A Website Migration Checklist That Protects Orders and Email

A website migration is ready to switch when the destination can run the business, the final data copy is current, and only one production environment can accept new writes. A working homepage is an early check. It does not tell you whether an order was saved, a payment callback arrived, or a customer received an email.

This tutorial covers a hosting move that keeps the same domain. WordPress and WooCommerce provide the examples, but the sequence also applies to other database-backed sites. Changing the domain, moving mailboxes, or changing DNS providers adds work; treat each as a separate part of the plan.

1. Record what must move—and what must stay

Before copying anything, build a small inventory. Use it as the migration record throughout the move.

Record the old and new server addresses, access owners, proposed window, and who can decide to pause checkout or recover. Keep credentials in the team's secure credential store, outside this checklist.

Ask the destination provider exactly what its transfer includes. A hosting-account transfer and an application-level migration have different boundaries. Review the transfer report rather than assuming that every mailbox, external integration, or custom task was included. cPanel documents its transfer workflow and limitations in the Transfer Tool guide.

2. Make a backup you can restore

Create a backup of both the application files and the database. Include uploaded media and any data stored outside the usual website directory. Record the backup timestamp and keep a copy accessible if either host becomes unavailable.

Restore that backup to the destination before the migration window. Check that the application starts and that an existing order, account and uploaded file are present. A successful backup job alone does not establish that recovery will work.

For WordPress, confirm the new database connection settings, file ownership, PHP compatibility and required extensions. When the public URL stays the same, avoid unnecessary domain replacements. If a URL does change, use a method that preserves serialized data; ordinary text replacement can corrupt stored values. The WordPress migration guide explains the different move scenarios, and WP-CLI search-replace supports a dry run before changes.

Leave a usable source copy in place while testing. Do not cancel the old hosting account yet.

3. Test the destination without sending public traffic there

Use a protected staging environment or a local hosts-file override that sends your browser to the new server while retaining the real hostname. The latter is useful for checking domain-dependent behavior. Arrange a valid certificate for that hostname before testing HTTPS.

A command-line check can confirm the destination's initial HTTPS response:

1curl.exe --resolve example.com:443:203.0.113.20 -I https://example.com/

Replace the example domain and documentation-only address with your own destination. This changes resolution for that host and port in this request; it retains the URL hostname for HTTPS. A redirect to another hostname needs its own mapping. The curl manual documents the option. A passing header request does not test login, checkout, or every page.

Protect the test copy from public access. Disable or redirect its live email, fulfillment calls, payment integrations and background workers before running tests. A copied production database may contain valid integration credentials, and a test order can still trigger real activity. WooCommerce's test-order guidance explains why staging and sandbox payments matter.

Write the expected result beside each test:

• An existing customer signs in and sees the expected account information.
• A product's price, stock and tax calculation are correct.
• A sandbox checkout records one order with the expected status and totals.
• An upload remains accessible after the request finishes.
• A contact form reaches the controlled test recipient.
• Required redirects retain the intended destination, and key pages have valid HTTPS.

Save the order identifier, timestamp and relevant log entries. “The site looks fine” is too vague to guide a cutover decision.

4. Separate mailbox delivery from website notifications

Email has two paths to check: mail delivered to your domain's mailboxes, and messages sent by the website. Moving one does not prove the other works.

If mail stays with the existing provider, retain its MX records and required authentication records. Also inspect the address records behind the mail hostname. An unchanged MX pointing to mail.example.com will still break if that hostname is moved to a web server that does not handle mail. Cloudflare's email DNS guide explains the roles of MX, mail-server addresses, SPF, DKIM and DMARC.

On a cPanel web host with external mail, confirm the domain's routing configuration with the provider. Remote Mail Exchanger routes mail away from the local server. Automatic detection uses the local DNS zone and does not continually update itself when records change, as described in cPanel Email Routing.

For website notifications, check the SMTP or mail-service configuration, sender address, authentication and notification recipients. In WooCommerce, inspect WooCommerce → Settings → Emails and the individual notification settings.

Actual screenshot from a disposable WordPress/WooCommerce demo. The default recipient is demo data. This screen shows notification settings; it does not prove delivery.

