How to export your site from WP Engine

How to export your site from WP Engine before your contract ends

If a renewal, a plan change or a decision to leave WP Engine is on the calendar, the risk is simple: losing a working copy of the site before you have tested a replacement. A WP Engine backup carries the WordPress files and the database, which is the core of the site. It does not carry everything the site depends on. DNS records, redirects, environment settings, platform-level caching rules and some vendor-specific configuration must be collected or rebuilt separately. Make a written inventory of those items now, while the live site still runs, so nothing is discovered during cutover.

Because WordPress is released under the GPLv2 or later, the exported code is yours to run on infrastructure you control. Your theme, custom code and the core files can move to another host without a licensing negotiation with WP Engine. Plugins are a separate check: confirm each one's license and whether it depends on a WP Engine feature, such as a platform cache or mu-plugin, that will not exist elsewhere. Record the PHP and database versions the site uses today so the target environment matches them.

Confirm the current backup retention period and the download window in WP Engine's own documentation and in your account, rather than relying on memory or on older third-party guides. Download a full backup, store it outside the WP Engine account, and then restore it to a staging environment to check that pages, media, logins and forms work. Repeat the restore test close to cutover, because content changes during the migration period. Keep the final backup and your inventory for as long as your retention policy requires.

What WP Engine lets you export and in what format

This table lists each item you can take from WP Engine, how it is exported, the format it arrives in and what to check before you rely on it. Treat the rows as a checklist and confirm each export is complete and restorable before the hosting account closes. Retention periods, download windows and file size limits can change, so confirm them with WP Engine in writing first.

Data type	Export method	Format	Limits and checks
Full site backup	Full backup from WP Engine's backup tool in the hosting portal	ZIP containing site files and the database	Confirm the download window and any size limit before relying on it. Test the restore.
Partial backup	Select specific files or the database in the same backup tool	ZIP containing only the selected files or database	Useful for large sites or a single fix. Confirm which selections the tool allows.
Database dump	Included in a full backup or taken as a database-only export	SQL dump inside the ZIP	Restore needs MariaDB 10.11 or later, or MySQL 8.0 or later. Check character set and collation.
Uploads and media	Included in the file set under the uploads folder in wp-content	Original media files in year and month folders	Large media libraries may hit size limits. Compare file counts after download.
WordPress core, plugin and theme code	Included in the file set, or reinstalled from WordPress.org for core	PHP and asset files in core folders and wp-content	WordPress is GPL and reusable. Check each plugin and theme license separately before reuse.
Target environment check	Compare your planned server against WordPress requirements before restoring	Version requirements, not an export	WordPress recommends PHP 8.3 or greater and MariaDB 10.11 or greater, or MySQL 8.0 or greater.

What a WP Engine backup does not carry over

A WP Engine backup captures the WordPress files and database, but the rest of the site's delivery path lives outside that archive. The cards below cover the items that sit in DNS, certificate authorities, the hosting panel and the vendor account, and that you need to export or document before the platform is switched off. For each item, confirm with WP Engine which of these are included in your plan and which you must collect yourself.

DNS records and registrar settings

Your domain's A, AAAA, CNAME, MX and TXT records point traffic to WP Engine and often carry email and verification entries. A site backup does not contain them. Export the zone file from your DNS provider, or record each record by hand if the provider does not offer export, and note the registrar account, transfer lock and renewal date. Do not change DNS until the replacement host serves the site under a test hostname.

SSL certificates and private keys

If WP Engine issued or installed the certificate for your domain, the private key may not be available to download. Confirm with WP Engine whether the certificate and key can be exported, and if not, plan to request a new certificate from your certificate authority or a free issuer once DNS points to the new host. Record which hostnames the certificate covers so no subdomain is left without HTTPS.

Redirect rules in the hosting panel

Redirects set in the WP Engine control panel act before WordPress loads, so they are missing from the database and the file archive. Export the list from the panel, then translate each rule into a .htaccess file for Apache or a server block for Nginx. Test old URLs, trailing slashes and HTTPS-to-HTTP variants on the new server before the cutover, since a missed redirect shows up as a 404 in search results.

Platform caching and CDN configuration

Cache purge rules, cache exclusions and CDN behavior for paths such as checkout or logged-in areas are part of the hosting platform, not the WordPress code. Write down every exclusion and cache lifetime, then choose a replacement such as a self-managed page cache plus a CDN and map each rule to it. Without this record, a new stack can cache private pages or serve stale content after publishing.

