Skip to content

Migrate from WP Engine

Moving off WP Engine onto managed.dev is free and white-glove: you grant read-only access, the migration team copies your database, files, plugins, and themes, and your site comes up on a branch environment with a live preview URL. You review it against your real site, and only after you sign off does DNS cut over — with zero downtime. WP Engine keeps serving traffic the whole time.

This page is the WP Engine-specific walkthrough. For the general flow across all source hosts, see migrate a site.

Have these ready — they make the access step fast:

  • The WP Engine install name (the yoursite in the WP Engine portal) and the production domain.
  • A WP Engine user with SSH/SFTP access, or the ability to create read-only credentials.
  • A rough plugin/theme inventory so you know what “correct” looks like on review.
  1. Open a migration. From your team in the dashboard, choose Migrate a site and select WP Engine as the source. You can hand the whole thing to the migration team (white-glove) or drive a self-serve copy — both land in the same place.

  2. Grant read access. Provide read-only SFTP/SSH plus database access for the WP Engine install. managed.dev only ever needs read access to copy your site; nothing is written back to WP Engine.

    The “Migrate a site” wizard in app.managed.dev with WP Engine selected, fields for the install name and SFTP/SSH credentials, and a note that only read access is required.
  3. We copy everything. The team copies the database, the files (uploads and wp-content), and your installed plugins and themes at their current versions. managed.dev detects the runtime — most WP Engine sites land as the vanilla profile, Bedrock-structured repos as bedrock — and assembles the right site profile.

The imported site is provisioned as an isolated environment with its own database and files and a live preview URL — exactly like any other branch environment. Your WP Engine domain is untouched.

Preview URL pattern
https://<site>-migration-<hash>.preview.managed.dev

A few WP Engine platform features don’t map one-to-one. Walk these during review so nothing surprises you after cutover.

  1. Object cache. WP Engine ships its own object cache integration. On managed.dev a tuned persistent object cache is included and managed for you, so the WP Engine object-cache drop-in and plugin aren’t needed. Confirm no WP Engine-specific cache plugin remains active.

    Check for a stale object-cache drop-in
    wp plugin list --status=active --fields=name,version
  2. Page rules and caching headers. WP Engine “page rules” (cache exclusions, header tweaks) live in their portal, not in your code, so they don’t migrate automatically. Re-create the ones you rely on as redirects and security headers on managed.dev.

    The WP Engine portal “Redirect rules” and “Page rules” screens side by side, used as the reference for re-creating exclusions and redirects on managed.dev.
  3. Redirects. Export your WP Engine redirect rules and re-add them under redirects so SEO and bookmarked URLs keep working after cutover.

  4. CDN / asset URLs. WP Engine’s CDN may have rewritten asset URLs in content. If you see a WP Engine CDN hostname in the database, fix it during the URL search-replace step of the go-live checklist.

Open the preview URL and compare it page-for-page with your live WP Engine site — home, key landing pages, media, forms, checkout, and wp-admin. Go deeper with WP-CLI over the SSH gateway:

Inspect the migrated environment
ssh acme-store@ssh.managed.dev
wp option get home
wp plugin list --status=active --fields=name,version,update

Take as long as you need — the preview stays up and WP Engine stays live.

When you sign off, the migration team schedules the DNS cutover. TLS is issued automatically ahead of time so the certificate is ready, and traffic moves to managed.dev with no downtime. Run the go-live checklist immediately before — it covers the URL search-replace, cache warming, and the DNS/TTL steps that make the switch clean. Decommission WP Engine only after propagation completes and you’ve confirmed the site serves on the real domain with valid TLS.