Migrating a WordPress Site from WP Engine to Getwebup

WP Engine is one of the most locked-down managed WordPress hosts out there, and that's exactly why migrating off it trips people up. There's no SSH shell, wp-config.php is half off-limits, and the site is stuffed with must-use plugins that only make sense on WP Engine's own servers. If you're moving from WP Engine to Getwebup, here's what actually happens at each step — and which WP Engine leftovers will break your new site if you don't strip them out first.

Why this migration isn't like a normal WordPress move

WP Engine sells itself on being fully managed, which in practice means a lot of the server is hidden from you on purpose. You get SFTP access and a restricted "SSH Gateway" that runs a handful of WP-CLI commands — not a real shell, so you can't cd around or run arbitrary Linux commands. File editing inside wp-admin is disabled by default. And the wp-content/mu-plugins folder is loaded with WP Engine's own code that talks to their internal APIs, none of which exists once you're on a different server.

None of that is a dealbreaker. It just means the export/import steps that work for a typical shared-hosting move need a couple of extra cleanup passes, or you'll spend your first hour on the new host staring at a fatal error instead of a working site.

Before you start: a 15-minute audit

• Confirm which environment is live. WP Engine gives every install a Production, Staging, and Development copy. Export from Production — it's easy to grab the wrong one from the User Portal dropdown.
• Check for mu-plugins. Open wp-content/mu-plugins over SFTP. You'll typically see mu-plugin.php, a wpengine-common folder, and sometimes slt-force-strong-passwords.php or Mercator (multisite domain mapping). All of it needs to be excluded from the move.
• Look for object-cache.php in wp-content. If it's there, WP Engine is using it to talk to their internal Memcached layer. It won't connect anywhere else and needs to go.
• Note any WP Engine-specific constants in wp-config.php — things like WPE_APIKEY, WPE_CLUSTER_ID, or a forced DISALLOW_FILE_EDIT define. These are dead weight on Getwebup.
• Check who owns DNS. WP Engine doesn't sell domains, so nameservers are almost always sitting somewhere else already — Cloudflare, GoDaddy, or your registrar. Run dig NS yourdomain.com to confirm before assuming anything needs moving.

Step-by-step migration

1. Download a backup from the User Portal

WP Engine's User Portal (not wp-admin) has a Backup Points tab under your install. Take a fresh on-demand backup, then use the "Download" option to pull the full site — files and database together — as a single archive. This is the fastest path and skips the SSH Gateway entirely for most sites.

If the backup download times out on a large site, fall back to exporting the database directly through the SSH Gateway instead:

ssh yoursite@yoursite.ssh.wpengine.net wp db export backup.sql

then pull it with sftp using the same credentials, and grab wp-content separately the same way.

2. Strip out WP Engine-only code before you upload anywhere

Delete these from your extracted files before they ever touch Getwebup:

• wp-content/mu-plugins/wpengine-common and any WP Engine mu-plugin files
• wp-content/object-cache.php, if present
• wp-content/advanced-cache.php, if it references WP Engine's page cache

Leaving these in causes the most common post-migration error: a white screen or Fatal error: Class 'WpeCommon' not found the moment WordPress tries to load a plugin that no longer has its dependency.

3. Create the database and upload on Getwebup

In cPanel, create a new database and database user under MySQL® Databases, then assign the user ALL PRIVILEGES. Upload the cleaned-up files through File Manager or SFTP into public_html, and import backup.sql through phpMyAdmin. For anything over roughly 50MB, gzip it first and let phpMyAdmin handle the decompression rather than fighting cPanel's raw upload limit.

4. Rebuild wp-config.php from scratch

Don't just edit the WP Engine version in place — rewrite the database constants (DB_NAME, DB_USER, DB_PASSWORD, DB_HOST as localhost) and drop every WP Engine-specific define. If you want file editing back in wp-admin, remove any leftover DISALLOW_FILE_EDIT or DISALLOW_FILE_MODS lines while you're in there.

5. Run a proper search-replace on URLs

Even if the domain isn't changing, WP Engine installs often have a staging subdomain (yoursite.wpengine.com) baked into image URLs or page-builder JSON from an earlier test. Use WP-CLI on Getwebup, not a raw SQL UPDATE, since a blunt update corrupts serialized data in widgets and Elementor/Divi content:

wp search-replace 'yoursite.wpengine.com' 'yourdomain.com' --skip-columns=guid --all-tables

6. Test before DNS changes

Point your own machine at the new server by editing your hosts file, without touching DNS for anyone else:

203.0.113.10  yourdomain.com www.yourdomain.com

Click through the full site this way — login, forms, checkout if it's WooCommerce — and check the browser console for 404s on assets, which usually means a leftover WP Engine CDN URL somewhere in the theme options.

7. Cut over DNS

Update the A record wherever your nameservers actually live to point at the Getwebup server IP. Leave MX records untouched — WP Engine never hosted your email, so a separate provider is already handling it and doesn't need to move. If TTLs were left low beforehand, the cutover is usually visible within a couple of hours.

Issues that show up after the move

Prevention: keep the WP Engine install alive for a few days

WP Engine bills monthly, not hourly, so there's less financial pressure to cancel the moment DNS switches — but don't cancel same-day regardless. Keep it reachable for 48-72 hours as a rollback path while you confirm mail, forms, and any payment gateway webhooks are all pointed correctly at the new domain on Getwebup. Once everything has run clean for a couple of days, cancel the WP Engine plan.