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.