The migration nobody noticed
Moving a high-traffic journey onto a new stack without a launch date, a freeze, or a drop in conversion.
The safest website migration is the one users never notice. There is no dramatic launch date, no long code freeze and no weekend cutover. A single route moves behind a feature flag, the old experience stays one toggle away, and evidence decides when the next route follows.
Begin with an inventory, not a rewrite. Map routes, templates, integrations, analytics events, redirects and the internal tools that depend on undocumented behaviour. Record the performance and conversion baseline for each journey. Without that baseline, a visually improved page can still hide a commercial regression.
Order the migration by learning value and operational risk. A plain, high-traffic route is often the right first candidate because it proves the application shell, data loading, consent model and analytics before a complicated journey is at stake. Starting with the most exciting page usually postpones the hard architectural questions.
Use the existing system as a boundary rather than an enemy. A strangler-style migration lets the new application take ownership route by route while established services continue doing their job. Shared contracts matter more than shared code: agree what data crosses the boundary and test that contract from both sides.
Compare the new route with the old one at a small percentage of traffic. Conversion, errors and Core Web Vitals should be visible by version and route, not averaged across the whole site. If the replacement cannot match the current experience, move traffic back the same day and investigate without turning the release into an incident.
Accessibility and search behaviour need the same discipline. Preserve heading structure, canonical URLs and meaningful content in the initial HTML. Test keyboard journeys and screen readers alongside visual regression. Redirect every retired URL deliberately and keep the sitemap aligned with the routes search engines should actually index.
The final ten percent is where migrations become permanent liabilities: old redirects, duplicated analytics, forgotten scheduled jobs and three internal pages nobody mentioned. Put removal criteria beside every temporary bridge and assign an owner. A migration is finished when the old path can be deleted safely, not when the new homepage looks complete.