How to Prepare for a Website Migration

Prepare content, URLs, data, hosting, DNS, email dependencies, analytics, backups, testing, launch, rollback, and post-migration monitoring.

A website migration may change hosting, platform, domain, design, content structure, or several of these at once. Preparation reduces the chance of missing data, broken forms, search loss, email disruption, or a launch that cannot be reversed. The plan should cover the website as an operating system, not only a folder of files.

Create a complete inventory

List pages, files, images, databases, forms, redirects, users, scheduled tasks, APIs, payment or CRM connections, analytics tags, search verification, DNS records, certificates, email-related records, and private configuration. Identify the owner and access method for every external account.

Record current behavior

Crawl public URLs and export important analytics and search data. Capture form recipients, confirmation behavior, event tracking, response headers, robots rules, sitemaps, canonical tags, and structured data. This baseline helps distinguish migration defects from pre-existing issues.

Plan URLs and content

Retain useful permanent URLs where possible. When a URL must change, map it to the closest relevant destination and use an appropriate permanent redirect. Remove obsolete content intentionally instead of redirecting every missing page to the homepage. Update internal links, navigation, canonical tags, sitemaps, feeds, and campaign destinations.

Prepare the target environment

Confirm runtime and database compatibility, storage, memory, scheduled jobs, mail delivery, certificates, caching, backup, monitoring, logging, and deployment access. Protect staging from public indexing and unauthorized access. Do not copy production credentials into an insecure test environment.

Rehearse data transfer

Test file and database migration before the launch window. Measure transfer time and identify which records may change between rehearsal and cutover. Choose a content freeze, maintenance period, synchronization approach, or another method to prevent data divergence.

Build a validation checklist

  • Representative pages return the correct status and canonical URL.
  • Navigation, search, forms, email, login, uploads, and integrations work.
  • Mobile layouts, keyboard access, images, and downloads are usable.
  • Analytics and consent behavior match the approved configuration.
  • Robots rules and sitemaps expose only canonical public content.
  • Backups, logs, monitoring, and administrative access are working.

Define launch and rollback

Assign who changes DNS, transfers final data, validates the site, communicates status, and decides whether to roll back. Record the condition and time limit for rollback. Keep the old environment protected and available until the new system has passed an agreed observation period.

Monitor after launch

Watch application errors, form delivery, redirects, crawl issues, traffic patterns, certificates, performance, and server capacity. Submit updated sitemaps through verified search tools. Decommission the old host only after data retention, credential removal, backup, and account closure are confirmed.

Apply this guidance to your situation.

Technical choices depend on the current environment, business goal, users, constraints, and operating responsibilities.

Start a Project

Choose whether this browser may use optional analytics storage.