What a WordPress migration actually involves
A WordPress migration is not simply copying a website from one server to another. It is a coordinated change across application files, a database, server configuration, domain records and the external services the website depends on.
The visible pages may live in WordPress, but the operating system around them is wider. DNS decides where visitors and email are sent. TLS certificates protect browser connections. Forms depend on mail delivery or third-party APIs. Analytics, consent tools, payment providers, search engines and internal workflows may all refer to the current domain or server.
This is why a plugin can report a successful copy while the business still experiences missing enquiries, broken tracking, lost email or falling search visibility. A complete migration protects the website and the responsibilities surrounding it.
Use this checklist to define what must be captured, tested, transferred and monitored before anyone changes the live destination.
Audit the existing website before moving
Start by documenting the environment that currently works. Record the hosting provider, server region, web server, PHP and database versions, active theme, must-use plugins, active plugins, scheduled jobs, caching layers and content-delivery network. Capture the WordPress Site Health report, but do not treat it as the whole inventory.
List every route into and out of the website. That includes contact and application forms, SMTP or transactional-email services, analytics, tag managers, consent platforms, payment providers, CRM connections, webhooks, embedded tools, external media, security services and any system using the WordPress REST API.
Confirm that the team controls the domain registrar, DNS zone, hosting account, WordPress administrator account, database and file access, analytics properties and third-party credentials. A migration should not begin with unresolved ownership or an account that only a former supplier can access.
Finally, establish a baseline: crawl the public site, export current URLs and status codes, save key page titles and canonical URLs, record the active sitemap and robots directives, and capture a small set of critical performance and workflow tests. The baseline tells you what the destination must preserve.
Create and test recoverable backups
A backup is valuable only when it can be restored. Create a synchronized copy of the database and website files, including uploads, themes, plugins, must-use plugins and relevant server configuration. If content or orders can change during the process, define how the final database delta will be captured before cutover.
Keep at least one copy outside the source hosting account. A backup stored only on the server being replaced does not protect the business from account suspension, disk failure or an incorrect deletion.
Restore the backup into an isolated staging environment. Confirm that WordPress loads, media is present, administrator access works and representative pages and workflows behave normally. This restoration test reveals corrupt archives, missing files, encoding problems and environment assumptions while the live site is still available.
Document the exact recovery sequence, the person responsible and the approximate restoration time. That turns a collection of files into a rollback capability.
Prepare the destination environment
Configure the destination before transferring production traffic. Match or deliberately upgrade PHP, database and server capabilities after checking compatibility with the active theme and plugins. Confirm memory limits, upload limits, rewrite rules, cron behavior, persistent caching and any image-processing or command-line dependencies.
Use a staging hostname or local host mapping so the migrated copy can be tested without changing public DNS. Prevent accidental indexing with authentication and a noindex directive, then remove both controls deliberately when the real site is live.
Install TLS support, security headers, backups, monitoring and least-privilege access on the destination. Do not postpone security until after launch: the new environment becomes public at the same moment the DNS changes.
Check that the destination can send transactional mail through the approved provider and that background tasks run as expected. A page that renders correctly does not prove the platform is operationally ready.
Preserve DNS and business email
DNS is shared infrastructure. Changing a website record without reviewing the complete zone can interrupt business email and other services that have nothing to do with WordPress.
Export or record every existing A, AAAA, CNAME, MX and TXT record before making changes. Identify which records serve the website and which protect email, verification, subdomains or third-party systems. Preserve MX records and the SPF, DKIM and DMARC configuration used by the organization’s mail provider.
Before cutover, lower the time to live for the website records when the current provider and schedule allow it. This can shorten the period in which different visitors reach different servers, but it does not create an instant global switch. Plan for propagation and keep both environments available during the transition.
After changing the web records, test the website from more than one network and verify inbound and outbound email with real recipient accounts. Do not infer email health from a working homepage. The website and mail can fail independently.
Moving the website should not put business communication at risk.
Visual Side can map the hosting, DNS, email and recovery dependencies before the live cutover is scheduled.
Protect URLs, redirects and SEO
A hosting transfer should not change public URLs. Preserve the protocol, hostname, path structure, trailing-slash behavior and canonical strategy unless a separate, planned information-architecture change is part of the project.
Compare the destination against the pre-migration crawl. Important pages should return the same successful status, canonical URL, title, description, heading structure and indexability. Existing redirects must be carried over at the server, application or edge layer where they can be managed reliably.
Check robots.txt, XML sitemaps, pagination, language alternates and structured data. Confirm that staging restrictions have not reached production and that production URLs do not point back to the staging host through canonicals, media references or internal links.
Keep the same analytics and tag-manager properties unless there is a documented reason to change them. Annotate the migration date, submit the correct sitemap and watch search-console coverage, crawl errors and organic landing pages after launch. A short-term fluctuation is possible; unexplained URL or indexation changes require investigation.
Validate forms and integrations
Test each critical workflow from the visitor’s action to the business outcome. A form is not verified when it displays a success message; it is verified when the submission is stored where expected, the correct people receive it and any CRM, automation or acknowledgement step completes.
Review contact forms, newsletter signups, account flows, payments, bookings, search, downloads, webhooks and API connections. Confirm secrets and callback URLs are configured through the destination environment rather than copied into public files.
Test failure behavior as well as the happy path. If a mail provider, payment service or API rejects a request, the user should receive an appropriate message and the team should have enough logging to diagnose what happened.
Use test-mode transactions where supported. Do not place real orders or trigger customer communication simply to prove that an integration exists.
Execute the migration with a rollback plan
Choose a cutover window based on business activity, not only team availability. Define a content freeze or final synchronization process so new posts, form entries, orders or account changes are not left behind on the old server.
Write the launch sequence before starting: final backup, final data sync, destination checks, DNS change, TLS confirmation, cache clearing, critical-path tests and monitoring. Assign one person to make the go-or-rollback decision and establish the deadline after which recovery is safer than continued live debugging.
Rollback criteria should be observable. Examples include unavailable critical pages, unresolved checkout failure, missing production data, broken business email or errors that cannot be contained within the approved window.
Keep the source environment intact and private until the destination has passed the monitoring period. Do not delete the old hosting account immediately after the first successful page load.
What to verify during the first 48 hours
Monitor availability, response errors, PHP and application logs, resource usage, certificate status and scheduled jobs. Check several geographic or network paths when DNS behavior is still changing.
Repeat the critical workflows: forms, notifications, login, search, checkout or booking, analytics events and integrations. Compare new submissions and transactions with the expected business records so silent delivery failures are caught quickly.
Review the sitemap, robots directives, canonical URLs and search-console signals. Crawl the site again and compare status codes, internal links and indexable pages with the baseline. Investigate differences rather than assuming the new host created them intentionally.
Record incidents, decisions and the final production configuration. When the monitoring window closes, take a fresh destination backup and confirm that its restoration process is documented.
Who should own the infrastructure afterward?
The business should retain durable control of the domain, DNS, hosting subscription, analytics properties and essential service accounts. Agencies and technical partners can administer those systems without becoming the only party capable of accessing them.
Document the hosting architecture, DNS records, backup policy, renewal dates, administrator roles, monitoring destinations, update process and escalation contacts. Remove temporary migration accounts and rotate credentials that were shared for the transfer.
Assign ongoing responsibility for WordPress core, plugin and theme updates; vulnerability response; backups and restore tests; uptime and certificate monitoring; form-delivery checks; performance; and periodic access reviews. Infrastructure without an owner gradually becomes a new migration risk.
A successful migration ends with a stable website, working business operations, verified recovery and clear ownership—not merely a different IP address.
Protect the website and the operations around it.
We can assess the current WordPress environment, dependencies, destination readiness and rollback path before the migration begins.