Here is a quick guide on migrating a Staging Server to Production in WPEngine.

Compare Content

Before you start the migration, you will need to check to ensure the content is identical on both websites.

The easiest way to check this is by visiting the XML sitemap on your website: /sitemap.xml

Compare the Last Modified dates, clicking on the XML links to see which pages/posts were added or modified.

XML sitemap

As you can see above, the production server had articles uploaded by the content team between September 29th and October 5th. You can move the content to staging manually or using the WordPress Export/Importer function. If you do not transfer the production content to staging, the new articles on production will be erased.

theme files

Once the content has been migrated, check your files and folders for updates. Specifically, the current theme your website uses. Did you update the styling on the homepage, fix a button?

If the code has been updated, remember to migrate it to staging using an FTP manager. If you work in a team, this is where Git repos come in handy.

If you are only migrating style changes (e.g., style.css), I recommend moving the updated files manually via sFTP.

The Migration Process

Once both sites are identical in content, you can begin the migration process.

  1. Login to WPEngine
  2. Find your Domain (I’ve removed client details from my screenshots)
  3. Click on the Environment you want to move. In this instance, we want Staging copied to production. So we are clicking on staging.

4. In staging, click on the Copy environment button in the top right corner. (don’t worry, you still have one more step before the migration starts)


5. Ensures no additional changes were made to staging since the previous backup. This case, noted below, was 4 hours ago. If you have made further changes, create a new backup (Staging >> Backup points >> Create backup) and use that new backup for the migration process.

“Database and file system” includes brings overall content and changes. “File system” migration only migrates the style (CSS) and coding changes (PHP, JS) and leaves everything in the database untouched (e.g., content, plugin settings).

copy environment

6. Preview and Submit

Add your email address to be notified when the process has been completed—press Preview copy.

send notifications

Then Submit when ready.

target environment

Optional: Best time to migrate a server when it has the least traffic (early mornings). Try not to migrate Friday End-of-Day; it’ll probably be fine, but if you are tired from the week, it’s so easy to make simple mistakes, ruining your Friday night/weekend.

If everything is broken and nothing works after migration, quickly restore a production backup.

Quality Assurance

After the migration has been completed and everything appears fine, you need to do two quick checks:

  1. Error Console

In Google Chrome, right-click on your website and select “Inspect” from the dropdown.


When Google Console opens, check to see if the website is experiencing any Errors or Warnings. It will look something like this:


Fix accordingly if you receive errors.

2. Update domain name

When you migrate a website, the database could still be directed to the old staging server. e.g., (which is set to no index).

The fastest way to fix this is by using a Search ‘n Replace plugin.

search replace

Be conscious of how your URL is set up. Does it use WWW or non-WWW? Don’t change the URL’s appearance as Google sees HTTP, HTTPS, WWW, & non-WWW as separate domains.