Moving client sites off WP Engine, in the order the work actually happens.
The real checklist is longer than "download a zip and point DNS somewhere else," and everything downstream depends on one fork you settle up front: are you staying on WordPress or rebuilding on something else. Most agencies leaving WP Engine do a straight lift-and-shift to another managed WordPress host, and that is a legitimate, well-worn path. A smaller number are leaving WordPress itself at the same time, and for those the build-toward is a managed platform like Devani Hosting, where the CMS and the hosting are not two things you keep aligned. This covers both honestly, including where each one actually leads.
Here is the whole move as an ordered checklist before any of the detail. I have shifted dozens of agency rosters between hosts over the years, WP Engine included, and the failures were never exotic. They were a forgotten MX record, a redirect map that missed the pages that mattered, or DNS flipped before SSL was live on the new side. None of it is complicated. All of it is avoidable if you work through it in order instead of rushing the day of.
- Inventory everything before you export. Every plugin and theme, WP Engine specific pieces flagged, custom code, the account's total visit and site counts, and every third-party integration wired into the site.
- Export the content cleanly. Database and wp-content, with WP Engine caching files and mu-plugins stripped out, and a proper database search-and-replace if the domain changes for testing.
- Pick a destination that fits the fork. Lift-and-shift belongs on another managed WordPress host; a rebuild is a different project with a different budget.
- Lower your DNS TTL 24 to 48 hours ahead. Drop it to about 300 seconds so the cutover propagates in minutes instead of hours if you need to undo it.
- Confirm SSL is live on the new host before you flip anything. A gap where DNS points to the new server but the certificate is not provisioned shows a security warning, which is worse than downtime.
- Build a complete 301 redirect map from an actual crawl. Every changing URL gets a server-side permanent redirect, prioritized by the pages carrying the traffic.
- Protect email before you touch the zone. Export the full DNS zone and change only what you mean to; leave MX, SPF, and DKIM records exactly as they are.
- Stage, test, cut over, and keep WP Engine alive as a rollback. Test the whole site on staging, then hold the old account for a week or two with the revert steps written down before you need them.
The reason is usually the bill, not the performance.
Worth naming plainly, because it decides what you audit first. The complaint I hear most from agencies is not WordPress performance on WP Engine, which is generally solid. It is the pricing model at scale.
WP Engine bills visit-based overages, charged in arrears rather than flagged proactively, so you often find out after the invoice lands rather than before. The bigger issue for agencies specifically is that the visitor ceiling is cumulative across every site on the account, not per site. Add a client, add their traffic, and you can trip an overage on a plan that felt comfortable a month earlier without touching your top clients' sites at all. That structure also makes white-labeling awkward: if an agency passes overage charges through, it becomes obvious which host is actually running the site, which undercuts an agency presenting itself as the sole vendor. And because the model is roughly marginal-cost per site, the hosting bill climbs steadily as the roster grows, which is exactly when a lot of agencies start pricing out alternatives.
| Tier | Roughly, per month | What it covers |
|---|---|---|
| Startup | $25 to $30 | One site, about 25,000 monthly visits |
| Professional | $50 to $55 | Three sites, about 75,000 monthly visits |
| Overage | About $2 per extra 1,000 visits | Cumulative across the whole account, billed in arrears |
Take those numbers as a rough, dated snapshot, not gospel, and monthly billing costs more than paying annually. Hosting prices change, so check the current plan page before budgeting a migration around them. None of this makes WP Engine a bad host. It is a reason agencies specifically, who add sites and traffic over time, feel the cost curve more than a single-site owner does.
Take an honest inventory before you export a single file.
This step gets skipped under time pressure, and it is the step that saves the most pain later. Five things to write down before anything moves.
Plugins, themes, and WP Engine pieces
List everything in active use and flag anything WP Engine specific. WP Engine ships its own mu-plugins (must-use plugins that load automatically) and its own page caching layer, EverCache, and neither will function once the site leaves. Both need removing or replacing, not leaving in place.
LargeFS media offload
Check whether the site uses LargeFS, WP Engine's offload of media files to Amazon S3. If it does, that media has to be pulled back down as part of the export, because a destination host will not automatically read from WP Engine's S3 bucket.
Custom code tied to the environment
Note any code that assumes WP Engine specifically: caching hooks, environment variables, or config tied to its infrastructure. This is where a developer's time is actually needed, not just a file copy.
Visit counts across the whole account
Pull current visit counts and site count for the entire account, not just the site you are focused on. If you are moving one site off an account with several others, understand what that does to the remaining sites' overage exposure too.
Third-party integrations
Analytics, a tag manager, a chat widget, a booking or scheduling embed, marketing pixels. None of these live on WP Engine specifically, but they are easy to forget in the rush and annoying to notice missing a week later when someone asks why last month's traffic report looks wrong.
WP Engine supports migration through its own plugin and through a manual process, and either can work depending on site size and complexity. The manual route exports two things: the database and the wp-content directory (themes, plugins, uploads). Before handing those files to a new host, strip out the WP Engine specific caching files and mu-plugins that will not run anywhere else, because they will either do nothing or throw errors on the new environment.
If the destination uses a different domain or subdomain during testing, run a proper search-and-replace across the database. A tool like Better Search Replace handles this correctly; a manual find-and-replace in a text editor risks corrupting the serialized PHP arrays WordPress stores in the database. Get this right before launch, not after, because a partial search-and-replace leaves broken image paths and links scattered through the site in a way that is tedious to find later.
Almost every migration that goes wrong fails on a forgotten MX record, a thin redirect map, or DNS flipped before SSL went live.
Pick the destination that actually fits the fork.
This is the part worth being honest about instead of steering toward one answer. What fits depends entirely on whether you are keeping WordPress or leaving it, and those go to different places.
Another managed WordPress host
The lift-and-shift answer, full stop.
- ✓ Kinsta, Cloudways, and Flywheel all host WordPress well, each with its own pricing model and overage structure worth comparing. See a fuller rundown of WP Engine alternatives and a direct WP Engine vs Kinsta vs Flywheel comparison.
- × You inherit the same plugin stack and update cadence you had, just on a different bill.
Your own VPS
Full control, at the cost of the maintenance.
- ✓ A real option if you are comfortable running your own caching and security stack.
- × It puts the maintenance work you were paying WP Engine for back on you or your team.
Devani Hosting
Only if you are also leaving WordPress.
- ✓ Managed infrastructure handled for you, a free tier to start, and agency tooling that puts multiple client sites in one dashboard instead of one account per site.
- × Not a lift-and-shift target: there is no one-click WP Engine to Devani importer, because it is a different CMS, not a flavor of WordPress hosting.
DNS and SSL, the part timing decides.
Once you have picked a destination and the site is live there for testing, on a temporary URL or a local hosts-file override, the cutover itself is three moves in a specific order.
Lower the TTL first
Drop your DNS TTL to around 300 seconds 24 to 48 hours before the actual cutover. A low TTL means the record change reaches visitors' resolvers quickly instead of leaving some of them on the old server for hours or a day.
Confirm SSL before you flip
Make sure SSL is fully active and valid on the new host before you change anything. A window where DNS points to the new server but the certificate is not provisioned yet shows a broken-certificate warning, which reads as a security problem rather than maintenance and is worse than a few minutes of downtime.
Raise the TTL after it holds
Once the cutover has held steady for about a week with no rollback needed, raise the TTL back to a normal value of an hour or a day. A permanently low TTL adds unnecessary DNS query load for no ongoing benefit.
Redirects are the step that decides whether the site keeps its search rankings or takes a hit it does not recover from for months. Every URL that is changing needs a server-side 301 redirect to its new location, not a JavaScript redirect and not a meta-refresh, both of which search engines treat with far less confidence than a proper 301. If the URL structure is not changing at all, same paths on a new host, redirects may be minimal beyond the domain-level cutover itself. If paths are changing, map them before launch and prioritize by traffic: the pages driving the bulk of your organic traffic, often a relatively small share of the total, have to be right on day one even if the long tail gets mapped over the following week.
Test every redirect on staging before it goes live in production. Once the new site is live and the redirects are confirmed working, submit a Change of Address in Google Search Console if the domain itself changed. Expect ranking signals to consolidate over several weeks, not instantly. That lag is normal and is not a sign something went wrong.
Three things that bite a week after the site looks fine.
The website loading is not the finish line. These are the pieces that pass the launch and then surface as an angry call days later.
Email lives in DNS, not on the host
WP Engine does not host email, so a client's Google Workspace, Microsoft 365, or transactional sender rides on MX records a hosting move does not touch on its own. The mistake is a careless full zone replacement that overwrites MX records along with the A records you meant to change. Export the full current zone, confirm exactly which records change versus which ones (MX, and usually the TXT records for SPF and DKIM) stay untouched. A day of a client's email vanishing is a far worse call than a day of a slow website.
Test the whole site on staging
Test more than the homepage before cutover. Submit every form and confirm the notifications arrive, run a full test transaction through any checkout, check desktop and mobile, and run a broken-link scan, since a partial file transfer or incomplete search-and-replace usually surfaces as broken internal links first. A quick page speed check on staging catches an obvious misconfiguration before it becomes the new host's reputation.
Keep a real rollback
Leave the WP Engine account and site active, not cancelled, for a defined window after cutover, typically a week or two, so there is somewhere to revert if something surfaces that testing missed. Keep the DNS TTL low during that window, and write down the actual revert steps, which records change back and in what order, before you need them. Figuring that out during an incident costs time you do not have.
Where Devani Hosting fits, and where it plainly does not.
I should be upfront: I work on Devani, so weigh this section knowing that. Everything above is destination-agnostic and applies whether you land on Kinsta, Cloudways, a VPS, or anywhere else that keeps you on WordPress.
Devani Hosting fits a narrower slice of this decision, and it is worth saying so before anything else: there is no one-click WP Engine to Devani importer, and there will not be one, because Devani is not a flavor of WordPress hosting. It is a different CMS, one system where the hosting and the CMS are not two separate things you keep aligned, a comparison worth reading in full at Devani Hosting vs WP Engine. A straight lift-and-shift of the existing install belongs on one of the managed WordPress hosts above, full stop.
Where it fits instead is an agency or owner leaving WP Engine who is also open to leaving WordPress itself, not just swapping which company hosts the same install. The path is exporting your WordPress content, the pages, posts, and media, and having a connected ChatGPT or Claude account recreate it on Devani through native AI editing, with no separate plugin or MCP server to configure. That is a rebuild, not a migration, and how much it is worth doing scales with how much content and custom functionality the original carries. Some sites it is worth it, others it is not, and that is a per-site call, not a universal one. What actually happens when you leave WordPress entirely is the fuller version of that tradeoff.
So the honest split is simple. If you are leaving purely because of the visit-based overages and cumulative site limits and WordPress itself is working fine, another managed WordPress host solves that with far less work than a rebuild. If you are already reconsidering WordPress, or starting a client relationship fresh instead of migrating an existing one, this is worth a look: managed infrastructure handled for you, a free tier to start on a free subdomain live in under a minute, and paid plans adding custom domains with managed SSL, more sites, more CDN storage, and agency or white-label tooling so multiple client sites sit in one dashboard instead of one account per site. If what you need is the existing WordPress site moved with its plugins and structure intact, this is the wrong tool and a WordPress host is the right answer. Devani Hosting is the right answer for the sites already headed toward a rebuild anyway.
Can you migrate a site off WP Engine yourself?
Yes, if you work through it in order. WP Engine supports both its own migration plugin and a manual export of the database and wp-content directory. The parts that actually need a developer are removing WP Engine specific mu-plugins and the EverCache layer, pulling media back down if LargeFS was in use, running a clean database search-and-replace when the domain changes, and building the redirect map and DNS zone correctly. The mechanics are well documented; the decisions and the tedium are where it goes wrong.
Does WP Engine charge you to leave?
There is no exit fee to migrate away, but keep the account active through your rollback window rather than cancelling on cutover day, so you have somewhere to revert. Watch the billing timing instead: overages are billed in arrears and the visitor ceiling is cumulative across every site on the account, so moving one site changes the overage exposure of the ones that remain.
Will migrating off WP Engine hurt my SEO?
Not if the redirect map is complete and correct. Every changing URL needs a server-side 301, never a JavaScript redirect or meta-refresh, prioritized so the pages carrying the bulk of your organic traffic are right on day one. Submit a Change of Address in Search Console if the domain itself changed, and expect ranking signals to consolidate over several weeks. Some early wobble is normal; a sustained drop usually traces to a URL that returned a 404 or a 302 instead of a clean 301.
How long does a WP Engine migration take?
It depends on the site. A clean content-only site moves in a few focused days once the redirect mapping is careful. One or two plugin-dependent features, a form with submission history or a small catalog, runs one to two weeks with rebuilding, testing, and the cutover. None of that includes the DNS propagation and the one to two week rollback window, which add calendar time without much active work. Plan the launch date around that reality rather than around when you would like to be done.
Leaving is doable. Match the destination to the fork.
If the move is a straight lift-and-shift, another managed WordPress host is the honest answer. If you are already rethinking WordPress, Devani Hosting has a free tier, so you can stand up a rebuilt site and see how it holds up before committing anything further.