1. Agree on the move and its limits
Confirm the old site, the business outcome, target platform, domain strategy, functional requirements, owner authority and available tools. Default to preserving working URLs, useful content and business facts. Ask for a host choice only if it is unknown; compare maintenance, forms, editing, access and ongoing costs before committing. Separate a migration from a redesign. A chat without editing and hosting tools produces a plan plus an exact implementation handoff.
Work product: A move brief with scope, target, tool access, exclusions, owner decisions and the first implementation step.
Done when: the target and domain strategy are confirmed or explicitly pending, every required function has a transfer route, and the owner knows which changes require approval.
2. Keep a recoverable copy and an inventory
Export the permitted source content, code, assets and CMS settings. Retain a restorable source backup and record how to recover it. Combine the sitemap, CMS export, public crawl and available analytics or Search Console records. Mark missing records as unknown. Include pages, media, documents, menus, forms, contact actions, legal links, scripts, analytics and integrations. Record actual status, title, heading, canonical, index controls and important links per observed page. Do not infer that an empty fetch proves a missing page. Avoid collecting form submissions or private customer data.
Work product: A dated URL and function inventory, evidence log, source backup and recovery procedure.
Done when: every observed URL and business-critical function is accounted for, gaps are explicit, the backup can be restored in a safe environment, and the old site remains available.
3. Map every old page to its destination
Keep the URL when feasible. For a necessary change, map each old URL to its useful final destination; record deliberate removals separately. Include media and downloads. Map a retired page to equivalent consolidated content only when it serves the same need. Otherwise use an appropriate missing-content response after the owner approves removal. Never blanket-redirect unrelated pages to the homepage. Assign each row a content-transfer decision and acceptance check.
Work product: An approved old-to-new URL map with preserved, moved, consolidated and removed rows.
Done when: every inventory row has one explicit decision, each proposed destination exists in the target plan, and important inbound links have a preservation route.
4. Build and transfer the actual website
Use the approved target tools to create the replacement in a branch, draft CMS or private preview. Transfer authorized page text, business details, images, downloadable files and accessible navigation. Preserve useful titles, headings, internal links and contact paths unless the owner approves a specific improvement. Recreate forms with correct destinations and a safe test mode; preserve agreed spam controls and privacy settings. Transfer only required integrations and analytics. Keep secret keys in server-side configuration, never client files or conversation text. Implement the URL map and direct permanent redirects where URLs change. Keep production untouched during construction.
Work product: A working preview and implementation record identifying transferred pages, functions, exclusions and unresolved issues.
Done when: every included inventory item has a working equivalent in preview, its content and function are checked, and any incomplete transfer is listed as a release blocker rather than marked complete.
5. Check the preview against the old site
Test desktop and mobile page rendering, readable text, keyboard navigation, form errors and a non-production submission, phone/email links, downloads and media. Inspect rendered status, title, H1, canonical, internal links and structured data against the baseline. Check each mapped destination and redirect behavior in a suitable preview environment; do not invent a successful redirect test when the host cannot reproduce it. Confirm that preview protection will remain on preview while production will have the intended indexing rules. Validate the release sitemap and robots settings. Treat unknown business-critical behavior as a blocker. Record issues with actual URLs, evidence and the confirming check.
Work product: A preview comparison and finite issue queue with release blockers, verified passes and untested conditions.
Done when: the owner can review the actual preview, every included function has test evidence, all blockers are resolved or explicitly accepted with consequences, and the production configuration is ready for a separate check.
6. Release only the approved change
Present the actual preview, URL map, remaining issues, expected downtime, rollback steps and exact production change for owner authorization. Use the existing authorized publishing route. If DNS changes are required, change only the agreed web records; retain mail and other unrelated records. Record previous values and propagation uncertainty. Confirm HTTPS and the canonical hostname. Do not shut down the old host before redirects and recovery are supported. Do not claim a deployment succeeded from a queued build. If production tools or authority are unavailable, deliver the exact release handoff and stop at release pending.
Work product: An authorized release record with timestamp, deployment identifier or host confirmation, prior configuration and rollback route.
Done when: the approved release is active at the canonical domain, HTTPS works, mail-related records are preserved, and a real production capture confirms the expected version.
7. Verify production and keep the recovery route
Repeat the agreed critical checks at the canonical domain. Verify important old URLs reach their mapped final pages through direct redirects when moved. Confirm content, forms, downloads, metadata, canonicals, indexing controls, sitemap and contact paths. Remove only staging-specific production indexing blocks. Record any fault, impact and first corrective step; execute an already-authorized rollback or request the necessary owner decision. For domain moves, verify the current Search Console Change of Address requirements; a path-only or hosting-only move does not require it. Submit the new sitemap through an authorized account where appropriate. Keep applicable old-URL redirects for at least a year and preferably longer. Schedule observations against the baseline; search visibility may fluctuate, and passing a release check does not guarantee rankings.
Work product: A production verification record, correction queue, retained redirect plan and dated follow-up observations.
Done when: every release acceptance check has fresh production evidence or explicit pending status, failures have a correction or rollback decision, and the owner retains the records needed to operate and recover the site.