Environment settings and server configuration

Environment variables, PHP version and extension settings, memory limits, cron jobs, and any custom server directives live in the hosting account. Record the PHP and MariaDB or MySQL versions in use, and compare them with the WordPress requirements for the release you will run. Also note any wp-config.php constants that WP Engine sets, such as database host or debug flags, because they must be rewritten for the new environment.

Account, user and support history

User accounts, login activity, support tickets, and records of past incidents or change windows are kept in WP Engine's systems, not in the site backup. Export the WordPress user list from the database and keep a written copy of your plan, contacts and any agreed maintenance terms. Ask WP Engine how long support records remain accessible after cancellation, since you may need them for an audit or a dispute.

How to export your site from WP Engine in a safe sequence

This sequence produces a verified, restorable copy of your WordPress site, along with the DNS, redirect and SSL details you need to point traffic at a new host. Each step ends with a check so you know the export is complete before you cancel anything.

Inventory the site and its plugins
Before any backup, the site owner or developer lists the WordPress version, the PHP and database versions in use, every active plugin and theme, custom code in the theme or mu-plugins folders, and any integrations such as payment gateways, email services and form providers. Note which items depend on WP Engine's platform, such as its caching layer, CDN or any plugin WP Engine restricts. Confirm the target PHP and database versions with WordPress.org's requirements page before you choose a host. The output is a written inventory that you can check against the restored site in the final step.
Take a fresh full backup
In the WP Engine User Portal, start a new full backup so the archive reflects the site as it is today, not an older snapshot. A full backup ZIP contains the files and the database together. Confirm the backup appears in the list with a completed status before you move on. If the site changed after this backup was taken, plan to repeat the step immediately before your final cutover.
Take a database-only backup
Create a second backup that contains only the database. This gives you a separate copy of the content and settings that you can restore or compare without unpacking the full archive. Keep the database backup alongside the full backup so you can check one against the other. The output is a second archive with a completed status in the portal, labeled so it cannot be confused with the full backup.
Download both archives within the window
Download the full and database backups while they are still available in the portal. WP Engine retains backups for 30 days, and the download window for each backup is 7 days, so do not leave this step for later. Store the files on storage you control, with access limited to the people who need them. Record the date of each download so you can tell which copy you have if the site changes again.
Record checksums and file counts
Generate a SHA-256 checksum for each archive with a tool such as sha256sum and save the result in your migration record. Unzip the full backup into a separate folder and count the files and the subdirectories under wp-content, then compare that count with your inventory from the first step. Count the tables in the database backup as well. Any mismatch in the checksum or counts means you should download the archive again before you rely on it.
Collect DNS, redirects and SSL details separately
The backup does not carry everything your site depends on. Export or write down the DNS records for the domain, including the A, AAAA, CNAME and MX records and any TXT records used for verification. Record the current redirect rules, whether they live in .htaccess, a plugin or the host, and the SSL certificate details, including who issued it and when it expires. Confirm with WP Engine how its CDN and SSL are provisioned, because you will need to replace both on the new host. The output is a DNS and redirect sheet that someone other than the migrator can review.
Restore to a staging environment
Import the full backup into a staging environment on the new infrastructure, using the PHP and database versions you confirmed earlier. Point the restored site at the staging URL and update the site address settings for that environment. Do not switch the public DNS yet. Keep the restore notes, including any step that failed, because they become part of the cutover runbook. The output is a staging site that loads without a database connection error.
Run the verification checklist
Work through a written checklist on the staging copy. Compare the database table count and the number of published posts and pages with the values from the original backup. Open the front page, a sample post, an archive page and the search results. Test logins for each user role, submit each contact or form and confirm the entries arrive, and check that media URLs resolve and images display. Confirm that each plugin on your inventory is either active and working or replaced by a documented alternative. Only after every item passes should you plan the DNS change.

Why a restore test matters more than a successful download

A downloaded archive proves only that the bytes arrived. It does not prove that the site works. Treat the backup as unverified until you have restored it on a staging host and walked through the site as a user would. Restore the files and the database into an environment you control, then confirm that the wp-config.php values point at the new database host, with the correct database name, user and password. Check whether any URL settings, such as the site address and home address stored in the database, need updating for the staging hostname. Search-and-replace tools should be run with care, because serialized data in the database can break if it is edited naively.

