Hey everyone! I've been knee-deep in a Terraform-to-Pulumi migration for our Salesforce-connected marketing stack, and let me tell you, the planning phase is everything. A smooth migration without downtime feels less like a tech project and more like a carefully orchestrated dance between your old and new IaC tool.
I wanted to share the core checklist that saved us, especially for those managing live environments. The goal is to keep everything running while you shift the foundation underneath.
First, **know your state inside out**. Before writing a single line of new code, audit your current state file. Map every resource, its dependencies, and crucially, any "unknown" values or sensitive data. For cloud resources with APIs, I often ran a script to tag everything with a `legacy_iac_tool = true` tag. This creates a visual safety net.
Second, **test the import flow in isolation**. Don't test on production. Create a copy of a non-critical module (like a test S3 bucket or a dev Salesforce sandbox environment) and practice importing it into the new tool's state. This is where you'll discover the real quirks—like how each tool handles name differences or immutable properties. We found Pulumi's auto-naming needed careful mapping to our existing Terraform resource addresses.
Finally, **plan your cutover in phases**. We grouped resources by blast radius and data sensitivity. Static networking components first, then stateless app layers, and finally the stateful, sensitive databases. For each phase, we had a rollback script ready that could re-import any failed resources back to the old tool's state using the tags we'd set. Communication with the broader RevOps and sales teams was key here—they knew which dashboards might flicker.
The biggest lesson? Time spent validating your backup and rollback plan is never wasted. It turns a scary "big bang" switch into a series of controlled, low-risk steps. Would love to hear what others have prioritized in their checklists, especially when integrating with CRM systems or APIs that have rate limits!
Your second point on testing the import flow in isolation is critical, but it often misses a hidden cost dimension. When you duplicate a non-critical module like a test S3 bucket, you're creating live resources that incur charges, even temporarily. I've seen teams run these import tests for weeks, forgetting that the duplicated resources often have different, more expensive configurations than the originals - think provisioned IOPS on a test database or a larger instance type.
The financial audit trail gets muddied. That `legacy_iac_tool = true` tag is excellent for identification, but you must also implement a strict cost allocation tag, like `migration_phase: import_test`, from the very first copied resource. Otherwise, your next cloud bill will have a spike from dozens of untagged, forgotten test resources, and untangling it is a forensic accounting exercise.
Always check the data transfer costs.