Moving off WP Engine: a one-week migration plan

WP Engine is a good host. It is also expensive, and the pricing jumps hard once your traffic or site count grows, so every few months someone asks us to move them off it. The search results for this are not much help: half are WP Engine’s own pages talking you into staying, and the other half are rival hosts promising a free, magic, zero-effort migration that quietly locks you into them instead. Neither tells you what actually breaks when you leave. We move sites off WP Engine regularly, and the failures are predictable once you know where WP Engine keeps its own machinery. Here is the week we plan around it.

First decide whether you should leave at all

Leave WP Engine for cost or for control. Do not leave it because you are annoyed. It runs a genuinely fast stack, its staging and daily backups work, and its support answers. If you are on a modest site and the bill is $50 a month, moving to a $15 box to save $35 is rarely worth the risk to a site that earns you money. Where the move pays off is the account paying $300 and up, the agency juggling ten sites at plan-tier pricing, or the team that wants root access and their own server WP Engine will never give them. If that is you, keep reading. If it is not, the honest advice is to stay and renegotiate.

The WP Engine-specific things that will bite you

A WordPress site on WP Engine is not a plain WordPress site. WP Engine injects its own code, and if you copy the files naively you carry that code to a server that has no idea what to do with it. The site then throws errors or silently misbehaves. The pieces to know about:

• The must-use plugins in wp-content/mu-plugins/ (the mu-plugin.php loader and wpengine-common) run WP Engine’s platform hooks. Off their platform they are dead weight at best.
• The object-cache.php and advanced-cache.php drop-ins wire the site into EverCache, WP Engine’s caching layer. On a normal server those files point at infrastructure that does not exist, and the site breaks until you delete them.
• WP Engine’s own backup export leaves directories out by design, so it is not a clean copy of your site. This is the single most common way a DIY migration ships a site with missing files.
• Redirects, page rules, and cache exclusions you set in the WP Engine user portal live in their control panel, not in WordPress. Copy the files and database and those rules simply vanish. Write them down before you touch anything.

None of this is a reason to stay. It is just the list you work through so the site lands intact.

The one-week plan

Seven days is comfortable for most sites and leaves DNS time to settle. A small brochure site compresses to two or three; a busy shop with a large database wants the full week. Move at the pace your site needs, but keep the order.

Day 1: pick the destination and lower DNS TTL

Choose where the site is going before you export a single file, because the target shapes everything. A managed host, a plain VPS you control, or a panel like CyberPanel or cPanel each want the files laid out slightly differently. We usually put a business WordPress site on a tuned VPS with LiteSpeed, but the right answer depends on your traffic and whether you want to manage the box yourself. If you are still weighing that, we lay out the trade-offs in a cheap VPS versus managed hosting.

Then do the boring thing that saves you on cutover day: log into your DNS provider and drop the TTL on the site’s records to 300 seconds. DNS caches for as long as the TTL says, so if it is still set to a day, your cutover later in the week will drag for hours. Lowering it now means the switch propagates in minutes when you flip it.

Day 2: take a full, honest copy

Ignore WP Engine’s backup export for the migration itself. Pull the whole site: all of wp-content, the database via a real export, and anything sitting outside the WordPress root. SSH and SFTP access are available on WP Engine plans, so use them rather than a plugin that times out on a big site. Verify the copy by counting files and checking the database dumped completely. A migration that starts from a partial backup fails on day five, and you will not know why.

Day 3: rebuild on the new host and strip WP Engine’s hooks

Stand the site up on the destination server, not yet public. Import the database, drop the files in place, and then remove the WP Engine machinery: delete the EverCache drop-ins, clear out the WP Engine mu-plugins, and check wp-config.php for WP Engine constants that no longer apply. Point the site at the new database and set the correct file permissions. This is the step where a rushed migration leaves a half-configured caching plugin fighting the new server, so take your time and read what you are deleting.

Day 4: test on a temporary URL

Before any DNS changes, browse the rebuilt site through a hosts-file override or the new host’s temporary domain. Click through the real pages: forms, checkout if it is a shop, the login, a few posts, the media library. Watch for mixed-content warnings and broken image paths, which usually mean a leftover absolute URL pointing back at WP Engine. Run a search-and-replace on the database for any surviving WP Engine domain. Re-add the redirects and cache rules you wrote down on the gotchas step, this time as real server or plugin config rather than portal settings.

Day 5: cutover

With the TTL already low from day one, cutover is quick. Put the WP Engine site into a brief read-only or maintenance state so no new orders or comments land on the copy you are about to abandon, do a final database sync of anything that changed since day two, then point the DNS A record (or your CDN origin) at the new server. Because you lowered the TTL, traffic moves over in minutes, not hours. Issue a fresh SSL certificate on the new host, since the WP Engine certificate does not travel with you, and this is exactly the sort of cutover detail our WordPress migration service exists to keep boring.

Day 6-7: watch, then cancel

Do not cancel WP Engine the moment DNS flips. Leave the old site running for a couple of days while traffic fully drains to the new server and you confirm nothing regressed: check that email still sends, that scheduled posts fire, that the contact form arrives, that analytics still logs. Keep an eye on error logs on the new box. Once a clean 48 hours have passed, export one last WP Engine backup for your own archive, then cancel. Only now is the move real.

Where people get stuck

The two failure points are almost always the same: a backup that was never complete, and WP Engine’s platform code left running on a server that cannot honor it. Work the gotchas list, start from a real copy rather than the portal export, and the rest of the week is mechanical. Keep solid backups through the whole thing so a bad step is a five-minute rollback and not a lost site, which is a habit worth having regardless and one we cover in our tested WordPress backup strategy.

If you would rather hand the whole thing over, moving off WP Engine with zero downtime is a fixed-scope job we do end to end as part of our migration pack, and we stay on for a while afterward through ongoing WordPress support so the new host does not become its own project. Tell us your plan tier and traffic and we will tell you where to land.

Worried about the search side of the move rather than the downtime? The redirect layer, the DNS TTL and the staging leftovers are what actually cost traffic, and we go through each of them in our server-side guide to migrating without losing SEO.