Website migration checklist: before and after launch

1. List every component to migrate

List the domain, website files, databases and mailboxes separately. Include PHP and database versions, scheduled tasks, external API connections, payment infrastructure, licences and IP allowlists. Each item must have a clear owner and access permissions.

Leave enough time for testing and rollback before the current service expires. Do not cancel the old account just because files have been copied. Remember that a domain transfer is different from a hosting migration; in most moves, the domain can stay with the current registrar.

2. Prepare a verified backup

Back up website files and the database from as consistent a point in time as possible. Fast-changing applications require an application-appropriate method for data consistency. Check separately whether mailboxes and server configuration are included.

Store the backup separately from the old server. Verify that the archive opens, expected folders are present and the database export completed. A web panel may time out with a large database; do not mistake an incomplete file for a successful backup.

3. Test the destination before changing DNS

Configure application-supported versions, database user permissions and file permissions on the new server. If necessary, test the real domain at the new IP using a safe hosts-file method or the control panel's preview feature. A temporary test address may not fully reflect the application's URL, cookie and HTTPS behaviour.

• Do the homepage, inner pages and images load?
• Do form messages reach the correct recipient?
• Do the administration panel and user login work?
• Are file uploads and permalinks correct?
• Do scheduled jobs and API connections work?
• Has the payment workflow been verified in the provider's test environment?

Take care not to trigger emails or payment transactions for real customers during testing. Prevent search engines from indexing the test environment; add removal of the appropriate launch restrictions to the checklist.

4. Synchronise dynamic data one final time

New orders, registrations, comments or files may be created on the old site after the first copy. Decide in advance how to transfer these records to the new system. If needed, pause write operations during a short maintenance window and perform the final synchronisation.

If the WordPress URL changes, arbitrary text replacements in the database can corrupt serialised data. Use an application-appropriate tool and inspect a trial result first. Ensure the same scheduled task does not run twice on the old and new servers.

5. Carry out the DNS and email cutover

Update the verified A and, if needed, AAAA records. If changing nameservers, check that every DNS record is present in the new zone. If email stays with another provider, preserve MX, SPF, DKIM and DMARC records. Verify DS record compatibility separately if DNSSEC is enabled.

DNS caching can cause different visitors to reach different servers for a while. Plan the data-writing strategy and the old environment's behaviour during that interval. Set an appropriate cutover window based on the application's characteristics rather than assuming zero downtime.

6. Complete the post-launch checks

Recheck the HTTPS certificate, redirects, email sending and receiving, order workflow and error logs. Verify that canonical URLs, the sitemap and robots directives refer to the actual production domain. Check for redirect chains and mixed-content errors.

Before ending the old service, confirm that the migration is complete, required backups are in place and rollback is no longer needed. Remove temporary access, change shared passwords and delete test copies according to your plan. Start on our website migration page to define the scope together.

Record concrete test results before the DNS switch

You can check that the new server responds correctly for your domain while everyone else still uses the old environment. Obtain the destination IP from the new service's panel. curl --resolve connects a domain and port to your chosen IP for that command only; it does not change public DNS or your device's hosts file. The domain and TLS SNI are preserved in the HTTPS request, and certificate validation remains enabled.

Format example only: Replace example.com and 192.0.2.10 with your domain and the authorised new server IP. The new environment must have a certificate ready that covers this domain. The terminal example sends a HEAD request for headers only:

curl --resolve example.com:443:192.0.2.10 --head --max-time 15 --write-out "\nTarget IP: %{remote_ip}\n" https://example.com/

In Windows PowerShell, use curl.exe if curl is mapped to another command. Record the HTTP status and Target IP line. With a direct connection, the IP should be the new destination; on a network using an HTTP proxy, the visible IP may belong to the proxy, so the technical team must verify the test path separately. Do not disable validation to bypass a certificate error.

If the response is 301/302, inspect the Location URL. This command does not follow redirects. If the destination hostname changes to something such as www.example.com, perform a separate check explicitly selecting the new IP for that hostname and port 443 too. Usage details are in the curl project's name resolution documentation.

Limits of this check: A HEAD response or HTTP 200 alone does not prove the application works. Separately test normal page requests and functions such as login sessions, forms and file uploads in the browser using a panel preview pointing at the new environment or a hosts method prepared by the technical team. Use a test environment for operations that generate payments or notifications.

Educational example — not a real migration record:
Function: Contact form
Destination: New test environment, verified destination IP
Expected: Test submission reaches only the test recipient
Observed: Application returns success, but the test email does not arrive
Decision: DNS cutover not approved until SMTP and sending logs are reviewed

Define success as verification of the expected outcome, rather than 'no error appeared'. Use the interactive migration checklist and download its checked state as a TXT file.