Migration checklist

What I check before moving a WordPress website to a new host.

A hosting migration is not just copying files and a database. I first map the website, DNS, email, forms, accounts, integrations, tracking, certificates, and recent business data so the move protects what customers actually use.

99%

Job Success

Top Rated Plus

Upwork status

511

Total jobs

9.2K

Total hours

4.6

240 Upwork reviews

Inventory every dependency

I record the current host, DNS owner, domain registrar, SSL, PHP, database, email routing, forms, scheduled tasks, APIs, analytics, and any service that depends on the website.

Build and test separately

The copied site is tested on a protected destination before DNS changes, with production email, payment, and customer-facing automation controlled.

Plan the switch and rollback

The launch window defines final data sync, DNS changes, cache clearing, certificate checks, business-path testing, monitoring, and the condition for returning to the old host.

I confirm ownership and access first

Before copying anything, I confirm access to the current WordPress site, files, database, DNS provider, registrar, destination hosting, SSL controls, email provider, analytics, and any external integration. A migration should not begin with one missing account that can stop the launch.

I capture a complete source baseline

I record WordPress and PHP versions, active themes and plugins, database size, uploads, scheduled tasks, redirects, forms, user roles, ecommerce or membership data, error logs, storage use, and the important public URLs. I also test the current business journeys so the destination can be compared against a known state.

I separate website DNS from business email

Changing a website address record should not accidentally replace Google Workspace, Microsoft 365, or another email provider. I document A, AAAA, CNAME, MX, TXT, SPF, DKIM, DMARC, verification, and subdomain records before touching DNS, then change only what the migration requires.

I build the destination without exposing staging

The destination receives an independent copy of files and the database. Search indexing is blocked, caches are controlled, and production email, payment, webhooks, or customer notifications are prevented from firing during tests. The original site remains available until the destination passes review.

I test real functions before changing DNS

I check pages, menus, media, forms, login and password reset, account routes, ecommerce, scheduled jobs, API callbacks, redirects, sitemap output, canonical tags, analytics, mobile layout, and administrative editing. Testing uses safe recipients and avoids fake activity that could confuse customers.

I plan final data synchronization

For a changing website, the first copy is not the final copy. I define whether content, orders, users, inquiries, stock, bookings, or form entries can change during the move. The launch plan includes a final export, temporary freeze, selective reconciliation, or another documented method appropriate to the workload.

I switch DNS with a measured rollback path

At launch I confirm the destination backup, lower DNS risk where possible, complete the final sync, change the required records, issue or verify SSL, clear caches, and repeat the priority tests from external networks. The old environment is retained until the new path is stable and the rollback condition has passed.

Read the managed hosting incident-response guide

Proof examples

Public Aimsparkk work patterns connected to Kamran Hassan.

Managed WordPress Migration Pattern proof preview
Controlled hosting move

Managed WordPress Migration Pattern

A migration pattern that protects service pages, forms, tracking, SSL, DNS, and ongoing editing while the destination is validated.

Commerce Migration Pattern proof preview
Orders and customer data

Commerce Migration Pattern

A commerce move needs an explicit data-freeze or final-sync plan so orders, users, products, stock, subscriptions, and callbacks are not silently lost.

Technical Website Migration Pattern proof preview
Integrations and launch QA

Technical Website Migration Pattern

A technical site may depend on APIs, scheduled jobs, account routes, environment variables, redirects, and external systems that must be tested after the switch.

Work with Kamran

Bring the next serious project to a cleaner, faster website.