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.

Basically, imports seem to require a lot of back-and-forth with a person present, or for you to jump through hoops + multiple PRs/commits to try automating it. The latter is fine for continuous Deployments, but this isn't everyone's usecase.

As a side, cross-project renames/imports, while a little dangerous, worked really well with some jq/sed magic and state imports. It'd be great to see Alias getting cross-project reference support :) This is important for people testing the waters with a single stack, who then want to introduce logical separation for performance and/or security.