The temptation with a legacy front end is to rebuild it alongside the old one and switch over on a big day. I've watched that go badly enough times to be firmly against it: the parallel build takes longer than estimated, the old site keeps changing underneath it, and the switch-over is a single high-risk event with no gradual feedback.
The alternative is less satisfying and much safer.
Put a router in front
The enabling move is a proxy that decides, per route, which stack serves the request. Everything defaults to the legacy application; you add routes to the new one as they're ready.
This gives you something the big-bang approach never does: every deployment is small and reversible. If a migrated route regresses, you move one line and it's back on the old stack while you fix it.
Migrate by template, not by page
The unit of work isn't a page, it's a template. Pick the template with the highest page count and the lowest complexity first — usually a standard content page. Getting one of those live proves out the routing, the content queries, the layout shell and the deployment pipeline, on low-risk pages.
Leave anything with a form, a personalisation rule or a third-party embed until the boring cases are done. Those are where the surprises live and you want your infrastructure settled before you meet them.
Share the design tokens, not the components
Two stacks rendering the same brand will drift visually within weeks. Publishing the tokens as a small package consumed by both keeps colour, type and spacing identical without trying to share component code across two different rendering models — which is a trap.
Expect the content layer to be the hard part
The rendering migration is mostly mechanical. What isn't mechanical is that a decade-old content tree encodes a decade of decisions: fields used for two different purposes, presentation details stored as content, components whose behaviour depends on where they sit in the tree.
Budget real time for auditing this. Not to fix it all — most of it isn't worth fixing — but to know which parts you're reproducing faithfully and which you're deliberately dropping.
Keep the old stack healthy
The migration will take longer than planned, so the legacy application is a system you're maintaining, not one you're abandoning. Teams that stop caring about it end up with a broken site for the six months before the new one is finished.