Back to Work
NextGen Platform Migration

NextGen Platform Migration

Half the enterprise customer base, off a legacy platform, onto a modern architecture, in a single year. The project that proved we could run a complex high-stakes delivery program without dropping things.

The result

Half the enterprise customer base, off a legacy platform, onto a modern architecture, in a single year. Release cadence went from quarterly to bi-weekly. Net retention held throughout. Customer trust survived a high-stakes year intact.

This is the proof that I can run a high-stakes program across product, engineering, customer success, support, and executive communication - and hold the dates, the retention, and the release momentum at the same time.

How it worked

A cohort-based migration of enterprise clients from a legacy system that had carried the company for years onto a new platform that needed to inherit all the complexity without inheriting any of the constraints. I led the program end-to-end: scope, sequencing, customer communication, and internal coordination across product, engineering, customer success, and support.

We shipped customer-facing roadmap communication on a published cadence. Every cohort knew what was coming three sprints in advance. We hit those dates.

What changed afterward

  • Quarterly release cycles became bi-weekly
  • The product organization stopped optimizing for the legacy stack and started optimizing for continuous flow
  • Migration patterns we developed became the template for how we shipped subsequent platform changes

What I took from it

A migration of this size is mostly a customer-trust project. The technical risks resolve with enough engineering rigor. The trust risks compound. The cohorts that shipped well were the ones whose customer success and product teams over-communicated, even when there was nothing new to say.