Frontend Platform Modernization

Both applications ran. Nobody was blocked on a given morning. But the framework versions were aging, React was several releases behind, newer platform capabilities were out of reach, and the packages around them were tightly version-coupled — so every month the next upgrade cost slightly more than it would have the month before.

Technical debt rarely arrives all at once.

Both applications consumed the same three shared internal frontend libraries, and those libraries carried peer-dependency constraints tied to the older React ecosystem. Nothing downstream could move until they did. Coordinating that took 31 prerelease package iterations while the two migrations advanced against them.

The upgrade started one level below the app.

The final state was four framework majors away, and it would have been quicker to attempt in one jump. Staging it meant each phase isolated a different class of compatibility failure — so when something broke, the search space was one version wide instead of four.

Smaller blast radius.

React 19 was available, and including it would have made the migration look more impressive. Before committing, I mapped what it would actually touch.

That is not a framework upgrade. That is a product rewrite wearing one. So the migration was deliberately capped at React 18, and React 19 was left as a separate, scoped piece of work with its own case for doing it.

The goal wasn’t the newest stack.

The goal was the safest meaningful modernization.

The first application became the reference implementation: every dependency failure, every workaround, every ordering constraint was discovered there. The second application then reused the same phased structure rather than rediscovering the same problems.

None of this happened during a feature freeze. The migration ran alongside normal product delivery, and I shipped unrelated product work through the same window. A platform migration that halts the roadmap tends not to get a second one approved.

Platform work shouldn’t hold users hostage.

Alongside the migration I also pushed for clearer frontend conventions — feature-oriented folder structure, a tidier types organisation, consistent asset handling, and dependency hygiene — and helped teammates approach related package modernization the same way.

I have one post-migration production build at roughly 98 seconds. On its own that number proves nothing — there is no pre-migration equivalent to compare it against, so presenting it as an improvement would be inventing a result. I didn’t capture a baseline before starting.

Measure before optimizing.

The hardest part of a framework migration isn’t installing the new framework. It’s understanding everything that assumes the old one. If I ran this again, there would be one step before Phase 0: record build output, bundle size and CI duration before changing the first dependency.

Modernize deliberately.