Migrate from WP Engine to self-hosted WordPress: what the work involves
If you are leaving WP Engine after a renewal, a plan or traffic tier change, or a data residency concern, the site's code and content move as-is because WordPress core is released under the GPL, and so are the plugins and themes built for it. What does not move is the hosting layer: WP Engine's platform caching, CDN, backup scheduling, staging environments and security controls must be rebuilt on infrastructure you run. Plan the migration around that split. Most of the risk sits in the infrastructure work, not in WordPress itself.
Who does this work depends on what your organization already runs. An in-house platform team that operates Linux servers, a database, a reverse proxy and a CDN can usually take it on directly. Teams without that capacity typically hire an implementation partner, and the written scope should name each hosting component being rebuilt, who operates it after go-live, and how patching is handled. Ask for the current PHP and database versions the partner will target, since the WordPress requirements page recommends PHP 8.3 or greater and MariaDB 10.11 or greater, or MySQL 8.0 or greater. Confirm the target versions in your own environment before you price the work.
The effort and risk are concentrated in four places: the database and file migration, caching and CDN configuration, backup and restore testing, and the DNS cutover. Restore a full backup into a staging copy first and test logins, forms, checkout if you run one, scheduled jobs and media. Then check plugins that WP Engine supplied or limited, such as caching or backup tools, because you must choose, configure and maintain their replacements. Background updates also change: WordPress applies automatic updates to plugins and themes only in special cases chosen by the WordPress.org API, so you need a scheduled process for reviewing and applying the rest. Define rollback steps before the DNS switch so downtime stays short if something fails.
Which WP Engine features map to self-hosted WordPress, and which need rework
This table compares each WP Engine managed feature with what the team must select, operate or rebuild on its own infrastructure. Read the status column first: clean means a like-for-like move, needs rework means configuration or code changes, and gap means the team must choose and run a replacement. WordPress core, themes and plugins move unchanged in every row, so the work sits in the surrounding platform.
| Feature | Self-hosted equivalent | Status |
|---|---|---|
| WordPress core, themes and plugins | Same GPL code installed on your own servers, with the same database and files | Clean |
| PHP and database hosting | Your own PHP 8.3 or greater and MariaDB 10.11 or greater or MySQL 8.0 or greater, per WordPress.org requirements | Needs rework |
| SSL certificates | Certificates issued and renewed by your chosen certificate authority or automation tool, configured on your web server | Needs rework |
| Platform caching | Page caching, object caching and server tuning selected and configured by your team, confirm tooling in your environment | Gap |
| CDN | A CDN provider or self-run edge layer you select, with cache rules and purge policies you define | Gap |
| Backups and restore | Scheduled file and database backups to storage you control, with restore tests you run regularly | Gap |
| Staging environments | A separate copy of the site on your infrastructure, with a sync process you design and document | Needs rework |
| Security patching | Core minor and security updates through WordPress auto-updates, plugin and theme patching handled by your team | Needs rework |
| Plugin installation and support | Plugins installed and maintained by you, with no vendor removal list, but compatibility and support are your responsibility | Needs rework |
What data to export from WP Engine and what to collect separately
A WP Engine backup covers the site files and database, but several items that keep the site working sit outside the archive. Collect the full backup inside its download window, then gather DNS, redirects, certificates, mail routing and API keys from their own sources before you cut over.
Full backup ZIP with files and database
The full backup is the primary export. It packages the WordPress files and the database into one archive that you download from the WP Engine User Portal. Download it within the 7-day window, because the archive is not kept for download after that period. Store a copy off the platform immediately, then confirm with a test restore that the database imports and the site loads on a clean server. Ask WP Engine support to confirm the current export steps for your plan, since the portal interface can change.
Seven-day download window
Plan the export before the migration date is fixed, not after. Start a full backup, confirm the archive downloads completely, and verify its size and checksum. If the download fails or is incomplete, take a new backup and repeat the process. Keep the archive as a rollback point until the new site has run through at least one full business cycle with no content or data loss.
DNS records and mail routing
DNS is not in the backup. Export every zone record from the registrar or DNS host, including A, AAAAA, CNAME, MX, TXT (SPF, DKIM and DMARC) and any records WP Engine asked you to add for its platform. Mail often runs through a separate provider, so confirm whether the MX records point elsewhere before you change anything. Lower the TTL in advance so the DNS switch propagates quickly.
Redirects and environment settings
Redirect rules, PHP settings, cron jobs and environment-specific values often live in the WP Engine dashboard or in server configuration rather than in the WordPress database. Record any redirect rules, custom headers, cache exclusions and scheduled tasks. Then recreate them in your web server or hosting panel, for example in an Nginx or Apache configuration file, and test each one against the old URLs.
SSL certificates and private keys
WP Engine manages certificates for hosted sites, and you cannot assume the private keys transfer with the archive. Plan to issue new certificates on your own server, for example through an ACME client, once DNS points to it. Confirm that the certificate covers every hostname, including www and any subdomains, and that automatic renewal works before the old platform is disabled.
Third-party API keys and secrets
Plugins that call outside services, such as payment gateways, form providers, search services, CRM connectors and SMTP relays, store their keys in the database or in wp-config.php. Verify which values the archive holds, then rotate any key that was exposed in shared admin screens or support tickets. Record each service's allowed domains and IP rules, since a new server may send requests from a different address.
The migration sequence from inventory to decommission
The sequence moves a WordPress site from WP Engine to infrastructure you control in stages, so each stage produces evidence that the next one can rely on. Nothing is decommissioned until the new environment has been tested, cut over and monitored.
Inventory plugins, themes, cron jobs and integrations
Before touching the target server, list every active plugin and theme, every scheduled task (WP-Cron or system cron), every outbound integration such as payment, email, CRM and form webhooks, and every custom mu-plugin or drop-in. Record the version, license and purpose of each item, and flag anything WP Engine provided at the platform level, such as caching drop-ins, object cache or backup tooling, that you must now supply yourself. The output is a written inventory that the site owner signs off on, and it is complete when every item has an owner and a replacement or a decision to drop it.
Build staging on the target server
Provision the target server or cloud environment with a PHP and database stack that meets WordPress.org's stated requirements (PHP 8.3 or greater, and MariaDB 10.11 or greater or MySQL 8.0 or greater), then restore the full backup ZIP you downloaded from WP Engine into it. Confirm the web server configuration, file permissions, HTTPS and the PHP extensions the inventory requires before you load the site. The output is a staging copy that loads without errors, which you verify by walking the main templates, forms and checkout paths. Confirm the exact versions your chosen hosting stack supports in its own documentation.
Run a pilot on a test hostname
Point a test hostname, which the public does not use, at the staging copy and test it as a real visitor and as an editor. Check logins, search, forms, redirects, media uploads, scheduled posts and each integration from the inventory, and compare rendered pages with the live WP Engine site for differences in content and layout. Log every defect, fix it, and repeat the pass until the defect list is empty for critical paths. The output is a pilot sign-off that names who tested what and when.
Run in parallel with DNS and cache checks
Keep WP Engine live while the new environment runs against the production data path you have chosen, and verify that content edits made during this window are either frozen or re-synced by an agreed process. Check the DNS records in the test zone, confirm that the TLS certificate is valid for the production hostname, and verify that your CDN or caching layer serves the new origin correctly, including purging rules that replace WP Engine's platform caching. The output is a short parallel-run log showing that the response, cache headers and certificate behave as expected from several networks.
Cut over with a lowered TTL and rollback plan
Lower the TTL on the production DNS records ahead of the change so resolvers pick up the new address quickly, then take a final backup from WP Engine, restore any delta into the new environment, and switch the records. Write the rollback plan before cutover: the exact DNS values that restore WP Engine, who authorizes the reversal and what data written after cutover would need to be reconciled. Watch error logs, uptime checks and analytics during the first hours. The output is a cutover record that shows the switch time, the checks passed and the rollback path still available.
Confirm backups and monitoring before decommissioning
Keep WP Engine in place as a fallback until the new environment has run long enough for your team to be satisfied. Confirm that automated backups of files and database run on the new host, that at least one restore has been tested in a separate environment, that uptime and error monitoring alert the right people, and that the update process for WordPress core, plugins and themes is written down. Only then cancel the WP Engine plan and retain the final export under your retention policy. The output is a decommission checklist with each item signed off, and it is complete when the restore test and alert test are both recorded.
How the move differs for a single site, a multisite network or a plugin-heavy store
A single brochure site is usually the simplest move. Content changes are infrequent, there is no checkout or member data to keep in sync, and the main risks are a missing media folder, a forgotten redirect or a DNS change that propagates unevenly. The cutover window can be short because the database changes little between the final backup and the switch, so you can take a fresh backup shortly before DNS moves and accept a small gap for any edits made in the meantime.
- Cutover window: Freeze editing for a short period, take a final full backup, restore it on the new server and switch DNS.
- Data sync risk: Low. Only comments, form submissions and any edits made after the final backup need to be reconciled.
- Testing effort: Check key templates, forms, the contact page, redirects and the sitemap on the new host before DNS changes.
- Plugin and cache work: Replace WP Engine's platform caching and CDN with a cache layer you run, and confirm the page cache clears on publish.
- Rollback: Keep the WP Engine site active until the new host has served traffic correctly for a period you agree on.
Before cutover, confirm with your team which forms, scheduled posts and redirects must work on day one.
A multisite network runs several sites on one WordPress installation and one database, with a shared set of plugins, themes and users. Moving it means moving every domain, mapping each domain to its site record, and confirming that the network settings, super admin accounts and shared media still resolve correctly. The cutover is usually coordinated across all domains at once, so the window is set by the slowest or most complex site rather than the average one.
- Cutover window: Plan one window for all sites, and order DNS changes so the primary network domain moves last or first as your team agrees.
- Data sync risk: Moderate. Editors on any site can change content during the window, so freeze editing across the whole network.
- Testing effort: Test each domain individually, including domain mapping, per-site logins, shared media paths and network-wide plugin settings.
- Certificates and domains: Confirm that TLS certificates cover every mapped domain before DNS changes.
- Ownership: Agree which team owns each site's content and approval after the move.
Confirm with your host or partner how the network database and per-site uploads are exported, because a single site's export may not include all of them.
A WooCommerce or membership site with live transactions has the highest data sync risk. Orders, customer accounts, subscriptions, stock levels and member records change continuously, so a backup taken before cutover can be out of date within minutes. The cutover window needs a deliberate plan for taking the store offline or into a maintenance state, capturing the final data, and confirming payment gateways, webhooks and scheduled actions point to the new server.
- Cutover window: Put the store in maintenance mode or pause checkout, take the final database backup, then restore and verify before reopening.
- Data sync risk: High. Orders placed during the gap, pending payments and subscription renewals must be reconciled against the payment provider.
- Testing effort: Run test orders through each payment gateway, check tax and shipping rules, emails, refunds and member access rules on a staging copy first.
- Integrations: Update webhook URLs, API keys, scheduled cron jobs and any outbound email settings for the new server.
- Compliance: Confirm how cardholder data is handled. Card data typically sits with the payment provider, so ask your payment processor and QA lead to confirm what your store stores locally.
Before you choose a date, ask your team to review the payment provider's requirements for changing a callback URL.
A site that relies on plugins WP Engine does not allow, such as certain caching or backup plugins, needs more upfront work. Self-hosting lets you install and configure those plugins, but each one becomes a component you must patch, monitor and test. Because WordPress is GPL, plugin code is yours to run, yet compatibility with the current WordPress release and PHP version must be verified, and plugins abandoned by their authors may need replacing.
- Cutover window: Often longer, because plugin setup, object caching and backup tooling must be configured and tested before DNS changes.
- Data sync risk: Depends on what the plugins store. Caching and backup plugins carry little data, while a plugin that writes to custom tables needs a full export check.
- Testing effort: Inventory every active plugin, check its last update date and compatibility, and test each feature it supports on staging.
- Hosting requirements: Confirm your server runs a PHP version that WordPress recommends (PHP 8.3 or greater) and a supported database version.
- Security responsibility: Plugins are not updated automatically unless the WordPress.org API flags them for critical fixes, so set a monitoring and patch process.
Confirm your plugin inventory with the vendor or maintainer for each commercial plugin before you commit to a cutover date.
What drives cost and duration in a WP Engine exit
This table lists the factors that shape the cost and timeline of leaving WP Engine, with why each one matters and how to reduce it. Read it before requesting quotes, since the largest one-time and recurring costs usually follow from the site count, custom code and compliance evidence rather than from the server itself.
| Driver | Why it changes cost or effort | How to keep it down |
|---|---|---|
| Site count and network layout | Each site needs its own install, database, backups, staging copy and DNS cutover. Multisite networks share infrastructure but multiply testing. | Group sites with similar themes and plugins, and migrate the simplest ones first to build a repeatable runbook. |
| Plugin and theme count | Each plugin needs a compatibility check, a license decision and a update owner. Plugins that WP Engine blocked or replaced may need a new choice. | Audit the active list, remove unused items and replace overlapping plugins before the move. |
| Custom code | Child themes, mu-plugins and custom plugins need PHP review, testing and ongoing maintenance under your own release process. | Document what each custom component does and keep the code in version control from day one. |
| Traffic and cache requirements | Replacing WP Engine's platform caching and CDN means sizing servers, a page cache, an object cache and a CDN for peak load, which drives both hardware and tuning time. | Measure current traffic and cache hit patterns from the existing site, then load test the new stack before cutover. |
| Integrations | Forms, CRM connectors, payment gateways, search and email services each need credentials moved, endpoints retested and failure modes checked. | List every external service and its owner, then test each one in staging with production-like data. |
| Compliance evidence needs | Assessors may ask for change records, backup restore tests, access reviews and patch logs that WP Engine's contract did not require you to produce. | Confirm early with your auditor which evidence they expect, and design logging and change tickets to produce it. |
| Team Linux and PHP skills | Teams without server administration experience will need training, a managed partner or extra time for hardening, patching and incident response. | Assess current skills honestly, and ask any partner to name who performs each operational task. |
| One-time costs | Migration work, staging setup, testing, performance tuning, security hardening and restore drills. Usually paid as project effort under a written scope. | Ask each quote to split discovery, migration, testing and hardening so you can compare scope directly. |
| Recurring costs | Servers, CDN, backups storage, monitoring tools, security patching, plugin updates and staff time. These continue for as long as the site runs. | Ask for a monthly run estimate that lists each component, its owner and its billing unit. |
Running WP Engine and the new host in parallel before cutover
Keep the WP Engine site live and authoritative until the self-hosted copy has passed functional, performance and restore testing, because the parallel period is the only safe window to find problems without visitors seeing them. Build the new environment from the full backup ZIP, then point a preview hostname or a local hosts-file entry at the new server to check pages, forms, checkout flows, redirects and the admin login. Confirm that the new host runs a currently supported stack, for example the PHP and database versions listed in the WordPress requirements, and that the WordPress core version matches the release line you intend to maintain. Do not rely on a single smoke test: exercise the plugins that matter most to revenue or lead capture, since their behavior can differ once WP Engine's platform layer is gone.
Every change made on WP Engine during the parallel period has to be reconciled, so decide early how you will handle writes. Either freeze publishing, comments, user registration and WooCommerce orders for a defined window, or accept a reconciliation step at cutover in which editors re-enter or export the changes made since the last backup. Name an owner for the freeze or reconciliation and write down which tables and uploads are in scope, such as wp-content/uploads and the posts and orders tables. A second copy of the database taken just before cutover, verified by restoring it on the new host, is what turns a risky switch into a routine one. Minimal downtime depends on this planning far more than on the DNS change itself.
Shorten the DNS TTL on the record for the site well before the planned switch, so that resolvers pick up the new address quickly once you change it. Confirm the current TTL with your DNS provider and lower it to a value your team is comfortable with, then wait at least the old TTL before cutover so caches expire. Keep the WP Engine environment running with its original DNS configuration until the new host is serving all traffic, and keep it for a rollback period you agree in advance. Also confirm that TLS certificates for the new host are issued and valid before the switch, and that redirects and canonical hostnames match the old setup so search engines and bookmarks are not disrupted.
What usually goes wrong when WordPress leaves WP Engine
Most failed WordPress moves do not fail on the main site copy. They fail on the things the old host did quietly: caching, scheduled jobs, mail, certificates and the monitoring that caught problems. Each card below names one of these gaps and the check that closes it before DNS changes.
Missing redirects break SEO
Redirects set in WP Engine's configuration, or added by plugins and legacy rules, may not exist on the new server. When URLs change or pages are removed, visitors and search engines land on 404 pages and lose the ranking signals those URLs carried. Export every redirect rule from the old environment, including any in .htaccess or the hosting panel, and recreate them on the new server. Then crawl the old sitemap against the new host and confirm each legacy URL returns a single 301 to its final destination.
Plugins that relied on platform caching
Some sites depend on WP Engine's platform-level page caching and object cache, and plugins written around them may skip their own caching or assume a persistent object cache is present. On a self-hosted server, these plugins can slow pages sharply or serve stale content once the platform layer is gone. Measure response times and database query counts on the old host first, then decide which caching layer replaces each function, such as a page cache, a Redis or Valkey object cache, and a CDN. Test logged-in and cart pages separately, since these usually bypass page caches.
Forgotten cron jobs and mail settings
WordPress runs scheduled tasks through its own cron system, which fires only when someone visits the site unless the server runs a real cron job. Backups, scheduled posts, plugin syncs and order emails can stop silently after the move. Outbound mail also changes: WP Engine's mail routing does not follow the site, so contact forms and password resets may fail. List every wp_cron event with WP-CLI, add a system cron entry that triggers wp-cron.php, and send a test message from the new host through your SMTP provider before cutover.
SSL gaps at cutover
The certificate on the old host does not move with the site. If the new server has no valid certificate for every hostname, including www, apex and any subdomains that serve assets or admin pages, browsers show warnings and mixed-content errors appear. Issue certificates on the new server before DNS changes, confirm the siteurl and home options use and search the database for hard-coded links, which search-and-replace tools handle more safely than manual edits. Set a calendar reminder for renewal, since certificate expiry is one of the most common outages after a move.
Unpatched plugins after handover
WP Engine applies platform-level protection and maintenance that a self-hosted site does not receive automatically. WordPress core updates for minor and security releases are applied by default, but plugins and themes receive automatic updates only in limited cases that WordPress.org controls. If nobody owns patching after launch, a vulnerable plugin can stay live for months. Assign one named owner for updates, define a fixed review cycle, remove plugins that are no longer maintained, and subscribe to security notices for every production plugin. Confirm which core and plugin updates your team applies automatically and which need a person to approve them.
Backups never tested with a restore
A backup file is only useful if it restores a working site. Teams often confirm that a ZIP or database dump exists but never restore it to a clean server, so missing uploads, wrong file permissions or an incompatible database version surface only during an incident. Restore the full backup to a separate staging server at least once before cutover and again on a schedule afterward. Check that the site loads, logins work, media displays, scheduled tasks run and the restored database version matches the MariaDB or MySQL version you run in production.
Questions teams ask before moving WordPress off WP Engine
Can we move our WordPress site without rebuilding it?
Yes, in most cases the site moves as the same WordPress install, with the same themes, plugins, content and database. WordPress is released under the GPLv2 or later, so the code you run on WP Engine is the same code you can run on your own servers. What changes is the hosting layer: the web server, PHP, the database, caching, the CDN, backups and deployment. Rebuilding is usually needed only when a plugin or theme depends on a WP Engine-specific feature, or when the site runs on an outdated stack. Confirm both during the inventory, before you choose a target.
What does our internal team need to provide for the move?
The team needs to own four things: a clear inventory of the site, access to the systems that will run it, a decision on who signs off on cutover, and someone who understands the business impact of downtime. The inventory should list plugins, themes, custom code, integrations such as forms, email and payments, DNS records, redirects and environment settings. Plan for the team to test the restored site with real workflows, because a technically working site can still break a checkout or a lead form. Ask your partner which of these tasks they will take on and which stay with you.
Can our own developers run the migration without outside help?
A capable team with Linux, PHP and database experience can usually handle a simple brochure site. Sites with custom code, heavy traffic, e-commerce or regulated data benefit from outside help on the parts that are easy to get wrong: caching configuration, the CDN, backup and restore testing, and the DNS cutover. Consider the ongoing load as well as the first move. Someone must apply core and plugin updates, watch logs, respond to incidents and restore backups on a schedule. If that work will sit with an internal team, confirm it has capacity before you commit to the date.
How long does a move off WP Engine take, and what drives the time?
Timing depends mostly on site complexity, not on the WordPress version. The main drivers are the number of plugins that need replacing, custom code and integrations to test, the volume of files and database content, the caching and CDN design you choose, and how many people must approve the cutover. The export is quick compared with testing. Your schedule should include a full restore test on the new host, a staging review, and a planned DNS switch with a lower TTL set in advance. Ask any partner for a written timeline tied to the scope, and ask which steps depend on your own approvals.
What happens to plugins that WP Engine disallows?
On a self-hosted server, plugins that WP Engine restricts can usually be installed, subject to their own license and to your site's performance and security needs. Two checks matter before you rely on them. First, confirm the plugin is GPL-compatible, because WordPress plugins are treated as derivative works that must also be GPL. Second, confirm it is maintained and compatible with the PHP and database versions you will run. The trade-off is that you now own the object cache, backup and security tooling those plugins once helped supply, so budget for configuring and testing them.
How does security patching change when we leave WP Engine?
WP Engine currently applies platform-level protections and patch work for you, and leaving moves that responsibility to your team or partner. WordPress core ships security fixes in bugfix releases, and the WordPress Security Team backports critical fixes to older versions as a courtesy, but only the latest version is officially supported. Automatic background updates for core are on by default for newly created sites since WordPress 5.6, while plugins and themes receive automatic updates only in special cases chosen by the WordPress.org API. That means you must monitor advisories and apply plugin updates yourself. Confirm your patch process and the server, PHP and database support windows before cutover.
Which versions and server requirements should the new host meet?
Plan for the current WordPress line and the minimum stack WordPress.org recommends. WordPress 7.1 was released on August 19, 2026, and 7.1.3 followed on October 6, 2026, with only the most recent release in the 7.1 series actively maintained. WordPress.org recommends PHP 8.3 or greater and either MariaDB 10.11 or greater or MySQL 8.0 or greater. Check your plugins against these versions before the move, because an old plugin may block a PHP upgrade. Confirm the exact versions you need in your own environment on the WordPress.org requirements and releases pages before you build the target.
What should we ask a partner to include in a quote?
Ask for a written scope that names each deliverable, in plain terms. The quote should list the inventory and plugin review, the target architecture for hosting, caching, CDN and backups, the migration and restore test, the DNS cutover plan and rollback steps, post-cutover monitoring, and handover documentation. Ask which items are one-time and which recur, such as updates, backup restore tests and support hours. Ask who holds the accounts and credentials, and how the work will be documented. DeployOpen plans, implements and documents self-hosted platforms in your own infrastructure under fixed-scope agreements, with ongoing support available as a retainer, and quotes follow from the written scope.
How DeployOpen works on this
DeployOpen plans and implements self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a WP Engine exit, we scope the work in writing first, then rebuild the site's hosting, caching, backups and staging on infrastructure you control, and hand it over with documentation.
How we scope
- Inventory the WP Engine site, including plugins, themes, custom code, multisite status and traffic profile before any work starts.
- Agree in writing which backups, DNS records, redirects and environment settings move, and who supplies each one.
- Define acceptance tests for cutover, including performance targets and rollback steps, in a fixed-scope document you approve.
How we build
- Provision the WordPress, PHP and database stack in your environment, using the supported versions listed by WordPress.org.
- Replace WP Engine's platform caching and CDN with settings you control, and review each plugin for its license and update path.
- Configure automated backups, a separate staging copy and restore tests, then document the restore procedure for your team.
How we hand over
- Deliver runbooks covering deployment, updates, backup restores, DNS switchover and rollback, written for your operations staff.
- Run a pre-cutover rehearsal and a controlled DNS change with a lower TTL, then confirm the site against the agreed acceptance tests.
- Transfer access, credentials and architecture diagrams to your team, with a record of what was built and where it runs.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, scoped separately from the migration.
- Agree in the quote who applies WordPress core and plugin updates, who monitors security advisories and what response you expect.
- Ask for a quote that names each recurring component, such as hosting, backup storage, CDN and support hours, so you can compare costs.
