New year, new platform. The tech debt from last year will be left behind. The new architecture will be clean. The team is energized. The roadmap is clear.
January is treated as a fresh start. It rarely is.
By March, the replatform is behind schedule and the old system is still running.
⸻
The Momentum Illusion
January energy is real but temporary. The returning team has clarity from distance. Two weeks away from the codebase creates the illusion that the problems are obvious and the solutions are simple.
This clarity fades by the third week. The problems that looked simple on the whiteboard are complex in the codebase. The dependencies that were "easy to untangle" are load-bearing. The migration path that seemed linear has branches that nobody mapped during the planning holiday.
The replatform was scoped during peak optimism and will be executed during reality.
⸻
The Parallel Burden
The new platform begins development. The old platform continues serving customers. Both require engineering resources.
The team was sized for one platform. It is now running two. Feature requests still arrive for the old platform because customers do not care about the migration timeline. Bug reports still come in for the old platform because it is still in production.
Every hour spent maintaining the old platform is an hour not spent building the new one. The migration timeline extends. Leadership asks why. The answer is the parallel burden, but the budget was approved for the new platform, not for maintaining both.
⸻
The Feature Freeze Rebellion
To accelerate the migration, the product team declares a feature freeze on the old platform. No new features. Maintenance only. All engineering effort goes to the new system.
The sales team objects. They have a deal that requires a feature on the current platform. The customer will not wait for the migration. The exception is approved. Then another exception. Then another.
The feature freeze dissolves within six weeks. The old platform is now receiving new features and maintenance, while the new platform competes for the same engineers. The migration has become a side project.
⸻
The Exit Criterion
Before starting the replatform, define the exit criterion for the old platform. Not the launch criterion for the new one. The exit.
When exactly will the old platform stop serving traffic? What must be true for that to happen? Who has the authority to enforce the cutover?
If these questions do not have firm answers, the replatform will produce a new platform that runs alongside the old one indefinitely. The organization will pay for both. The exit criterion was never defined. The timeline belongs to no one.
End.