Test the journeys that carry business risk, not just the home page loading. Log in to the admin area and confirm that media, menus and widgets appear. Submit a contact form and confirm where the message lands. If the site takes payments or bookings, run a test transaction through the new payment configuration in a sandbox mode provided by the processor, and confirm that plugins which depended on WP Engine's hosting layer, such as caching or mail delivery, are either replaced or disabled on purpose. Record which plugins and themes are active, since that list is what you will need to re-check after each update.

Build the staging host to match the WordPress requirements page rather than the version you happen to have on hand. The requirements page recommends PHP 8.3 or greater and MariaDB 10.11 or greater, or MySQL 8.0 or greater, so confirm your target against those figures and check your plugins against the same PHP version before cutover. Keep the restore notes, including the commands used, the versions tested, the test results and any issues found, as evidence in the cutover record. Those notes are also what your team or partner will use when a later restore is needed, so write them for someone who was not in the room.

Which export path fits your site

A brochure site is mostly pages, a theme and a modest media library, with few plugins and little custom code. A full backup ZIP, containing files and the database, is usually the simplest starting point because it captures everything the site needs to render. The main risk is not the data itself but forgetting what sits outside the backup, such as DNS records, form notification addresses, redirects and the contact or mail settings tied to the domain.

Full backup ZIP: Download a full backup from the WP Engine User Portal while the 7-day download window is open, then confirm both the files and the database are present.
DNS and email records: Export your current DNS zone and note the MX and SPF records, since mail often depends on them and not on the website.
Redirects and permalinks: Record the permalink structure and any redirect rules so old URLs keep resolving after the move.
Forms and notifications: List every form, its recipient address and any third-party service it calls.
Test first: Restore the backup to a local or staging server and check the home page, contact form and a sample of old URLs before changing DNS.

Before you leave, confirm that the restored copy matches the live site page by page on a short checklist.

A site with a large media library carries most of its weight in uploads, which are stored in the files portion of the backup. Media volume is the main driver of how long the download takes, how much storage the copy needs and how long the restore runs. Plan the export around the upload folder rather than assuming a single ZIP will be convenient to move.

Full backup or files only: Confirm the backup contains the wp-content/uploads folder in full, and compare its size against the database to see where the bulk sits.
Storage target: Decide where the files will live after the move, such as local disk, block storage or object storage, and confirm capacity before downloading.
Image derivatives: Note whether thumbnails are generated on demand or stored, since regenerating them after restore can take significant time on large libraries.
Media-linked URLs: Search the database for absolute upload URLs so references to the old host or CDN path can be rewritten.
Test first: Restore only the uploads to the new host and load pages that use the heaviest images, checking for broken links and slow responses.

Confirm with your team how long the download and restore are expected to take for your library size, since this varies by connection and host.

Sites with a production install, a staging copy and sometimes a development environment need a clear answer about which environment is the source of truth at export time. Exporting from the wrong environment can carry unpublished changes or outdated content into the new host. Each environment may also hold different settings, so the export plan should name the one you are leaving and treat the others as references.

Source of truth: Name the production environment as the export source and freeze content edits for the export window.
Separate exports: Take a backup of each environment you intend to keep, and label the files with the environment name and date.
Environment-specific settings: Record differences in wp-config.php values, debug flags, search-engine visibility and API keys between production and staging.
Staging rebuild: Decide whether staging will be recreated on the new platform, and plan its refresh process so it does not drift from production.
Test first: Compare the restored production copy with the live site for content and menus, then confirm that the staging environment is pointed at the new host and not the old one.

Confirm with WP Engine support which environment-level backups are available to you before you start.

What to plan before the WP Engine contract ends

The export itself is the easy part. The risk sits in the dates around it: the backup window, the DNS cutover, and the services and accounts that stop working when the WP Engine plan ends. Work through these cards in order and confirm each item against WP Engine's current terms before you rely on it.

Confirm the export window in writing

The backup retention and download windows are set by WP Engine's current terms, not by WordPress itself. Ask WP Engine to confirm in writing how long a backup stays available, how long a download link remains valid, and whether those windows change if you cancel early. Record the answers with the date you asked, since terms can change between your planning and your cutover.

