A WordPress migration does not have to begin by changing public DNS and hoping the destination works. The safer pattern is to build the destination, copy the application, validate it through another route, and make the public cutover only when the new environment is ready.
DNS should be the cutover mechanism, not the testing mechanism.
A controlled migration in five stages
Why changing DNS first is risky
If DNS is changed before the destination is proven, visitors become part of the test. Missing files, incompatible PHP versions, broken rewrites, certificate problems or database errors are discovered after traffic has already moved.
DNS caching also means a rollback is not necessarily immediate. Different resolvers can retain different answers for a period, leaving some visitors on the old environment and others on the new one.
Build the destination while production remains live
The new hosting environment can normally be provisioned independently of the current site’s public address. Match the required PHP/runtime behaviour, create the database and site boundary, then import the WordPress files and database.
The WordPress hosting architecture guide is useful here because migration compatibility is not just a PHP-version question. Web-server behaviour, rewrites, PHP extensions, filesystem permissions and database state all affect the application.
How do you view the destination before DNS changes?
You need a way to send your own request to the destination while ordinary visitors continue resolving the production hostname to the source.
Platform preview hostname
A hosting platform can expose the destination through a temporary preview hostname. This is convenient because it does not require changing the customer’s public DNS simply to inspect the imported site.
Local hostname override
A developer can override name resolution on their own workstation so the real hostname resolves to the destination IP only for that machine. This can be particularly useful for testing the exact production hostname, HTTPS and application behaviour without changing authoritative DNS.
The override must be removed after testing, otherwise that workstation can continue bypassing normal DNS after cutover.
Preview URLs and staging sites are different
A migration preview normally exposes the destination copy that is intended to become production. It does not necessarily create another staging copy.
This distinction is covered in WordPress Staging vs Preview Sites. During migration, preview is primarily about routing selected testers to the destination before public cutover.
What should you validate?
- Homepage and representative internal URLs.
- WordPress admin and authentication.
- Images, downloads and other uploaded media.
- Permalinks, redirects and
.htaccess-dependent behaviour. - Forms and application mail behaviour.
- Plugin functionality and scheduled tasks.
- PHP compatibility and error logs.
- Database-backed features such as search, accounts, orders or memberships where applicable.
- HTTPS and canonical-host behaviour for the intended production hostname.
The source may keep changing during the migration
An initial copy is only a point in time. If visitors continue creating orders, accounts, form submissions or content on the source, those changes are not magically present on the destination.
For active sites, the cutover plan therefore needs a final synchronisation step. The exact method depends on the application. A brochure site may tolerate a short content freeze and final database copy. A transactional site needs more careful handling to avoid overwriting new records.
Cutover option 1: change DNS
The conventional cutover updates the site’s DNS record to the destination address. Lowering the relevant TTL ahead of a planned migration can reduce how long compliant resolvers retain the previous answer, although it cannot make every cache on the internet update instantly.
Once public traffic is consistently reaching the destination, the old environment should normally remain available for an agreed rollback period rather than being destroyed immediately.
Cutover option 2: move the existing IP
Where the hosting architecture and network ownership allow it, another strategy is to move the site’s existing public IP address to the new environment. The authoritative DNS record then does not need to change because it still points to the same address.
This can be particularly useful during a controlled infrastructure migration where the old server can be shut down and the address reassigned to the new one. It avoids DNS propagation as a cutover variable, but it requires control of the address and careful network, ARP/routing and service configuration.
No DNS change does not mean no cutover. It means the traffic handoff occurs at the network/IP layer instead.
Certificates still matter
The destination must be able to serve the production hostname securely. A temporary preview certificate proves the preview route, not necessarily the final hostname. Certificate issuance or transfer should therefore be part of the migration plan rather than an afterthought.
Do not forget application URLs
WordPress stores URLs in the database, and plugins can store them in serialized structures. A migration between temporary and production hostnames should use WordPress-aware tooling rather than a blind text replacement.
WP-CLI can perform serialization-aware search/replace operations when needed. The SSH, SFTP and WP-CLI guide explains where WP-CLI fits in the developer workflow.
Plan rollback before cutover
A rollback plan should identify the point at which the source stops accepting writes, how traffic can be returned, and what happens to data created after cutover. Simply turning the old server back on can lose new production data if the new site has already accepted transactions.
The safer the migration, the less likely rollback becomes necessary; but the decision is much easier when the recovery path was designed before the change.
How Webcore approaches WordPress migrations
Webcore’s migration workflow is designed around preparing and validating the destination before public traffic moves. Preview access provides a way to inspect the imported site, while controlled final synchronisation and cutover keep the source authoritative until the migration is ready.
Where infrastructure allows an IP-takeover strategy, an existing address can be reassigned at cutover so public DNS remains unchanged. Where DNS must change, the same principle still applies: prove the destination first, then move traffic.
See Managed WordPress Hosting, WordPress for Developers & Agencies, or talk to Webcore about a managed migration.