We’ve been through a couple of platform migrations, and the pattern is always the same: someone says “we’re moving to platform X,” and then developers see a chance to “do it right this time” and end up rewriting everything from scratch instead of migrating existing workflows.
That kills the economic case for switching. You’re supposed to save money by moving to a more efficient platform. You don’t save money if you spend the next six months rebuilding every workflow you’ve ever written.
I’m trying to figure out the practical constraints that would make developers actually migrate existing workflows instead of rewriting them. Is it a matter of tooling—like, is there migration automation that preserves 80% of the work and forces them to only customize the remaining 20%? Or is it a matter of deadlines and freezing the codebase so they don’t have time to rewrite? Or is it that the old platform and the new platform are similar enough that migration is genuinely less work?
I’m also wondering whether the cost of migration—even if it’s partly automated—is accounted for in the TCO analysis. Because if migration costs are high enough, you might be better off running both platforms in parallel for a while, which adds its own overhead.
How have other teams actually managed this transition? Did you have a forced migration timeline? Did you provide tooling that made migration automatic? Or did you just accept that some effort was spent on rewriting old stuff?
We put a hard freeze on new features for two weeks before migration and required developers to migrate existing workflows to the new platform as-is, without rewriting. The rule was simple: get the workflow running on new platform with minimal changes, get it tested, get it deployed, move to the next one. Any significant rewrites had to wait until after migration and be evaluated separately.
That constraint actually worked. Developers didn’t have time to rethink architecture, so they focused on mechanical migration. We still did some cleanup and optimization afterward, but it was consciously separate from the migration work. Made the cost much clearer.
The tooling question is real. If the new platform can import old workflows directly—even if they need tweaks—that’s a huge leverage point. If developers have to manually rewrite each workflow, migration becomes a rewriting project. We had partial import capabilities, which meant 60-70% of old workflows came over working. That forced function as a baseline.
We also assigned one senior developer to do a test migration of our most complex workflow first. That gave us realistic time estimates and identified what actually needed tweaking. Then we could enforce realistic timelines for the rest of the team instead of everyone guessing and deciding to rewrite.
The other thing that helped: publish the cost of rewrites. If a developer wants to spend three weeks optimizing a workflow instead of doing a two-day migration, make them justify that time investment against the business case for platform switching. Most rewrites don’t survive that scrutiny.