Agree migration acceptance checks before moving a customer website. A successful copy operation is one milestone; acceptance should establish that the intended website, data and connected services work from the destination.
IN THIS ARTICLE
01 Define the scope and baseline
Record the source and destination, applications, domains, databases, storage, scheduled jobs and services included in the move. State whether email, DNS, domain registration, external backups and third-party integrations are part of the work. A WordPress files-and-database migration alone does not move every service associated with a domain.
Choose representative customer journeys and a point-in-time baseline. For a shop, record a recent order and test the agreed checkout route. For a membership site, include an authorised test login and protected content. Keep personal data out of the acceptance report unless it is necessary and appropriately protected.
02 Run the acceptance checks
- Confirm the destination contains the expected application files, database and required configuration. Compare significant content and recent records with the agreed migration cutoff.
- Use an appropriate preview method before public DNS changes. Check the homepage, important inner pages, navigation, media and downloads. A temporary preview URL may behave differently from the final domain, so repeat domain-dependent tests after cutover.
- Verify application URLs, redirects and HTTPS using the intended public hostname. For WordPress, review stored URLs and embedded references with tools that understand the application's data format.
- Test login, password recovery, forms, search and any customer-critical transaction. Use approved test modes for payments and external actions so acceptance does not create unintended live purchases or notifications.
- Check outgoing application mail, scheduled jobs, webhooks and other integrations against their expected destination. Ensure a remaining source copy does not also run production tasks.
- If email is in scope, test incoming and outgoing delivery, mailbox contents and the agreed client connection settings separately from website checks.
- After DNS cutover, confirm the public records reach the intended destination and test from an external connection. Record the actual observation time and any remaining cached resolution.
- Document exceptions with their impact, owner and next action. Obtain acceptance from the authorised contact against the agreed criteria.
03 Handle changes during the move
A dynamic website may receive new orders or uploads after the initial copy. Define how final changes are captured and when source writes stop. Copying an older database over an active destination can remove new records; full database replacement does not merge competing changes.
Retain the agreed recovery copy until the migration and retention requirements are satisfied. Decommission the source only after checking that it no longer owns required mail, DNS or background jobs. Record where the customer should report a post-migration issue.
Common questions
Can a homepage screenshot prove the migration is complete?
It proves only that one page rendered at that moment. Acceptance also needs the application's important workflows, recent data and included supporting services.
Should we switch DNS back immediately if one function fails?
Assess data written at each location and the scope of the failure first. An unplanned reversal can split new orders or uploads between two copies. Follow the agreed recovery plan and record any reconciliation needed.