Which fits a WordPress site that has outgrown or must leave WP Engine
The right answer depends on what forced the question. A renewal notice, a move to a higher plan or traffic tier, a plugin that the host will not allow, or a data residency requirement each points in a different direction. WP Engine fits teams that want the vendor to handle hosting, platform caching, backups, staging and platform patching, so the internal team can focus on content and features. Self-hosted WordPress fits teams that need control over plugins and server configuration, want to choose where data physically lives, or expect lower cost per visit at higher traffic, and that have either staff to run operations or a partner under contract to do it.
Four decisions usually settle the question. The first is operating capacity: who will apply updates, watch uptime, respond to incidents and restore backups at 2 a.m., and whether that person or partner is already on the payroll. The second is required plugins: list every plugin the site depends on, including caching, backup and security tools, and check which ones the current host restricts. The third is data location: confirm with legal and compliance where personal data, backups and logs may be stored, because self-hosting lets you choose the region, but you must then document it. The fourth is monitoring: decide what uptime, error and security alerts you need and who receives them. Ask your current host in writing which plugins are restricted and what the platform patches, so the comparison rests on facts, not assumptions.
Self-hosting also keeps the GPL terms in view. WordPress is licensed under GPLv2 or later, so the code you run can be moved between hosts without a license negotiation, but the security work moves with it. Check the supported PHP and database versions in the WordPress requirements page before choosing a server image, and confirm that your chosen partner will track the current WordPress release line and its security fixes. If the answer to any of these questions is unclear, treat the migration as a scoping exercise first and a hosting purchase second.
Which option fits which scenario
This table matches common WP Engine situations to the option that usually fits better, with the condition under which each fit holds. Read each row against your own traffic, plugin list, data rules and staffing, because a fit that holds for one team can fail for another.
| Scenario | Better fit | Why and the condition it depends on |
|---|---|---|
| Small brochure site with no custom plugins | WP Engine, unless cost of your own operations is higher | Few moving parts means little to patch and little to tune. The fit holds if you do not have an in-house person who can take on updates, backups and uptime monitoring on a recurring basis. |
| Site that depends on plugins WP Engine restricts | Self-hosted WordPress | Plugins that WP Engine removes for platform reasons, such as some caching and backup tools, can run on your own servers. The fit holds only if you accept responsibility for testing each plugin and its performance impact. |
| Regulated organization needing control over data location | Self-hosted WordPress in infrastructure you choose | You decide the region, network boundaries and access paths. The fit holds only if your assessor accepts the hosting location, backup copies and administrator access you document, so confirm those requirements before deciding. |
| Team with no operations staff | WP Engine, or self-hosting with a managed partner | Patching, backups, PHP and database upgrades and incident response become your job without a platform team. The fit holds if you can fund a retainer or contract that covers those tasks in writing. |
| High-traffic site with predictable load | Self-hosted WordPress on capacity you size and reserve | Predictable load lets you size servers, caching and a CDN once and review them periodically. The fit holds if you have capacity planning and load testing in place, because a cost model based on visits can change sharply with traffic growth. |
| Agency managing many client sites | Self-hosted WordPress with shared standards and a deployment pipeline | Common hosting, backup and update routines spread the operating effort across sites. The fit holds if each client's data, plugins and access are kept separate and the agency has documented responsibilities for each site. |
What WP Engine handles today and who takes it over
Leaving WP Engine moves a set of duties that the platform performs quietly today. Map each one to an owner before you cut over. Page and object caching, including the platform caching layer and any CDN in front of the site, must be rebuilt by your team, your host or a partner, and you should confirm which layers the new host provides. Scheduled backups, staging environments, server patching, and web application firewall or malware monitoring also need a named owner. Support is the duty most often underestimated: WP Engine's ticket queue is replaced by whoever you contract for on-call response. Write this as a responsibility matrix with one owner per row, and ask each candidate host to confirm in writing which rows they cover.
WordPress core still needs a decision on update timing even when a host patches the operating system and PHP. WordPress 7.1 was released on August 19, 2026, and 7.1.3 followed on October 6, 2026, according to the WordPress.org releases archive. That archive also says only the most recent release in the 7.1 series is actively maintained, so a site that stays on an older 7.1 point release stops receiving routine fixes. Decide who tests a new release against your themes and plugins, how long a staging copy is kept for that test, and who approves the production update. Automatic background updates handle minor and security releases by default, and the WordPress advanced administration handbook covers how major release updates are configured, so confirm those settings on the new server rather than assuming they carried over.
Plugin and theme updates need a separate decision because WordPress applies automatic plugin and theme updates by default only in special cases that the WordPress.org API determines, and the WordPress Security Team controls that process for critical vulnerabilities. Everything else is your responsibility once you leave a managed platform. Assign an owner for reviewing plugin advisories, decide which plugins may update automatically, and confirm that the Web Application Firewall rules or malware scanner you choose can block exploits while a patch is pending. Ask your host or partner to show a restore from a recent backup onto a staging copy before cutover, so the backup duty is proven rather than assumed.
Where plugin freedom and data control matter
WP Engine restricts which plugins run and how the platform is configured, and it hosts the data in its own environments. Self-hosting removes those limits, but each freedom moves a specific task to your team or your partner. The cards below pair each advantage with the condition under which it matters and the work it brings.
Plugin choice under GPL
WordPress is released under GPLv2 or later, and the project treats plugins and themes as derivative works that must also be GPL. That licence lets you install any compatible plugin on your own server, including caching, backup or security tools that a managed host may not allow. The freedom matters most when your site depends on a plugin WP Engine does not permit. Before you migrate, list every active plugin, confirm its licence and check its update history, because each one becomes your team's responsibility to patch and test.
PHP and server configuration control
On your own infrastructure you choose the PHP version, extensions, memory limits, object cache and web server settings. WordPress.org recommends PHP 8.3 or greater and MariaDB 10.11 or greater or MySQL 8.0 or greater, so you can match those minimums or go higher. This control matters when your application needs a specific extension or a custom rewrite rule. The responsibility is that every setting is now yours to document, version and test after each change.
Data location and hosting choice
Self-hosting lets you decide which cloud account, region or data center holds the database, uploads and backups. This matters when a contract, internal policy or regulator requires data to stay in a named jurisdiction or on infrastructure your organization controls. Confirm with your legal and privacy teams where personal data, logs and backups must reside, then check that your chosen host and backup target meet those terms. DeployOpen can prepare the hosting design and evidence, but compliance determinations rest with your auditors and counsel.
Full database and backup access
On a self-hosted stack you hold the complete database dump, uploads directory and retention schedule, with no export window set by a vendor. WP Engine's backup and download windows are its own rules, so reviewing them against your recovery objectives is worth the time. Ask whether you need point-in-time recovery, offsite copies and restore tests, since these now run on your schedule. The responsibility is that a backup you have never restored is not a tested backup.
Patching and update ownership
WordPress applies automatic background updates for core, and since WordPress 5.6 new sites have automatic major release updates enabled by default. Plugin and theme updates happen automatically only in special cases chosen by the WordPress.org API, so most plugin patches still need a person to apply them. Only the latest release is officially supported, though the Security Team backports critical fixes to older versions as a courtesy. Set a patch window, a staging test step and an owner for every plugin, because on self-hosting this work no longer sits with the host.
Operating and monitoring responsibility
Each freedom above carries operating work that a managed host previously absorbed, including server hardening, uptime monitoring, log review, incident response and capacity planning. The condition that makes this worth taking on is a team that can staff those duties or a partner under a written scope that covers them. Confirm who responds at night, what the response time is and how security findings reach the people who fix them. Without those answers, the freedom to choose plugins and hosts can become exposure rather than control.
Why the GPL makes self-hosting possible
WordPress is released under the GPLv2 or later, and that license is the reason a WP Engine site can run on infrastructure you choose. The WordPress license page explains that the project is distributed under the GPL from the Free Software Foundation. The WordPress project also treats plugins and themes as derivative works that must carry a GPL-compatible license. In practice, the core files, the premium plugins your site depends on and the themes you have customized are all code you are entitled to copy, install and run on your own servers. Before you leave, confirm the license of each plugin and theme in your installation, because the GPL applies to the code you received, and a vendor's terms for its hosted service or support plan are separate documents.
The GPL does not oblige a site operator to publish code that is used only to run a website internally. The Drupal.org licensing page describes the same principle for Drupal and its contributed projects. For a WordPress site, this means that custom code you write for your own business, such as a checkout integration or an internal reporting plugin, does not have to be released to the public just because it runs on your servers. Ask your legal or licensing team to confirm how this applies to any code you have had a vendor build for you, since the contract may say more than the license does.
WordPress is not an open-core product. There is no paid Enterprise edition hidden behind a feature gate, so you do not need to buy a license tier to host the same core software yourself. Your costs move to what you pay for infrastructure, backups, monitoring, patching and the people who run them, which the cost section of this page covers. The license decision is therefore simple, but the operating decision is not. Confirm that every commercial plugin you rely on has a license that allows use on your own hosting, and check that its updates are available to you outside the WP Engine environment.
What each option costs and what drives it
WP Engine bundles hosting, caching, CDN, backups and updates into a plan that scales with traffic and storage. Self-hosting splits those same components into servers, storage, delivery and labour that your team or a partner pays for directly. The cards below show who pays for each component, what recurs, and what to ask for before you compare totals.
Platform or plan fees
WP Engine charges by plan, with tiers tied to traffic, storage and sites. Those tiers are the recurring line most teams track at renewal, so check which limit your site would hit first. Self-hosting removes the platform fee but replaces it with compute, storage and delivery bills that you pay directly. Ask WP Engine which tier your traffic and storage map to, and whether overage terms apply.
Servers or cloud compute
On WP Engine, the host sizes and runs PHP and database capacity for you. Self-hosted WordPress needs PHP 8.3 or greater and MariaDB 10.11 or greater, or MySQL 8.0 or greater, on servers you choose and patch. Cost grows with peak load, redundancy and the number of environments. Confirm whether your estimate covers a second node for failover and how the instance size was sized against real traffic.
CDN and edge caching
WP Engine includes platform caching and a CDN as part of the hosting plan, and it tunes those layers for WordPress. Self-hosted sites need a CDN contract or a self-managed cache such as a reverse proxy, with its own per-request or per-gigabyte charges. Model delivery cost against your media volume and your cache hit ratio, which you should measure before committing. Ask any CDN vendor for their egress pricing in writing.
Backup storage and retention
WP Engine's backups come with the plan, and its retention window is part of the service terms. On your own infrastructure, backups are a separate recurring cost: object storage for database dumps and file archives, plus the cost of keeping copies offsite. Retention length drives storage cost more than anything else in this line. Ask for restore tests to be scoped and priced, since a backup you have never restored is not yet a recovery plan.
Staging and development environments
WP Engine provides staging environments within its plans, and the number available depends on the tier you buy. Self-hosted staging means a second copy of compute, database and storage, plus a process to sync content and plugins between environments. The recurring cost is usually the duplicate infrastructure and the time spent keeping staging current. Confirm whether your team needs more than one staging copy before you size the environment.
Monitoring, updates and testing labour
WP Engine's operations team watches uptime and applies platform-level fixes. Self-hosting moves that work to your team: uptime monitoring, log review, WordPress core and plugin updates, and regression testing before each release. Core security fixes are backported to older branches, but plugin and theme updates still need your review. This labour is recurring and is often the largest line in a self-hosting comparison, so ask for it as hours per month, not as a lump sum.
Support and migration project fees
WP Engine's support is included in the plan, so its cost is already in your subscription. Self-hosting shifts support to in-house staff or a partner, and migration is a one-time project on top of the run cost. A fixed-scope migration quote should list the site inventory, the cutover plan, DNS work, redirect mapping and post-move monitoring. DeployOpen agrees scope, deliverables and timelines in writing before work starts, so ask any provider to do the same.
How a move from WP Engine to self-hosted WordPress is sequenced
The sequence secures a complete copy of the site first, then rebuilds it on infrastructure you control, proves it works, and only then moves live traffic with a way back. Each step closes with a check, so the cutover happens on evidence rather than assumption.
Take and verify a full backup first
Before anything else, download a full backup of files and database from WP Engine while the export is still available. Confirm the backup download window and retention period with WP Engine directly, since these set how long you have to act. Store the archive somewhere separate from WP Engine. The step is done when you have a complete archive, you know its checksum, and someone other than the person who downloaded it has confirmed it opens and contains the database dump and uploads folder.
Inventory plugins and third-party integrations
List every active plugin, theme, mu-plugin and drop-in in the backup, and note which ones WP Engine provided or configured at platform level, such as caching, object cache, CDN and backup tooling. Record every external service the site calls, including payment, forms, email delivery, search and analytics, along with the DNS records, redirects and environment settings that live outside the archive. The step is done when this inventory is a written list that each owner has reviewed and marked keep, replace or retire.
Build the target environment
Provision the server or container platform that will run the site, using PHP 8.3 or greater and a database version that WordPress.org lists as supported, which is MariaDB 10.11 or greater or MySQL 8.0 or greater. Confirm these requirements against the current WordPress.org requirements page before you build. Configure web server, TLS, file permissions and outbound mail. The step is done when a blank WordPress install runs on the target stack and the team has a documented build that can be repeated.
Restore and test the site
Restore the database and files into a staging copy on the new environment and update the site URL settings for that address. Walk through key templates, forms, checkout or login flows, search, scheduled tasks and every integration from the inventory. Replace any platform-level caching, CDN or backup function with a self-managed equivalent before testing performance. The step is done when the test checklist passes, with each failure logged and resolved, and the staging site is signed off by the content and technical owners.
Cut over DNS with a rollback plan
Lower DNS record time-to-live values ahead of the change, if your DNS provider allows it, then point the domain to the new environment during a planned window. Keep WP Engine running until the new site is confirmed live, and write down the exact DNS values that restore the original configuration. Re-check redirects, certificates and email records after the switch. The step is done when production traffic reaches the new site, the rollback steps have been rehearsed, and the old platform is kept in place until the team confirms it is no longer needed.
Set up backups, monitoring and updates
Configure scheduled database and file backups to a location you control, and run a test restore on a schedule. Add uptime, error and certificate monitoring, and set alerts to a named on-call owner. Define an update policy covering WordPress core, plugins and themes, with a staging step before production. Note that WordPress applies automatic updates to plugins and themes only in special cases chosen through the WordPress.org API, so you need your own patch process. The step is done when a restore has been tested, alerts reach a person, and the update policy is written and assigned.
Questions buyers ask before switching from WP Engine
How much more effort is self-hosting WordPress than staying on WP Engine?
Self-hosting moves work that WP Engine currently handles onto your team or a partner: server provisioning, platform caching and CDN configuration, backup scheduling, staging environments, uptime monitoring and security patch oversight. The WordPress core code is the same either way, so the content, themes and plugins do not change. The effort is mostly operational and recurring, and it grows with traffic peaks, the number of sites and the strictness of your uptime and recovery requirements. Ask any proposal to list each managed function on WP Engine and who performs it afterward.
What skills does the internal team need to run WordPress on its own servers?
The team needs to operate a Linux web stack that meets current WordPress requirements. The WordPress.org requirements page recommends PHP 8.3 or greater and either MariaDB 10.11 or greater or MySQL 8.0 or greater. In practice that means someone who can manage web servers, PHP versions, database backups and restores, DNS, TLS certificates, a CDN and firewall rules, and who can read logs when something breaks. Staging, change control and a documented rollback procedure are also expected skills, not optional extras.
Can our team migrate and run WordPress without an outside partner?
Yes, if your team already runs production web infrastructure and has someone who owns the on-call and patching duties. A partner becomes useful when the team lacks those skills, cannot staff the recurring work, or needs the migration finished inside a fixed window. Whichever path you choose, confirm who restores a backup in a test environment before cutover, because an untested backup is not a recovery plan. DeployOpen plans, implements, hardens, backs up, upgrades and documents self-hosted platforms in your own infrastructure, under a written, fixed scope for most engagements, and offers ongoing support as a retainer.
How long does a WordPress migration off WP Engine take?
No duration figure is available for this migration, and the length depends on the site. The main drivers are the size of the database and media library, how many plugins and custom integrations need rework, how much platform-specific caching or redirect logic must be rebuilt, the number of environments, and how much DNS cutover planning is needed to keep downtime low. Ask any provider for a written scope that lists each of these items and the deliverables that close the migration, rather than a single estimate.
What happens to plugins that WP Engine restricts after we self-host?
On your own servers you decide which plugins run, so plugins that WP Engine disallows can be installed if they fit your requirements. WordPress is released under GPLv2 or later, and the WordPress project treats plugins and themes as derivative works that must also be GPL, so the code remains yours to inspect and run. The tradeoff is that you own compatibility testing, updates and the performance and security effects of every plugin. Inventory your plugins, check their maintenance status and test them on staging before cutover.
How does security patching change when we leave WP Engine?
Patching becomes your responsibility, with the WordPress project supplying the fixes. The WordPress Security Team fixes responsibly disclosed vulnerabilities in bugfix releases and backports critical fixes to older versions as a courtesy. Automatic background updates exist, and since WordPress 5.6 new sites have automatic major release updates enabled by default. However, by default WordPress applies automatic plugin and theme updates only in special cases that the WordPress.org API determines, so your team must watch plugin advisories, apply updates, and run a web application firewall and monitoring that WP Engine may currently provide. Confirm which of these functions you will own in writing.
Does self-hosting WordPress actually reduce our hosting cost?
It can, but only after you count every component. WP Engine's bill covers hosting, platform caching, CDN, backups and vendor-run operations as a bundle. Self-hosting replaces that bundle with separate lines for servers or cloud capacity, CDN, backup storage, monitoring, security tooling and the staff time or partner fees to run them. Costs that recur include infrastructure, licenses for any paid tools, and ongoing maintenance. Costs that are one-time include the migration and the initial hardening. Ask for a quote that shows each component, its owner and what would change its price as traffic grows.
How to decide with a partner's help
A partner can turn the move into a fixed-scope written plan that covers four parts: an inventory of the site, a target architecture, the migration itself and the run model that follows. The inventory should list every plugin, theme, custom code path, cron job, email route, redirect and third-party integration, because WP Engine's platform handles several of these invisibly. The target architecture then decides where caching, the CDN, object storage for uploads, database backups and the staging copy will live. Ask for the plan, deliverables and timeline in writing before work starts. Ongoing support, upgrades and continuous testing can be set up as separate retainers, so the one-time build and the recurring run are priced and reviewed as two different decisions.
Bring four inputs to the first scoping call: your traffic profile, your plugin list, your compliance requirements and your internal staffing. Traffic profile means peak and typical visits, the share of logged-in or commerce traffic that cannot be cached, and any seasonal spikes, since these drive server sizing and CDN configuration. The plugin list should include versions, licenses and any plugin WP Engine restricted, so the partner can plan replacements. Compliance requirements, such as data residency or the controls your auditors will test, determine where backups are stored and who can read them. Internal staffing answers the question of who patches WordPress core and plugins, reviews alerts and restores a backup. Confirm these answers with your own teams before the call, because a plan built on guessed staffing will underestimate the run work.
How DeployOpen helps with a WordPress move
DeployOpen plans and implements self-hosted WordPress inside your own cloud accounts, data centers or private networks. We start from a written scope for your WP Engine site, then rebuild the hosting, caching, backups, staging and update routine so your team can run it after handover.
How we scope
- Inventory every WP Engine feature the site relies on, including caching, CDN, redirects and environment settings.
- Map the plugins in use and flag any that depended on WP Engine's platform rules or managed infrastructure.
- Agree the written scope, deliverables and timeline before work starts, since engagements are fixed-scope.
How we build
- Deploy WordPress on your chosen servers or cloud, with PHP and MariaDB or MySQL versions matched to current WordPress requirements.
- Configure page caching, object caching, CDN and automated backups to replace what WP Engine provided by default.
- Set up a staging environment and test the migrated site, plugins and DNS cutover before any public traffic moves.
How we hand over
- Document the hosting architecture, update procedure, backup schedule and restore steps in language your team can follow.
- Run a restore test from backup so your team sees that recovery works before WP Engine access ends.
- Walk your operators through patching, plugin review and monitoring so the routine stays with your team.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Retainers can cover WordPress core and plugin upgrades, backup checks and security testing on a schedule you agree.
- Ask for the support scope, response expectations and upgrade process in writing before you sign.
