This message was deleted.

The main hurdles I faced were: • Importing resources when you have multiple stacks (ie, production, staging, + test; all nearly like-for-like) • Accounting for minor drift issues, such as descriptions being slightly incorrect, or different attributes being set on a gke cluster (but nothing that triggers a recreate) • Values that are actually references to other resources (such as the IP address name) • Generating code without importing into state (we do code reviews before changing production. It's desired that Staging + Test stacks follow the same process) In this case, we had one environment we could mess up (test), one we shouldn't (staging), and one we mustn't (production). Our usecase was pretty small, around 30 resources, with 5 that had drifted. With multiple stacks + using resource outputs for inputs, we elected to use

import

through ResourceOptions, generating code via another stack if the resources had larger definitions. The drifted resources needed conditionals on inputs, "ignore Changes" setting, or modifying from the console so that they'd import. Effectively, no way to do "import and fix drift" without modifying code. The limitation is documented. It's also the biggest blocker, as it prevents us saying "the existing infrastructure was incorrect in the first place, respect my code". I can absolutely see how dealing with drift can be a major inconvenience in trying to adopt large existing infrastructure. We were lucky in that much had been previously created with scripts as apposed to using a console or CLI directly. Other infrastructure I've worked on would not be as clean, perhaps even resulting in a decision to just do a rebuild (had one case where this was necessary, but the infra was in a dire state anyway). Multiple stacks was less of a hurdle, but added a little more complexity as we needed to account for drift from multiple sources.

This is all excellent feedback, thank you!