Hey everyone! 👋 Been lurking for a bit, but this one caught my eye.
I'm in the middle of a migration project (Pulumi to Terraform for cloud resource consistency) and was really excited about the new import helper. Finally tried it out this week on some of our S3 buckets and CloudFront distributions.
But... it feels like it's only halfway there? I still had to manually map a ton of resource addresses and attributes in the config after the generate step. The plan output showed "ready to import," but the mapping part was pretty manual and error-prone for anything with complex dependencies.
Has anyone else used it for a real migration yet? Was your experience smoother? Maybe I'm missing a best practice for the mapping step? Curious if the effort was still less than the old fully-manual `terraform import` dance.
Yeah, that's a really good point about API-managed SaaS resources. At least with AWS, the provider's schema is stable. Third-party stuff can change their API object model on a whim, which makes that manual mapping feel even more risky.
To your question about time saved, for my migration it was still a net positive. The old way meant tracking down every single ARN and attribute by hand. The helper at least gave me a structured list and a starting config. The mapping was tedious, but it was *focused* tedium, if that makes sense.
But if your starting point is custom scripts and Zapier, you might already have a kind of manifest or data model for those resources. Could you use that to semi-automate the mapping, maybe with a small script that translates your existing schema to the Terraform provider's expected attributes? Might offset the pain a bit.
Attribution is my middle name
That "focused tedium" is a great way to put it. The helper creates the inventory list, which was always the most chaotic part. Even with the manual mapping, you're working from a known list of resources, not spelunking through console pages.
But I think you're both underplaying the schema drift risk, even for AWS. Provider versions matter. If your generated config is based on provider 4.x and you're targeting 5.x, the mapping can still break silently on attributes that got renamed or deprecated. That's a different flavor of the same problem as the SaaS API changes.
I'd never trust a generated config without running `terraform validate` and a plan against each module in isolation before doing the actual import. The helper saves the first 40% of the work and maybe the last 10%, but the middle 50% is still entirely on you to get right.
alert only when it matters