Schedule the final backup before the plan ends

Take a full backup ZIP with files and database while the site is still live on WP Engine, and then take a second one close to cutover if content changes. Store both copies outside WP Engine. Confirm with WP Engine whether a backup can be created or downloaded after the plan lapses, because that determines how late you can start.

Plan the DNS cutover and TTL

Lower the TTL on your domain's DNS records well before the switch so that resolvers pick up the new target quickly. Keep the old WP Engine records in place until the new host serves the site correctly. Confirm with your DNS provider how long the lowered TTL takes to propagate, and schedule the cutover outside peak traffic.

Inventory services tied to the account

List everything that depends on the WP Engine account: analytics and tag manager connections, payment gateways, form and CRM webhooks, email sending domains, CDN or security add-ons, and any scheduled jobs. Each one may need a new API key, a new allowed origin, or a re-verified domain before it works on the new host.

Record domain and certificate ownership

Confirm which party is the registrant of record for the domain and who holds the login at the registrar. If WP Engine issued or managed the SSL certificate, confirm whether it can be exported or whether you need a new certificate on the new host before cutover. Keep the registrar, DNS and certificate credentials in your own password manager, not only in an account you do not control.

Decide on a read-only copy period

Decide whether to keep the WP Engine site in read-only form for a defined period after cutover, so that you can check a missing page or re-download data. Ask WP Engine whether a read-only or staging copy remains available and for how long. Set a date to retire the copy and delete any exported data you no longer need.

Who patches WordPress after the export

When you leave WP Engine, the team that takes over owns patching, and that job splits differently than it did on a managed host. WordPress core is released under the GPLv2 or later, so the code is yours to run, but the only officially supported release is the latest one. The WordPress Security Team backports critical fixes to older versions as a courtesy, so an older site can still receive security fixes through auto-updates, but you should not plan around that as a support commitment. The release to track is the 7.1 series, which the WordPress releases archive lists as 7.1 (released August 19, 2026) and 7.1.3 (released October 6, 2026), and only the most recent release in that series is actively maintained. Confirm the exact current version on the WordPress releases page on cutover day, not from this page.

Automatic updates behave differently for each layer. Background updates for WordPress core have existed since WordPress 3.7, and sites created since WordPress 5.6 have automatic major release updates enabled by default. Plugins and themes are another matter: by default, WordPress applies their automatic updates only in special cases chosen through the WordPress.org API, which the security team uses to patch critical vulnerabilities. Everything else in your plugin and theme inventory is yours to patch. Before cutover, export a list of every active plugin and theme with its installed version, mark which ones you are no longer able to update from a vendor, and decide who receives vulnerability notices for each one.

The team that takes over must own three recurring tasks: plugin patching, monitoring for vulnerabilities and release testing. Patching means applying updates to plugins and themes on a schedule, and it includes removing plugins that are abandoned. Monitoring means subscribing to security advisories for your plugin list and watching the core release cycle so you can move to a new core version in time. Release testing means running each core, PHP or plugin update on a staging copy first, using the same PHP 8.3 or greater and MariaDB 10.11 or MySQL 8.0 requirements that WordPress.org recommends. Assign these tasks to a named owner before DNS moves, because the first unpatched plugin usually appears within weeks of the switch.

How long does it take to export your site from WP Engine, and what does the work need from you?

How long does a WP Engine site export take?

No supplied source gives a fixed duration for exporting a WP Engine site, so the honest answer depends on the site. The main drivers are media library size, database size, how many environments need to be captured and how deep the verification goes. A brochure site with a modest media library is a different job from a multisite network with years of uploads and custom tables. Ask any provider to break the estimate into inventory, export, restore test and DNS work, so you can see which part is driving the timeline. Your own download window also matters: WP Engine backups are kept for a limited period and must be downloaded within a set window, so start the export early rather than at cutover.

Can an internal team export a WordPress site from WP Engine alone?

Yes, for a simple site, an internal team can usually do the export without outside help. The work is downloading the full backup ZIP, confirming it contains the files and database, and restoring it to a test environment. That is realistic for a team with a WordPress administrator who can run a restore test and check the front end, forms, logins and media. The harder cases are sites with custom code, many plugins, integrations with payment or CRM systems, or regulated data where someone must document each step. In those cases the internal team should decide early whether they have the time and skill to own the restore test and cutover.

