How to Migrate From WP Engine Safely

A WP Engine automated migration can transfer much of a WordPress site's database and file content, but leaving cleanly requires more than running a migration plugin. Most hosting migration workflows automate copying; they cannot decide whether platform-specific must-use plugins, configuration values, CDN URLs, cron behavior, or custom integrations belong in the destination. Protect the source first, test the destination independently, and switch DNS only after the receiving site passes functional checks.

Before You Start: Export and Backup

Create an independent backup before relying on either host's migration workflow. It should include the database and the complete wp-content directory, particularly uploads, themes, plugins, and must-use plugins. Record the active PHP and WordPress versions, plugin inventory, DNS records, redirects, cron tasks, and any external services that restrict requests by IP address.

WP-CLI can produce a database export and archive content when shell access and local disk capacity permit:

wp db export pre-migration.sql
wp plugin list --format=csv > plugin-inventory.csv
tar -czf wp-content-pre-migration.tar.gz wp-content

Download the outputs to protected storage and verify that the archive opens. Avoid leaving a database dump in a publicly served directory, because it may contain password hashes, customer records, API configuration, and private content. Remove the server-side copy after confirming the independent backup.

Take note of dynamic data. Orders, form entries, comments, account changes, and content edits made after the initial copy must be synchronized or briefly paused during final cutover. A low-traffic brochure site may need only a final database refresh; a busy store requires a migration plan that avoids overwriting new transactions.

Review your access before scheduling anything. You should control the domain registrar or authoritative DNS account, have WordPress administrator access, and know who can approve a content freeze or DNS change. If email uses the same domain, preserve its MX, SPF, DKIM, and verification records exactly; moving the website does not require moving email.

Lower Your DNS TTL Early

Lower the TTL on the website records several days before cutover, ideally before the old value's cache lifetime begins to matter. A shorter TTL asks recursive DNS resolvers to refresh the record sooner. It does not force every resolver or browser to discard an already cached response immediately.

An illustrative zone record might be:

www.example.com. 300 IN CNAME destination.example.net.
example.com.     300 IN A     203.0.113.20

The names and addresses are examples only. Confirm whether the destination expects an A, AAAA, CNAME, or provider-specific apex record. Do not delete unrelated mail or verification records. After the migration is stable, raise the website TTL to your normal operational value.

What Commonly Breaks When Leaving WP Engine

The following are verification categories, not claims that every WP Engine site contains the same implementation. The site's age, plugins, custom code, and enabled platform features determine what needs attention. A factual feature comparison at Nova versus WP Engine can help frame the hosting decision separately from the migration mechanics.

Platform-specific must-use plugins

Managed platforms commonly place integration, caching, or administrative code in wp-content/mu-plugins. WP Engine sites may include must-use plugins that support its platform. Those components may be unnecessary or unavailable on another host, and blindly copying them can preserve code that expects services or files found only in the source environment.

Inventory the directory, compare it with the destination's requirements, and let the receiving team determine what should remain. Also search custom code and stored options for explicit references. Removing a file without cleaning a dependent custom call can produce a fatal error; keeping an incompatible file can do the same.

Environment-specific configuration

Custom wp-config.php files and application code sometimes rely on host-provided constants, environment identifiers, filesystem paths, trusted proxy behavior, or environment variables. The receiving host will have its own database credentials, cache endpoint, salts, proxy configuration, and possibly different paths.

Do not transplant the source configuration wholesale over a destination-generated file. Compare the files deliberately. Preserve portable application settings while translating or removing host-specific values. Confirm environment detection in custom deployment code so production does not accidentally load development keys or disable scheduled jobs.

CDN and asset URLs

WP Engine can provide a CDN layer, and a site may also contain plugin-managed CDN configuration or rewritten asset URLs. After moving, a stale CDN hostname, purge integration, or rewrite rule can cause missing images, blocked fonts, redirect loops, or assets served from an endpoint you no longer control.

Inspect page source and browser network requests on the destination. Search the database carefully for the old asset hostname, but use a serialization-aware WordPress search-and-replace tool rather than a raw SQL replacement. Configure the new CDN or origin behavior first, then purge every cache layer after changing URLs.

Test the Destination Before Cutover

The destination should be tested while public DNS still points to WP Engine. Use a temporary hostname supplied by the new host or a local hosts-file override that maps the production domain to the new address. Using the real hostname during testing is valuable because WordPress redirects, cookies, TLS, and absolute URLs can behave differently under a temporary domain.

Check the homepage, representative content, administrator login, media, search, forms, scheduled actions, transactional email, API callbacks, and any purchase or membership journey. Confirm canonical URLs and robots directives. Review PHP and web-server logs rather than relying only on visual inspection.

Compare the migrated database and uploads with the source, then plan the final synchronization of changing data. Freeze only the operations that cannot be merged safely, keep that window short, and communicate it to editors or store operators.

DNS Cutover

Immediately before cutover, take or confirm the final restore point and synchronize approved changes. Verify that the destination serves the correct site and certificate, then replace only the necessary website DNS records. Watch authoritative DNS answers as well as results from more than one network.

During the overlap, requests may reach either platform. Avoid making independent edits in both copies. Monitor error logs, forms, checkout, login, scheduled tasks, and external callbacks. Keep the old environment available until DNS caches have aged out and the new site has completed an agreed observation period. Do not cancel the source first and hope the export is sufficient.

How Nova's Free Migration Works

Nova includes a free, team-led, zero-downtime migration on every plan, typically completed within 24-48 hours for a standard WordPress site. The team moves the database, files, and plugins, adapts configuration, configures SSL, verifies the destination, and coordinates DNS cutover with you. That process is part of managed WordPress hosting, not a migration plugin handed off without review.

How Nova Handles This

Nova's team coordinates the migration and cutover, then runs the site in an isolated Kubernetes namespace with Traefik and WAF ingress and daily automated GCS backups; WordPress support remains available after launch.

FAQ

Can a migration plugin move everything automatically?

It can usually copy standard database and file content, but it cannot reliably judge custom integrations, platform-specific code, DNS, external callbacks, or the safest final synchronization strategy. Manual verification remains necessary.

Will changing website DNS affect my email?

Not if you change only the intended web records and preserve mail-related records. Record the full zone beforehand and avoid altering MX, SPF, DKIM, or mail verification entries unless email is also being migrated.

Should I delete WP Engine must-use plugins first?

Not from the live source as a first step. Inventory them, test their removal or replacement on the destination, and check for dependent custom code or options before changing production.

When can I cancel the old hosting account?

Wait until DNS caches have aged out, the destination has been monitored, dynamic features work, and independent backups are secure. Confirm any contractual or billing requirements directly with the source provider.