After cutover, send an external message into a real mailbox and reply to a separate external address. Test a form and an approved order notification as well. Confirm receipt, not just a successful send response in the application.

If mailboxes are moving too, plan their own initial copy, final synchronization, aliases, forwarding rules and client settings with the mail provider. During the overlap, messages may arrive at either provider. Keep both accessible until those messages are reconciled.

5. Plan the final copy around every writer

The test copy becomes stale as soon as the live site changes. Choose a final synchronization method and identify all processes that can write while it runs.

For a shop, pausing checkout is only part of the freeze. Administrator edits, imports, scheduled renewals, queue workers and payment callbacks can also change records. A payment started before maintenance may complete during it. Decide how those events will be received, queued or reconciled using the payment provider's supported process. Do not assume a maintenance page stops background requests.

Choose a migration window, then follow the agreed sequence:

1. Pause the relevant user and background writes. Record the last accepted order and the freeze time.
2. Account for in-flight payments and other outstanding events.
3. Take the final database copy and synchronize files changed since the initial transfer.
4. Verify recent orders, statuses, stock and uploads on the destination.
5. Switch traffic and activate the destination's production integrations and workers in the planned order.
6. Reopen customer writes only when the destination and callback route are ready.

Keep one authoritative production database. Two independent writable copies can accept different orders and stock changes even though both appear healthy.

The sequence is a planning model. Your application's callback handling and synchronization method determine the exact pause and reopening steps.

Review outbound webhooks separately from incoming payment callbacks. WooCommerce lists outgoing webhook configuration under Settings → Advanced → Webhooks. Check the status, topic and delivery URL, then review delivery logs when an integration fails. The WooCommerce webhook guide describes these settings and logs.

Actual demo interface; no webhook was saved or activated. This form configures outgoing WooCommerce notifications, not a payment provider's incoming callback endpoint.

6. Change only the DNS records required for the move

Export the existing zone or save a complete record list before editing. Include subdomains and verification records, not just the main website address. Cloudflare provides a DNS import and export workflow.

If the DNS provider stays the same, a web-host move may require only changes to the relevant A, AAAA or CNAME records. Check both the main domain and www, plus any stale IPv6 address that could continue sending visitors to the old host. Leave records for services staying elsewhere intact.

Lower the relevant TTL ahead of the window where supported. Allow the previous TTL to expire before expecting the lower value to help. Cached responses can keep directing visitors to the old address; there is no single instant when every resolver switches. See the DNS TTL reference.

If nameservers are changing, prepare the complete destination zone before switching delegation. Coordinate DNSSEC and registrar DS records with the DNS providers: a signing mismatch can make the domain fail validation. Follow the provider's migration procedure and verify the final state. Cloudflare's nameserver setup guide covers its DNSSEC requirements.

Keep the old host under the same write policy during cached traffic overlap. It can show maintenance or use a tested arrangement that sends requests to the new application. It must not reopen as a separate shop with an outdated database.

7. Verify business outcomes and define recovery

Check the public site through normal DNS after cutover. Repeat the important customer workflows and inspect application errors, payment events, webhook deliveries and worker activity. Compare the store's orders with the payment provider's records, including transactions around the freeze.

Define recovery before the window. Record who decides, which failures require checkout to pause, where the final backups are, and how new data will be preserved.

If the destination has accepted orders, pointing DNS back to the old server does not carry those orders with it. Pause further writes if necessary, preserve both databases, reconcile payments and new records, and use the application's supported recovery method. A failed notification may be repairable without reversing the entire move.

8. Close the move after reconciliation

Keep the old service until the agreed observation period has passed and overlapping orders, callbacks, uploads and mail have been checked. The right period depends on the site's traffic and delayed events, including scheduled renewals; one successful homepage visit is not enough.

Confirm that destination backups run and can be restored. Update the operating record, remove temporary migration access, and document any remaining task with an owner. Cancel the old account only after checking whether it still supplies mail, DNS, certificates or another dependency.

The handover should show what moved, which system now owns production writes, which tests passed, and how recovery would work. That is the evidence that the business can operate on the new host.

Documentation checked on 2 October 2026. Interface screenshots were captured from a temporary demo; no production migration or live payment was performed.