Re-Platforming Without Stalling the Roadmap: A Practical Playbook

Big-bang re-platforming is the project pattern that has killed more product roadmaps than any other. The team announces a multi-quarter rewrite, freezes feature work to focus on the platform, hits unexpected scope at the 60% mark, slips by quarters, ships the new platform later than promised, and discovers that competitors shipped features while the team was busy. The pattern is so consistent it’s almost a corporate folk tale.

The teams that re-platform successfully use a different approach. They ship product features and platform migration in parallel, never freezing the roadmap. This post walks through what the discipline actually looks like.

The strangler fig pattern#

Martin Fowler popularized the term, borrowed from the strangler fig vine that grows around a host tree, gradually replacing it. Applied to software, the pattern: build new functionality in the new platform alongside the existing system, route specific traffic to the new platform, gradually expand coverage until the old system is unused, then remove it.

The pattern works because each step is small and reversible. If the new platform has an issue, route traffic back to the old system while you fix it. Each migration step is a normal deployment, not a high-stakes cutover.

The pattern requires upfront investment in routing infrastructure — typically a façade layer or API gateway that can selectively route requests to old or new implementations based on configuration. This investment is usually worthwhile; the alternative is the big-bang risk profile.

The four parallel work streams#

Successful re-platforming runs four parallel streams.

Platform foundation. Build the new platform incrementally — the persistence layer, the service framework, the deployment patterns, the observability infrastructure. Start with one well-understood domain and expand from there.

Feature migration. As the platform stabilizes, migrate existing features one at a time. Each migration is a defined project with clear acceptance criteria — feature parity, performance match or improvement, and the ability to fall back to the old implementation.

New feature development. Product roadmap continues on the new platform. New features are built where they belong rather than artificially constrained to the old platform.

Old platform maintenance. The legacy system continues to serve traffic until decommissioning. It needs bug fixes, security patches, and occasional capacity upgrades. The team treats this as ongoing operational work, not as deprecated.

What goes wrong without discipline#

Several patterns produce big-bang style failures even when teams intend to do strangler fig.

Migrating too fast. The team rushes the migration to get to “done” and skips the validation steps. Bugs that would have been caught with careful migration ship to production.

Migrating too slow. The team becomes too cautious and the migration drags on for years. The team has both platforms running for an unreasonable period, paying double infrastructure costs and double cognitive overhead.

Feature drift between platforms. The team adds features to one platform but not the other. By the time migration completes, the new platform doesn’t have feature parity.

Skipping the routing layer. Teams that don’t build routing infrastructure end up with hard cutover dates that produce the same risk profile as big-bang.

Insufficient old-platform investment. When the team treats the old platform as deprecated, bugs accumulate and production incidents increase. The team that was supposed to be migrating gets pulled into incident response.

The communication discipline#

Re-platforming touches the broader organization. The discipline that distinguishes successful programs:

Clear ownership. One technical leader owns the platform migration. They report progress, escalate blockers, and make trade-off decisions.

Regular stakeholder updates. Engineering leadership, product, and executive stakeholders get updates on cadence. Surprise slippage is a sign the program is broken.

Honest scope. Re-platforming reveals scope that wasn’t visible at planning time. The team that pretends scope hasn’t changed loses credibility. The team that re-estimates honestly maintains trust.

Explicit trade-offs. Sometimes the migration team needs feature-work resources. Sometimes product needs feature-team resources. The trade-offs should be explicit and decided at the right level, not absorbed quietly.

The decision criteria#

Not every re-platforming need is best served by strangler fig. The technique works best when:

• The old platform has clear boundaries that can be addressed one at a time.
• Routing infrastructure can be built without prohibitive complexity.
• The team can run both platforms in parallel without unsustainable cost.
• The migration timeline is months to years, not weeks.

For smaller systems with tight boundaries, a focused rewrite over a few weeks is sometimes the right answer. For systems where the boundary between old and new is impossible to draw cleanly, hybrid approaches with longer routing phases may be necessary.

Where pdpspectra fits#

Our architecture practice has led re-platforming engagements across data, AI, and broader application stacks. The pattern is consistent; the specifics are always different.

Related reading: the tech stack audit post, the sun-setting legacy systems post, and the tech debt triage post.

---

Re-platforming should not freeze the roadmap. Talk to our team about your migration.