I am curious what others experiences on here are with migrating over from Terraform. I’ve worked with Pulumi for a while, but don’t know Terraform. I’ve started to learn a little bit to help me understand how to best accomplish a migration to Pulumi. The current setup I am looking at is feasibly manageable (not too big), so I thought as a POC I could just import the base infrastructure and go from there as I learn more how/what Terraform is doing in this particular case. Doing research I found Pulumi has a convert feature though and a Pulumi Terraform bridge. It seems obvious to just use and trust the convert feature but I am now curious…what’s your take on each different approach? Have/how have you done a migration from Terraform to Pulumi? What was your strategy? Any common pitfalls encountered? Gotchas to lookout for? What worked, what didn’t, and what to probably avoid? I think it’s a manageable size to just rip the bandaid and the benefit outweighs dealing with incremental adoption/migration (at least the major bulk and confirming before cutover). Would love to hear any experience and insights. Thank you

So we put a lot of effort into the TF converter, but it's a very large surface area and it turns out LLMs are generally better at it. I think for state conversion the pulumi tools will probably work better though, they'll go through and pull all the IDs out the terraform state file and give you an import file to run with

pulumi import

@sticky-answer-6826 Are you using Pulumi OSS or Pulumi Cloud?

Thanks for that tip, @echoing-dinner-19531! @stocky-restaurant-98004, OSS. Why the difference?

Was going to potentially suggest Pulumi Neo for your conversion efforts.

Thank you

IMO, almost all migrations (not just IaC.. anything really) benefit from being from-the-ground-up reworks. Between learning the new tech "better", and having the opportunity to not make all the mistakes that you're still living with after 5 years of tech debt management.. just do it again from scratch. (Note that I'm not a manager, and I've yet to find a manager, or anyone non-technical, who agrees with my technically-sound and experientially-validated opinion.. but them's the breaks.) As an infra-specific twist on this, there will be some resources that you really, really want to maintain and import as-is, and many resources that you'll be happy to rebuild (or replace with a newer, better tech). Which makes from-the-ground-up reworking that bit more fun :)

@little-cartoon-10569 While I agree with the sentiment, this can be a lot of work. I just had to do a rewrite from scratch of a single component of our platform infrastructure and it took ages – so many pitfalls, so much arcane knowledge that you had long forgotten… So from a product management perspective it might not always be the best approach (in terms of ROI etc).

Absolutely. "Can benefit from" != "Provides excellent return on investment" 🙂

Agreed - Fine balance. I do see an intermediate of moving all “as-is” but now managed via Pulumi with the intention of this stable “copy”, to be refactored the “right way”. Now that it’s managed via Pulumi, it makes it much easier to move forward with the right plan. So no-diffs after first migrated deployment is the goal. Easiest way to get there is what I am curious about.

Exactly, this would be my approach as well: Avoid a big-bang migration, instead migrate & refactor incrementally.