github.com/muratcelep/terraform@v1.1.0-beta2-not-internal-4/website/docs/cli/commands/state/mv.html.md (about)

     1  ---
     2  layout: "docs"
     3  page_title: "Command: state mv"
     4  sidebar_current: "docs-commands-state-sub-mv"
     5  description: |-
     6    The `terraform state mv` command changes bindings in Terraform state, associating existing remote objects with new resource instances.
     7  ---
     8  
     9  # Command: state mv
    10  
    11  The main function of [Terraform state](/docs/language/state/index.html) is
    12  to track the bindings between resource instance addresses in your configuration
    13  and the remote objects they represent. Normally Terraform automatically
    14  updates the state in response to actions taken when applying a plan, such as
    15  removing a binding for an remote object that has now been deleted.
    16  
    17  You can use `terraform state mv` in the less common situation where you wish
    18  to retain an existing remote object but track it as a different resource
    19  instance address in Terraform, such as if you have renamed a resource block
    20  or you have moved it into a different module in your configuration.
    21  
    22  ## Usage
    23  
    24  Usage: `terraform state mv [options] SOURCE DESTINATION`
    25  
    26  Terraform will look in the current state for a resource instance, resource,
    27  or module that matches the given address, and if successful it will move the
    28  remote objects currently associated with the source to be tracked instead
    29  by the destination.
    30  
    31  Both the source and destination addresses must use
    32  [resource address syntax](/docs/cli/state/resource-addressing.html), and
    33  they must both refer to the same kind of object: you can only move a resource
    34  instance to another resource instance, a whole module instance to another
    35  whole module instance, etc. Furthermore, if you are moving a resource or
    36  a resource instance then you can only move it to a new address with the
    37  same resource type.
    38  
    39  The most common uses for `terraform state mv` are when you have renamed a
    40  resource block in your configuration or you've moved a resource block into
    41  a child module, in both cases with the intention of retaining the existing
    42  object but tracking it under a new name. By default Terraform will understand
    43  moving or renaming a resource configuration as a request to delete the old
    44  object and create a new object at the new address, and so `terraform state mv`
    45  allows you to override that interpretation by pre-emptively attaching the
    46  existing object to the new address in Terraform.
    47  
    48  ~> *Warning:* If you are using Terraform in a collaborative environment, you
    49  must ensure that when you are using `terraform state mv` for a code refactoring
    50  purpose you communicate carefully with your coworkers to ensure that nobody
    51  makes any other changes between your configuration change and your
    52  `terraform state mv` command, because otherwise they might inadvertently create
    53  a plan that will destroy the old object and create a new object at the new
    54  address.
    55  
    56  This command also accepts the following options:
    57  
    58  * `-dry-run` - Report all of the resource instances that match the given
    59    address without actually "forgetting" any of them.
    60  
    61  * `-lock=false` - Don't hold a state lock during the operation. This is
    62     dangerous if others might concurrently run commands against the same
    63     workspace.
    64  
    65  * `-lock-timeout=DURATION` - Unless locking is disabled with `-lock=false`,
    66    instructs Terraform to retry acquiring a lock for a period of time before
    67    returning an error. The duration syntax is a number followed by a time
    68    unit letter, such as "3s" for three seconds.
    69  
    70  For configurations using
    71  [the `remote` backend](/docs/language/settings/backends/remote.html)
    72  only, `terraform state mv`
    73  also accepts the option
    74  [`-ignore-remote-version`](/docs/language/settings/backends/remote.html#command-line-arguments).
    75  
    76  The legacy options [`-backup` and `-backup-out`](/docs/language/settings/backends/local.html#command-line-arguments)
    77  operate on a local state file only. Configurations using
    78  [the `remote` backend](/docs/language/settings/backends/remote.html) 
    79  must specify a local state file with the [`-state`](/docs/language/settings/backends/local.html#command-line-arguments)
    80  option in order to use the [`-backup` and `-backup-out`](/docs/language/settings/backends/local.html#command-line-arguments)
    81  options.
    82  
    83  
    84  For configurations using
    85  [the `local` state mv](/docs/language/settings/backends/local.html) only,
    86  `terraform state mv` also accepts the legacy options
    87  [`-state`, `-state-out`, `-backup`, and `-backup-out`](/docs/language/settings/backends/local.html#command-line-arguments).
    88  
    89  ## Example: Rename a Resource
    90  
    91  Renaming a resource means making a configuration change like the following:
    92  
    93  ```diff
    94  -resource "packet_device" "worker" {
    95  +resource "packet_device" "helper" {
    96     # ...
    97   }
    98  ```
    99  
   100  To tell Terraform that it should treat the new "helper" resource as a rename
   101  of the old "worker" resource, you can pair the above configuration change
   102  with the following command:
   103  
   104  ```shell
   105  terraform state mv packet_device.worker packet_device.helper
   106  ```
   107  
   108  ## Example: Move a Resource Into a Module
   109  
   110  If you originally wrote a resource in your root module but now wish to refactor
   111  it into a child module, you can move the `resource` block into the child
   112  module configuration, removing the original in the root module, and then
   113  run the following command to tell Terraform to treat it as a move:
   114  
   115  ```shell
   116  terraform state mv packet_device.worker module.worker.packet_device.worker
   117  ```
   118  
   119  In the above example the new resource has the same name but a different module
   120  address. You could also change the resource name at the same time, if the new
   121  module organization suggests a different naming scheme:
   122  
   123  ```shell
   124  terraform state mv packet_device.worker module.worker.packet_device.main
   125  ```
   126  
   127  ## Example: Move a Module Into a Module
   128  
   129  You can also refactor an entire module into a child module. In the
   130  configuration, move the `module` block representing the module into a different
   131  module and then pair that change with a command like the following:
   132  
   133  ```shell
   134  terraform state mv module.app module.parent.module.app
   135  ```
   136  
   137  ## Example: Move a Particular Instance of a Resource using `count`
   138  
   139  A resource defined with [the `count` meta-argument](/docs/language/meta-arguments/count.html)
   140  has multiple instances that are each identified by an integer. You can
   141  select a particular instance by including an explicit index in your given
   142  address:
   143  
   144  ```shell
   145  $ terraform state mv 'packet_device.worker[0]' 'packet_device.helper[0]'
   146  ```
   147  
   148  A resource that doesn't use `count` or `for_each` has only a single resource
   149  instance whose address is the same as the resource itself, and so you can
   150  move from an address not containing an index to an address containing an index,
   151  or the opposite, as long as the address type you use matches whether and how
   152  each resource is configured:
   153  
   154  ```shell
   155  $ terraform state mv 'packet_device.main' 'packet_device.all[0]'
   156  ```
   157  
   158  Brackets (`[`, `]`) have a special meaning in some shells, so you may need to
   159  quote or escape the address in order to pass it literally to Terraform.
   160  The above examples show the typical quoting syntax for Unix-style shells.
   161  
   162  ## Example: Move a Resource configured with for_each
   163  
   164  A resource defined with [the `for_each` meta-argument](/docs/language/meta-arguments/for_each.html)
   165  has multiple instances that are each identified by an string. You can
   166  select a particular instance by including an explicit key in your given
   167  address.
   168  
   169  However, the syntax for strings includes quotes and the quote symbol often
   170  has special meaning in command shells, so you'll need to use the appropriate
   171  quoting and/or escaping syntax for the shell you are using. For example:
   172  
   173  Unix-style shells, such as on Linux or macOS:
   174  
   175  ```shell
   176  terraform state mv 'packet_device.worker["example123"]' 'packet_device.helper["example456"]'
   177  ```
   178  
   179  Windows Command Prompt (`cmd.exe`):
   180  
   181  ```shell
   182  terraform state mv packet_device.worker[\"example123\"] packet_device.helper[\"example456\"]
   183  ```
   184  
   185  PowerShell:
   186  
   187  ```shell
   188  terraform state mv 'packet_device.worker[\"example123\"]' 'packet_device.helper[\"example456\"]'
   189  ```
   190  
   191  Aside from the use of strings instead of integers for instance keys, the
   192  treatment of `for_each` resources is similar to `count` resources and so
   193  the same combinations of addresses with and without index components is
   194  valid as described in the previous section.