What does a migration need from our team before work starts?

Before any export, your team needs to provide four things. First, access to the WP Engine account with rights to download backups and view environment settings. Second, access to the DNS registrar, so the domain and any mail records can be checked and changed at cutover. Third, a list of plugins, themes, third-party services and integrations, including forms, analytics, email delivery and payment tools. Fourth, a named owner who can sign off the restore test and approve the switch. Missing any of these usually adds delay later, because the inventory and cutover steps depend on them.

What does a partner's fixed-scope export engagement usually include?

DeployOpen works on fixed-scope engagements, so scope, deliverables and timelines are agreed in writing before work starts. For a WordPress export, a written scope typically covers an inventory of the site and its settings, collection of the full or partial backup, a restore test on infrastructure you control, verification of key pages and functions, and a documented cutover plan. Items such as DNS changes, redirects and environment settings should appear as named deliverables rather than assumptions. Ask for the exact list of checks and what happens if the restore test finds a problem, since those terms define what you are buying.

What should we ask to see in a migration quote?

A useful quote separates cost components so you can compare providers and see what recurs. Ask for labor for the inventory of plugins, themes, redirects and environment settings, labor for the export and restore test, labor and verification for the DNS cutover and rollback plan, and a separate line for ongoing support after the switch. Ask which items are one-time and which recur, such as backups, patching, monitoring and hosting you pay for directly. Also ask what changes the price, such as additional environments, large media libraries or custom integrations. A quote without these lines is hard to compare with an internal plan.

Does the export include the DNS, redirects and environment settings?

Usually not, because a standard WordPress backup ZIP contains the files and the database, not the registrar records or hosting-level configuration. Collect these items separately: DNS records, email routing, SSL certificate arrangements, redirect rules, cron jobs, PHP version, and any environment variables or caching settings configured in the WP Engine dashboard. Record each one in your inventory before you start the restore, and confirm the target host can reproduce it. Treat anything you cannot find in the dashboard as an open question for the vendor, not as something that will carry over on its own.

How do we confirm the export is complete before we cancel WP Engine?

Confirm completeness with a restore test, not by checking file sizes. Restore the backup to a separate environment that matches your target PHP and database versions, which WordPress.org recommends as PHP 8.3 or greater and MariaDB 10.11 or greater, or MySQL 8.0 or greater. Then check logins, forms, media, search, scheduled tasks, plugin functions and the pages your analytics show as most visited. Keep the WP Engine site running until the owner signs off and DNS has moved. Cancelling before this sign-off is the most common way teams lose content or features.

What ongoing work starts once the site leaves WP Engine?

Once the site runs on your own infrastructure, updates, backups, monitoring and security response become your responsibility or your partner's. WordPress core automatic background updates apply to minor releases by default, and since WordPress 5.6 newly created sites have automatic major release updates enabled by default. Plugin and theme updates are not generally automatic, so someone must watch advisories and test changes. Only the latest WordPress version is officially supported, although the Security Team backports critical fixes to older versions. Plan for an ongoing support arrangement from the start, and ask a provider to state which of these tasks they cover.

How DeployOpen scopes and delivers an export and exit

DeployOpen plans, implements, documents and supports self-hosted open-source platforms inside your own infrastructure, and an export from WP Engine is scoped the same way. We agree deliverables in writing before work starts, then test the restore so the exported site is proven to run outside WP Engine before anyone changes DNS.

How we scope

Inventory the WP Engine environments, plans and sites in scope before any backup is requested.
Agree in writing which full or partial backup ZIPs, database exports and separate items such as DNS and redirects are included.
Confirm the 30-day retention and 7-day download window against your own backup calendar and deadline.

How we build

Take the backup, verify the files and database dump, and record checksums and file sizes.
Recreate the items WP Engine does not export, including DNS records, redirects, environment settings and cron jobs.
Stand up a restore of the site in your own cloud account or data center and test pages, forms, logins and media.

How we hand over

Deliver a runbook covering the export steps, restore steps, DNS cutover order and rollback path.
Document each plugin and theme retained, replaced or removed, with its license and update source.
Hand over the restore test results and the list of open items for your team to sign off.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Support can cover WordPress core and PHP upgrades, which WordPress.org recommends at PHP 8.3 or greater.
Confirm response expectations and support hours in the written scope, since these are not published here.