Website migration checklist: from inventory to launch

1. Inventory pages, files and visitor actions

List the public pages that need to stay. Include pages outside the main navigation: older campaign links, service detail pages, PDFs and pages shared in email or QR codes. Record what each page does for a visitor.

• Page address, title, main text and who approves it.
• Images, PDFs, tables and download links, including permission to reuse them.
• Contact phone and email links, forms, booking links and directions.
• Stores, member areas, logins, search, custom code and other dependencies.
• Current hosting, domain, mailbox and other services, with their renewal dates.

Save a backup of the existing content and files before work starts. Keep access to the old hosting account until the new site and recovery plan are accepted. Never share account passwords with a migration vendor; use named, limited access where available.

2. Map old page addresses before changing them

For every agreed old URL, choose one action: preserve it, redirect it to its closest replacement, or deliberately retire it. A list makes omissions visible. Preserve meaningful paths where practical; changing the design does not require changing every address.

Download the URL inventory worksheet (CSV). It contains three illustrative rows; replace them with your own URLs. It is a planning worksheet, not a file to import into SiteSnug.

• Map moved pages to relevant replacements rather than sending every URL to the homepage.
• Check both navigation links and links inside text or files.
• Confirm the preferred HTTPS domain and each page's canonical address.
• Agree how to handle retired pages, legacy redirects and external integrations.

Google's site-move guidance explains the search considerations for URL changes. A migration can change search performance; URL mapping does not guarantee rankings.

3. Agree the quote and acceptance checks

A written scope should identify the page and file inventory, supported layout, redirects, contact paths, exclusions, responsibilities and timing. Mark custom forms and booking features explicitly. Keeping a link to an existing service is different from rebuilding that service.

SiteSnug migration starting prices are $499 for up to 10 pages and $999 for up to 100 pages, per site, subject to review and a written quote. More involved work needs a custom quote, and requests above 100 pages need capacity confirmation. Hosting, updates, domains and other vendor services are separate. Payment arrangements are confirmed directly: 50% before work and 50% after preview approval, before launch.

4. Approve the exact private preview

Review the prepared release, not just a screenshot or an editable draft. In SiteSnug, a saved draft and a prepared preview do not change the live website. Record which release you approved and which corrections remain.

• Read every agreed page and check business names, hours, prices and contact details.
• Open the navigation, internal links, external links, images and PDF downloads.
• Test supported contact and booking paths using an agreed test procedure.
• Compare mobile and desktop layouts, headings and readable text.
• Review titles, descriptions, canonical addresses, the sitemap and redirect map.
• Confirm that private workspace and preview content cannot be accessed by unrelated or signed-out visitors.

Our Cylentware pilot walkthrough illustrates draft, preview and publishing as separate stages. Its successful publication is evidence for that pilot, not proof that another website's forms or integrations will work.

5. Verify the live website after the domain change

After approval and agreed payment, the owner confirms the publishing and domain changes. Keep mailbox records intact. Website routing and email routing are separate: do not replace MX, SPF or DKIM records just to connect the website.

• Check HTTPS and the preferred domain, including the www redirect if used.
• Open all agreed pages and files at their public addresses.
• Test old URLs against the agreed redirect map.
• Check contact links and agreed integrations on the public site.
• Confirm that public pages are indexable, the sitemap is accessible, and private pages remain excluded.
• Submit the updated sitemap in the owner's verified Search Console property. Inspect changed URLs when needed.

Allow for DNS propagation and search recrawling. Keep the previous website and backup available until the agreed live checks pass. See Google's sitemap report guidance; submitting a sitemap does not guarantee crawling or indexing.

6. Finish with an update and recovery plan

Record the published release, domain settings, support contacts, agreed recurring services and unresolved items. Show the owner how to edit supported content, prepare a preview, approve publication and restore a previous successful release. Revoke temporary access when the work is complete.

Keep a list of what SiteSnug manages and what stays with another provider. Use the setup guide for the dashboard workflow and the cost comparison worksheet for ongoing expenses.