A WordPress migration is not complete when the files have copied. It is complete when the new site serves the right content, forms and integrations work, search engines receive consistent signals, the domain is secure, and the team still has a practical rollback path.
This checklist helps a business prepare for a move between hosts, servers, domains, or managed platforms. If the site is active, complex, or revenue-critical, review the scope with a WordPress migration service before changing DNS.
1. Confirm ownership and access
Record who controls each part of the website before anyone starts copying data. A delayed registrar login or unknown mailbox dependency can create more risk than the file transfer itself.
- Domain registrar and DNS provider access
- Current hosting or server access
- WordPress administrator access
- Database, SFTP or SSH, and backup access
- CDN, security, analytics, tag manager, and search tools
- Form delivery, CRM, payment, shipping, membership, and API credentials
- Business email provider and active MX records
2. Create a restorable source snapshot
Keep a full copy of the source database and files before the first migration pass. A backup archive is not enough by itself: record when it was created, where it is stored, how it will be restored, and which new orders, leads, comments, or account changes could arrive after that point.
3. Build and inspect staging
Staging should use the same important software versions and enough of the real environment to expose compatibility problems. Protect it from indexing, restrict access where appropriate, and avoid sending production email or payment events during QA.
- Compare page, post, media, user, order, and form-record counts where relevant.
- Check images, downloads, menus, search, filters, and pagination.
- Test login, password recovery, forms, and transactional workflows without contacting real customers.
- Review PHP errors, browser-console errors, scheduled tasks, and integration logs.
- Inspect desktop and mobile layouts at representative widths.
4. Preserve search and URL signals
Keep working URLs unchanged whenever possible. If a redesign or domain change also alters URLs, prepare a one-to-one redirect map, update internal links, retain useful titles and descriptions, and check canonical tags, robots directives, XML sitemaps, and structured data before launch.
| Search check | Before cutover | After cutover |
|---|---|---|
| Canonical URLs | Confirm intended production URLs | Verify they do not point to staging or the old host |
| Redirects | Prepare and review the map | Test destination and status code |
| Indexing | Keep staging blocked | Confirm production pages are indexable |
| Sitemap | Generate the expected URL set | Open it and submit only after QA passes |
| Analytics | Record the current identifiers | Confirm one production implementation |
5. Plan DNS, SSL, and email separately
Lower DNS time-to-live ahead of the agreed window when appropriate. Confirm the exact web records that will change and protect unrelated mail records. Website hosting and business email often use different providers, so replacing an entire DNS zone from memory can interrupt mail even when the website launches correctly.
6. Define the content freeze and final synchronization
Choose how late-arriving content, leads, orders, or account changes will move to the new site. A brochure site may need a short edit freeze. An ecommerce or membership site may require a maintenance window, final database synchronization, or an integration-specific reconciliation step.
7. Write the cutover and rollback steps
The launch plan should name the person who approves the change, the records being edited, the verification checks, the rollback trigger, and the latest safe time to reverse the change. Do not improvise these decisions while customers are already reaching the new environment.
8. Run post-launch QA
- Homepage, priority landing pages, navigation, and legal pages
- Forms, email delivery, login, account, checkout, and integrations
- HTTPS, redirects, mixed content, robots, canonicals, and sitemap
- Images, downloads, responsive layouts, and browser-console output
- Cache behavior, scheduled jobs, backups, monitoring, and server health
- Analytics collection without generating synthetic leads or purchases
9. Retire the old environment carefully
Keep the source available through the agreed validation window. Preserve the final backup and migration notes, revoke unnecessary temporary access, update documentation, and only then cancel the old service.
Migration decision
A simple site can use this checklist internally. A site with active orders, memberships, several domains, custom integrations, uncertain ownership, malware, or a simultaneous redesign deserves a staged migration plan with a named rollback owner.
Review Aimsparkk’s WordPress migration scope or share the current site for a migration assessment.