A phased rebuild can look safe because only one section changes at a time. The hidden risk is the step that crosses the boundary: a new service page sends a visitor to an old booking form, or an old account page links to a new dashboard that does not recognize the session. Test those transitions as complete customer tasks before declaring a phase finished.
Martin Fowler's incremental replacement pattern explains why replacing parts over time can avoid a single wholesale switch, while also creating temporary integration work. It is an architecture approach, not evidence that phasing automatically saves money or protects search traffic. The phase is successful only if the whole buyer journey still works.
Draw a route and responsibility map
List each live path in the proposed phase. For every URL, name the system that serves it today and the one that will serve it after release. If both systems share a domain through routing rules, identify who maintains that routing. nginx documents proxy_pass as one way to send requests to an upstream application; the buyer does not need to prescribe that technology, but the project needs a verifiable route owner.
Then trace each task across both systems. A useful test set is not just “open the new pages.” It includes at least one transition in each direction:
| Boundary to cross | Concrete acceptance test | Evidence to keep |
|---|---|---|
| New page → old form or booking tool | Start on the new service page, submit a realistic inquiry, and confirm it reaches the right team with the right service context. | Starting URL, submitted test ID, destination record, time. |
| Old page → new account or tool | Follow the real link and complete the intended signed-in task; check the expected sign-in or handoff behavior. | Redirect chain, account state, result screen; no production credentials in the brief. |
| Either page → language or consent choice | Change the setting, cross the boundary, and confirm the choice and permitted tags behave as approved. | Browser state, page pair, tag/consent evidence. |
| Either page → search and navigation | Follow menus, breadcrumbs, search results, and important internal links without dead ends or unintended duplicate pages. | URL list, response, canonical/redirect outcome. |
| Either page → measurement | Complete the same qualified inquiry on each path and verify that the intended event is recorded once with usable source context. | Event name, test record ID, timestamp, report/debug trace. |
| Revert a failed phase | Restore the previous route and page state, then repeat the critical task. | Owner, trigger, rollback steps, test result. |
The cookie/session row is a risk to test, not an instruction to share authentication across applications. Cookie Domain, Path, Secure, and SameSite settings affect when browsers send them; MDN's cookie reference explains those behaviors. A security owner must approve any cross-system session design. If a customer should sign in again, make that explicit and test that the handoff is understandable.
Keep search changes separate from phase changes
If a page keeps the same URL, record its old and new content, title, canonical, and internal links. If a URL changes, create an explicit old-to-new mapping and test the redirect. Google's site-move guidance says a large site can test a section first when technically possible, while warning that one section may not represent the whole move. It also says significant site changes can produce search fluctuations. A successful internal QA pass is not an indexing or ranking guarantee.
For analytics, compare the same event definition before and after the phase and test the consent state that permits it. A shared domain with two applications can still have different event and tag behavior. Record launch dates and synthetic inquiry IDs so later analysis can separate a tracking break from a change in actual inquiries.
Accept the journey, then accept the phase
Run the matrix in a staging environment, then repeat the most consequential paths on the public site after release. A phase does not pass because the new section looks finished. It passes when the old/new route, the customer action, the business record, and the rollback route match the agreed behavior. Assign an owner to each failure and keep the previous system available until the agreed rollback window closes.
The redesign migration guide addresses search visibility after a move, and the content migration QA guide checks missing or duplicate pages. This matrix is for the live boundary between two systems. Keep it with the route map and phase acceptance record. Phased routing, session work, and integrations need separate discovery under ARCHV's website scope.