Breaking the rule: how we migrated the framework and the UI at the same time
Conventional wisdom says you never replace a frontend framework and a design system together. For one of Europe's largest e-commerce platforms, doing both at once was the safer choice, and an AI-assisted pipeline cut each application's migration from months to weeks.
One of Europe's largest e-commerce platforms needed two things at once: a new frontend framework and a new design system. Conventional wisdom says you never do both together, and normally we agree. Replacing a system piece by piece, often called the Strangler Fig pattern, is our default advice for a reason.
This time we took a different path. We rebuilt the framework and the UI together, and it turned out to be the safer choice. What used to take one to two months per application came down to one to two weeks, with over 80% of the migration work handled by an AI-assisted pipeline we built along the way.
Why we did both at once
Phasing out an application gradually, with old and new components running side by side, is usually the right call. You avoid one big launch and ship value as you go.
That breaks down when the UI library itself is being replaced. Running the legacy styles next to a new in-house design system, page by page, means customers see two design systems on the same screen for the whole migration. For months. That cost outweighed the risks a gradual migration normally protects you from.
So we inverted the approach. We built the new application in full isolation, in its own environment, while the live application kept running untouched. When it was ready, we switched over in one move instead of screen by screen.
Gradual migration wins when the half-migrated product is fine to live with. Here it was not. When two major parts of the product change at once, the slow rollout can be the more visible risk.
How we made a single cutover safe
A launch of this size only works if you take as much risk out as possible beforehand, and can undo it in seconds if something goes wrong.
We built the new application on staging while the live application stayed in production, untouched. No shared code, no shared state, nothing customer-facing depending on unfinished work. The build phase carried close to zero production risk.
The risk concentrates at the cutover. Switching a whole customer-facing application in one move means any defect missed in testing reaches every user at once. So we designed the switch to be reversible in seconds: if anything broke, traffic went straight back to the proven legacy build. Close to zero risk during the build, and a known, bounded risk at launch with an immediate way back. That combination is what made it safe.
We also ran this without a dedicated QA function. The engineers building each part of the new application owned its correctness, testing their own and each other's work against the live legacy application before sign-off. That worked for two reasons. The isolated setup gave them a clean environment to test against, and quality stayed with the people who understood the code best.
Where AI came in
The early phase was entirely manual. We migrated a handful of applications, small and large, by hand before writing any automation. That is how we learned how the legacy logic maps onto the new stack and where the edge cases live. A tool can only repeat a pattern someone has already proven.
Once the patterns held, we built an internal tool to apply them at scale. Instead of one large, unpredictable pass per application, it runs a small pipeline of specialised automated steps. That pipeline now reliably handles over 80% of the remaining migration work.
The rest stays with people. Roughly a fifth of the effort goes to catching the subtle mistakes an automated system can plausibly make, and to the deployment configuration specific to each team's application. The pipeline handles the repeatable part; people handle the part that needs judgement. Knowing exactly where that line sits is what let the business trust the timeline.
What used to take one to two months per application now takes one to two weeks.
What to take into your own migration
- "Never do both at once" has conditions. It holds when the half-migrated state is fine to live with for months. When a framework change and a design system change collide, and a slow rollout means shipping an inconsistent product, ask whether an isolated rebuild with a fast, reversible cutover is the safer path.
- Prove the pattern by hand before you automate it. Migrate a representative handful of cases manually first. That is where you find the mapping rules and edge cases a tool has to get right before it runs at scale.
- Developer-owned testing can replace a QA gate, if the new build is isolated. It worked here because the new application never touched production while it was being built. Ask where quality ownership sits in your own migration, and whether your environment gives people a safe place to own it.
- Know where your automation stops, and say so. An AI-assisted migration that names the work it hands back to people is more believable than one claiming full automation. When you evaluate one, look for that boundary, not just the coverage number.
Facing a migration where going gradually means months of a product that looks half-finished? Talk it through with us before you pick the path.
Talk to us