Terraform：跨项目迁移资源状态的低痛苦实现方案咨询

嘿，这个问题我之前帮好几个团队踩过坑，跨状态文件迁移确实比同文件内重构麻烦，但绝对不用手动改JSON这么折磨人！下面是我亲测有效的最低痛苦流程：

第一步：先做双重备份，稳字当头 #

不管操作多熟练，备份永远是第一要务。分别在两个项目里执行命令，把远程状态拉到本地备份：

# 原项目备份
terraform state pull > old-project-state.backup
# 目标项目备份
terraform state pull > new-project-state.backup

万一操作失误，随时可以用terraform state push把备份推回去恢复。

第二步：在目标项目中同步资源配置 #

确保目标项目里要迁移的资源/模块代码，和原项目中的完全一致——包括所有参数、标签、依赖、甚至资源名称，差一个字符都可能让Terraform误以为要新建或删除资源，这会搞砸整个迁移。

第三步：用terraform state mv跨状态迁移 #

这个命令是核心！它支持跨本地状态文件迁移，我们可以先把远程状态拉到本地临时文件，迁移后再推回远程。

1. 先把两个项目的远程状态拉到本地临时文件：

# 拉取原项目远程状态到本地临时文件
terraform -chdir=./old-project state pull > ./old-project.tfstate
# 拉取目标项目远程状态到本地临时文件
terraform -chdir=./new-project state pull > ./new-project.tfstate

2. 执行状态迁移命令，比如要迁移名为module.my_service的子模块：

terraform state mv \
  -state=./old-project.tfstate \
  -state-out=./new-project.tfstate \
  module.my_service module.my_service

如果是单个资源，就写完整的资源地址，比如aws_s3_bucket.my_data_bucket。

第四步：验证迁移结果，确保无意外 #

分别在两个项目里执行terraform plan：

• 原项目的plan应该显示没有要销毁的资源（因为状态已经移走了，你之后再删掉原项目里对应的代码）；
• 目标项目的plan应该显示No changes. Your infrastructure matches the configuration.，说明状态和代码完全匹配。

如果这里出现了意外的创建/销毁提示，赶紧停下来检查代码和状态的一致性，别硬推进。

第五步：推送更新后的状态回远程S3 #

确认没问题后，把修改后的本地状态推回各自的远程存储：

# 推送原项目的更新状态（移除了迁移资源）
terraform -chdir=./old-project state push ./old-project.tfstate
# 推送目标项目的更新状态（新增了迁移资源）
terraform -chdir=./new-project state push ./new-project.tfstate

第六步：清理收尾 #

最后删掉原项目中对应的资源/模块代码，再执行一次terraform plan确认没有残留变更，整个迁移就完成了。

额外注意事项 #

• 迁移过程中暂停两个项目的自动部署（比如CI/CD流水线），避免并发修改状态导致冲突；
• 如果迁移的资源依赖原项目的其他资源，要么把依赖一起迁移，要么在目标项目中用数据资源（data "aws_xxx"）引用原项目的依赖，或者重新创建依赖；
• 绝对不要手动编辑状态JSON文件，哪怕只是改个名称——状态文件的格式和内部关联很复杂，手动修改极易导致状态损坏，排查起来比迁移本身还痛苦。

内容的提问来源于stack exchange，提问作者Nathan