Enterprise platform migration

Context

A large production web application needed to move off a legacy frontend while teams continued shipping. The constraint was operational, not theoretical: the existing system still had customers, release trains, and unresolved product work.

Problem

The platform had accumulated rendering, data-fetching, and ownership problems that no longer fit the product. A rewrite was politically attractive and technically dangerous. The work had to reduce architectural risk without creating a second product.

Constraints

• No freeze on feature development
• No public naming of the customer
• Shared design and API surfaces had to remain intact during the transition
• Performance could not regress on the paths students and operators used every day

Approach

The migration was treated as an architecture problem first. We mapped system boundaries, identified the routes that actually mattered, and moved in slices: routing, data access, then UI. New work landed in the target stack. Old work was isolated instead of endlessly patched.

Architecture

The replacement stack used Next.js as the application platform, with rendering strategy chosen per surface rather than as a global slogan. Shared packages covered design primitives and domain types so both systems could coexist.

Implementation

Teams shipped behind the same product surface. Tooling, preview deployments, and a small set of invariants (typed boundaries, performance budgets on key routes, explicit ownership) mattered more than a dramatic cutover date.

Result

The platform moved forward without a rewrite theater. Delivery continued. The new architecture became the default path for new work instead of an adjacent experiment.

What we learned

Incremental migration works when the team is honest about what must remain stable. The hard part is not the framework choice. It is protecting the product while the system underneath it changes.