Website Migration Checklist

A successful website migration is more than copying files. The move has to preserve the application, database, runtime, URLs, DNS, email, scheduled work, security controls, and a clean rollback path. Use this checklist for WordPress, WooCommerce, Magento, Drupal, Joomla, Laravel, Node.js, cPanel, Plesk, DirectAdmin, and custom application moves.

Do not change DNS until the destination has been tested with the real application and a recent copy of the data. A temporary URL, preview hostname, destination IP, or local hosts-file override lets you verify the move while the source remains live.

1. Source Website Inventory

• Confirm the customer owns or is authorized to move the website and related data.
• Record the application and exact version from the install folder instead of relying only on a dropdown selection.
• Measure file size, database size, inode or file count, and any directories stored outside the public web root.
• Record PHP, Node.js, Python, database, search-service, queue, cron, and extension requirements.
• List domains, subdomains, aliases, redirects, SSL certificates, DNS provider, CDN, WAF, and origin-lock settings.
• Identify ecommerce orders, form submissions, memberships, comments, and other changing data that may require a final delta sync.

2. Access And Backup

• Confirm the source route: wp-admin agent, cPanel or Plesk, SSH, SFTP, FTP, database credentials, provider export, or assisted migration.
• Create a source backup or snapshot that can be restored independently of the migration process.
• Use per-migration passwords, private keys, and tokens. Do not place reusable credentials in tickets or saved endpoint profiles.
• Check whether Cloudflare, Sucuri, a managed host, or another WAF will block the source and destination agents.
• Lower DNS TTL before the planned cutover when the DNS provider and timing allow it.

3. Destination Readiness

• Create the destination account, document root, database, database user, and required runtime version.
• Confirm available disk space, inode capacity, memory, CPU, I/O, upload limits, execution time, and database import limits.
• Install the source app version when a clean application bootstrap is required. Avoid silently upgrading during the move.
• Set file ownership and permissions for the destination user, web server, cache, uploads, logs, and writable storage paths.
• Prepare a preview hostname, temporary domain, IP route, or hosts-file test path with working HTTPS where possible.

4. Transfer And Restore

• Start the destination receiver before the source sender and verify their one-time handshake.
• Use resumable chunks and checksums for large file trees instead of one fragile archive upload.
• Export and import the database with the correct character set, collation, routines, triggers, and engine support.
• Exclude disposable caches and generated files only when the application can safely rebuild them.
• Keep transfer payloads moving directly between customer-controlled endpoints whenever the route supports it.
• Record warnings, retries, skipped files, table errors, hash mismatches, and operator actions in the migration log.

5. Pre-Cutover Testing

• Test the home page, representative internal pages, admin login, media, search, forms, uploads, redirects, and custom endpoints.
• For ecommerce, test products, cart, checkout, tax, shipping, payment callbacks, order email, and admin order access.
• Run serialized-safe URL replacement for WordPress and application-aware configuration changes for other platforms.
• Verify cron, queues, workers, scheduled tasks, webhooks, API credentials, SMTP, and third-party allowlists.
• Check browser console errors, application logs, PHP errors, database errors, mixed content, and broken assets.

6. DNS Cutover And Final Delta

• Place a write-heavy site into a short maintenance window or run a final database and uploads delta before DNS changes.
• Update the required A, AAAA, CNAME, or proxy origin records without accidentally replacing MX, SPF, DKIM, or DMARC records.
• Issue or verify the destination TLS certificate before enforcing HTTPS.
• Purge application, server, CDN, and browser-facing caches after the final domain points to the destination.
• Verify public DNS and the actual edge response from more than one network before calling the cutover complete.

7. Evidence And Rollback

Keep the source available until the acceptance window closes. Save the migration summary, source and destination checksums, database row or table checks, DNS change time, warnings, screenshots, and final test results. Rotate credentials used for the move, remove temporary WAF exceptions, restore normal TTLs, and use the post-migration checklist for the final production review.