Website migration checklist for small businesses.

1. Inventory what is moving

“Move the website” can mean different things. The website files and database may be separate from DNS, domain registration, email, form delivery, analytics, a content-delivery network, or paid software. Write down the boundary before requesting a migration.

• Record the current domain registrar, DNS provider, web host, control panel, website platform, runtime versions, database, storage used, and traffic pattern.
• List every domain and subdomain, including staging, forms, APIs, downloads, and redirects.
• Export current DNS records and identify records used for website traffic, email, domain verification, and third-party tools.
• List mailboxes, aliases, forwarding rules, mailing services, and form recipients. A website migration does not automatically include mailbox data.
• Identify scheduled jobs, server rules, environment values, certificates, caching, security tools, external storage, and licensed plugins or themes.
• Capture a current URL list, redirect list, crawl result, important search data, and a small set of representative performance measurements.

2. Prepare a backup and rollback path

A copy is not proven merely because a backup tool reports success. Preserve the original site, then verify that the files, database, configuration, and any required media are present and readable.

• Take a dated backup before migration work and another after the final content freeze when the site changes frequently.
• Store the backup separately from the server being changed and confirm who can retrieve it.
• Document how the current site can remain available or be restored if the new setup fails.
• Set a change freeze for content, orders, memberships, bookings, or other changing data. If a freeze is impossible, define how final data will be synchronized.
• Agree on the maximum acceptable interruption, the person who can approve rollback, and the point after which the old system must remain available.

Sites with orders, accounts, subscriptions, or frequently changing records need a migration plan designed for that data. A basic file-and-database copy may not be enough.

3. Copy the site to a controlled test location

Use a staging address, local host mapping, or another access-controlled method to test the destination before public DNS points to it. Keep staging out of search results and prevent it from sending real customer mail by mistake.

• Match supported runtime, database, extension, and server requirements before importing the site.
• Copy files and data, then update only the configuration needed for the destination.
• Check page layouts, media, navigation, search, login, forms, downloads, redirects, and platform-specific features.
• Test clean URLs, case sensitivity, file permissions, scheduled tasks, cache behavior, and large uploads where relevant.
• Use safe test recipients or a mail-capture method so staging does not contact real customers.
• Compare important page titles, canonical URLs, robots rules, structured data, status codes, internal links, and image paths with the approved source site.

Plan URL changes explicitly

If URLs must change, map each useful old URL to the closest new equivalent. Test permanent redirects without loops or long chains. Do not redirect unrelated removed content to the homepage merely to avoid a 404 response.

4. Control DNS and the changeover

DNS changes can take time to be seen by every resolver. Lowering a record's time-to-live in advance can help, but existing cached values may remain until their prior lifetime expires.

1. Confirm the final destination address, certificate plan, preferred hostname, and exact records that will change.
2. Preserve mail and verification records unless their owners have approved a change.
3. Take the final backup or data synchronization after the agreed content freeze.
4. Apply the smallest necessary DNS change and record the old and new values with a timestamp.
5. Issue or verify HTTPS on the public hostname and confirm alternate hostname and HTTP redirects.
6. Keep the previous hosting available through the agreed observation and rollback window.

Changing name servers has a wider effect than changing one website record. Use it only when the complete DNS zone has been reviewed and reproduced, including email-related records.

5. Verify the public site from more than one path

• Check DNS results and the certificate from a connection that is not relying on the project computer's local override.
• Open the homepage, representative pages, administrator route, important files, the 404 page, and redirected old URLs.
• Submit forms and verify delivery to the real destination mailbox. Check success, validation, and controlled failure behavior.
• Confirm email delivery records were not lost and that website-generated messages use the approved sender and reply route.
• Crawl the public site for broken links, unexpected redirects, missing assets, wrong canonicals, accidental noindex rules, and staging references.
• Compare key performance and error logs with the baseline. Investigate meaningful changes instead of assuming the new server is always faster.

6. Watch the site, then close the old service carefully

Do not cancel the old host as soon as the homepage opens. Complete the observation period, verify changing data, forms, email, logs, backups, and search access, then obtain the account owner's approval.

• Save the migration record: scope, backups, DNS changes, URL map, tests, issues, approvals, and new ownership details.
• Update monitoring, backup jobs, renewal records, license records, and support documentation for the new environment.
• Remove temporary access, staging mail overrides, debug settings, unused copies, and migration accounts according to the agreed retention plan.
• Cancel the old service only after needed files and records are exported, the rollback window has ended, and the owner confirms it.