The website redesign migration checklist has one hard boundary
Most migration damage is committed months before anybody opens the launch runbook. Changing URLs and rewriting core content in the same release creates two unknowns at once, and no launch-day checklist can undo either decision. A website redesign migration checklist can prevent operational errors, but it cannot reconstruct signals discarded earlier.
The default rule is plain: keep URLs identical, keep the core content of pages that already earn traffic, and redirect only where a URL genuinely cannot survive.
The version we see in audits is usually presented as efficiency: new architecture, new copy and a new CMS shipped together. It is an untestable bundle.
For illustration, release A retains 24 of 24 established URLs and rewrites none of their core content; release B retains 0 of 24 while rewriting all 24 pages. Both may render correctly. Only release A separates deployment defects from content decisions.
Our claim is falsifiable: if comparable launches preserving 0 of 24 URLs produce no more critical routing incidents or unplanned content reversions during the first business day than launches preserving 24 of 24, the claim is wrong.
Architecture belongs upstream. In our Lanteria work, a broad capability set was routed for several stakeholder audiences. For AfriCap Hub, catalogue filtering and registration formed one coherent journey. Those are conversion-led redesign decisions within disciplined website design and redesign work, not switch-night improvisations.
Migration safety is decided before the launch room opens.
Four pre-launch gates that make the checklist enforceable
A calendar date is not evidence of readiness. For end-to-end website delivery, each of the four gates below needs veto power.
- Change gate. At T–5 working days, compare the signed release against the approved scope. If one traffic-earning core page changes both its URL and primary copy, remove one change or postpone the launch.
- Ownership gate. At T–48 hours, every launch-blocking task needs a named person and deputy. One blank owner field makes the release a no-go; “the agency” and “marketing” are not owners.
- Recovery gate. By T–24 hours, restoration evidence must be no older than 30 days and the rehearsal must have completed within 30 minutes. Miss either threshold and postpone rather than trusting an untested backup.
- Commercial-path gate. By T–2 hours, run 10 controlled enquiries across two browsers and two device classes. All 10 must reach HubSpot or the chosen CRM with required fields intact, while any Cal.com booking must reach the correct calendar. A 10/10 result passes; 9/10 is a no-go.
These thresholds are operating policies, not universal laws. Their purpose is to replace launch-room optimism with predetermined decisions.
The honest limit here is that 10/10 controlled enquiries cannot tell you whether the redesign will convert better. Baselines and event parity belong in a separate measurement plan for a redesign; this gate proves only operational receipt.
A frozen scope makes launch evidence trustworthy.
The eight-step launch-day website migration checklist
Run one queue under one incident commander, with no parallel “quick fixes”. Replace every role label below with a person’s name.
- Lock the release. Owner: release manager. Pass condition: the approved build identifier matches the candidate and the change diff contains zero unapproved items.
- Create the recovery point. Owner: platform engineer. Pass condition: the recovery point is less than 30 minutes old and the incident commander can access the tested rollback command or runbook.
- Expose the candidate privately. Owner: lead developer. Pass condition: all four route types—the homepage, principal landing template, form-success page and error page—load through an external connection using final production configuration.
- Prove the commercial handoff. Owner: marketing operations lead. Pass condition: five of five controlled form or Cal.com journeys produce all three required outcomes: the correct CRM record, internal notification and calendar entry where applicable.
- Switch public routing once. Owner: infrastructure lead. Pass condition: both routing checks pass—two independent networks reach the new origin and the live domain presents a valid TLS certificate.
- Run the public path set. Owner: QA lead. Pass condition: 10 of 10 priority URLs return their signed status and complete their intended journey. A 200 response on the candidate versus a 404 after the switch is an immediate failure.
- Confirm acquisition endpoints. Owner: demand-generation lead. Pass condition: three priority Google Ads final URLs and one primary outbound-campaign URL reach the correct live pages and complete the commercial handoff. Paused campaigns remain paused until this passes.
- Declare the state. Owner: incident commander. Pass condition: all three closing conditions hold—the previous seven steps are signed, no rollback trigger is active and the decision is logged as live or reverted.
Nobody silently converts a failed condition into an action item. A failure stops the queue until the incident commander applies the predetermined rule.
A launch sequence works only when every gate can stop the release.
If this analysis exposes wider gaps in your site, we can turn the evidence into a focused redesign brief — book a call
Rollback rules require numbers, not launch-room debate
Debate becomes expensive once prospects are reaching a broken commercial path. Put three numerical rollback triggers in the runbook before switching traffic.
- Lead-delivery trigger. If successful production form-to-CRM delivery falls from 100% in the signed pre-switch test to below 80% during any rolling 15-minute window, using at least five controlled submissions, revert rather than investigate.
- Availability trigger. If primary conversion-path availability falls from 100% on the candidate to below 95% across 20 external checks within 10 minutes, revert.
- Server-error trigger. If three or more of the 10 priority paths return a 5xx response on two runs five minutes apart, revert.
One isolated 404 on a non-priority archive page does not justify rollback. Log it, assign an owner and keep the release live only when the principal journey remains intact.
Take an explicitly illustrative UK cybersecurity consultancy with six labelled inputs: monthly Google Ads spend of £8,000; 1,000 monthly paid clicks; 20 expected paid clicks during a four-hour launch window; a normal enquiry rate of 5%; a broken-state enquiry rate of 0%; and £4,000 weighted pipeline value per accepted enquiry.
£8,000 monthly spend ÷ 1,000 monthly clicks = £8 per paid click 20 launch-window clicks × £8 = £160 paid media exposed 20 launch-window clicks × (5% normal − 0% broken) = 1 expected enquiry lost 1 expected enquiry × £4,000 weighted pipeline = £4,000 weighted pipeline at risk
This illustrative counterfactual is confounded by whether those 20 clicks would have converted. It prices exposure, not measured loss.
Rollback speed protects commercial opportunity.
What does not work on launch day
Metadata edits cannot repair a broken route, and rushed tagging changes can conceal one. Bar four apparently productive jobs from the cutover queue.
- Bulk title and meta-description rewrites. Search snippets do not restore failed forms, routing or CRM delivery. Editing them under pressure introduces an unreviewed content variable without helping the launch pass.
- A GA4, Google Tag Manager and Consent Mode refactor. This three-part rebuild cannot repair the user journey. Doing it during cutover makes collection failure harder to distinguish from website failure.
- CMS asset deletion and image recompression. An unused-looking file may still be referenced by a page, email or cached stylesheet. Deleting or renaming files under pressure creates fresh 404s and cache faults.
- CTA, form and brand-copy changes. Apply credible B2B brand personality and B2B lead-generation principles during design approval. Changing them during migration gives every lead movement two competing explanations.
The four jobs can matter in controlled releases after launch. None belongs beside a traffic switch, recovery point or rollback decision.
Launch pressure turns optional optimisation into uncontrolled migration risk.
FAQ
Four operational decisions need fixed answers before the launch calendar invite exists.
How low should the DNS TTL be before migration?
Use an operating threshold of 300 seconds at least 24 hours before launch where the provider permits it. If the TTL remains above 3,600 seconds at T–2 hours and DNS is the rollback mechanism, postpone or use a pre-approved proxy switch.
Is a Friday website launch ever acceptable?
Approve Friday only when two named technical owners and one commercial owner are available for the first four hours and the following morning. Otherwise, choose Tuesday to Thursday and preserve a staffed recovery window.
How long should the old environment remain available?
Keep an access-restricted, read-only instance for seven calendar days when security and contractual rules permit. If retaining the environment creates exposure, close it and retain the tested recovery image under the organisation’s approved retention schedule.
How long should launch evidence be retained?
The release manager should retain the build identifier, approvals, timestamps and incident log for 90 days or the organisation’s change-control period, whichever is longer.
Operational certainty is the only useful definition of launch readiness.
Summary
Use these five rules:
- Keep every viable URL and traffic-earning core page unchanged; redirect only unavoidable removals.
- Postpone when one core page changes both its URL and primary copy.
- Give all eight launch steps one named owner and one binary pass condition.
- Revert when form-to-CRM delivery falls from 100% to below 80% within 15 minutes.
- Launch-day scope excludes metadata rewrites, asset clean-ups, GTM refactors and CTA experiments.
Actualyse designs and rebuilds B2B websites that turn research visits into qualified pipeline. Book a call to talk through where yours stands.
