How to Use WP Engine to Test Plugin Updates on Staging

The short answer: if your WordPress site collects leads through a form plugin, every update to that plugin should pass a WP Engine staging copy before it reaches visitors, and on the $35 a month Essential tier that copy is already in the plan, per the plans page (checked on 26 October 2026). The steps: add a staging environment, pull production into it, update and test there, take a checkpoint of production, apply the same update live, clear the caches, submit a real test lead.

Disclosure: I may earn a commission through some links on this site. It does not change what this page says.

The job here is narrow on purpose: one plugin update, done so that the form, the tracking and the CRM sync still work afterwards. What WP Engine is and costs is in the WP Engine glossary entry.

Before you touch production:

1. Put a number on a broken form. For example, a form that brings in 40 leads a week loses 40 / 7 = 5.71 leads for every day a failed update goes unnoticed. That is the cost this routine avoids, and it is larger than the time it takes.
2. Sort the plugins you already run. List the ones that touch a lead or a sale: forms, CRM connectors, tracking, checkout. Those go through staging. A plugin that only changes how the admin screens look can wait for the next batch.
3. Write down what "working" means. One test submission that lands in the CRM with its source fields filled, and the weekly count of form submissions compared with the week before the update.

What you need

• A WP Engine site on any plan. One-click staging and development environments are included on Essential, Business and Enterprise, per the plans page.
• A User Portal login with rights to the site. Adding environments and creating backups happen there; deleting them is reserved for Owner-level users, per the environments article.
• Licence keys for paid plugins. The same article warns that premium services which license by domain may need an extra licence, or their own staging mode, for each environment.

Step 1: Add a staging environment

On the Sites page, open the site and click Add environment next to the environment name, or use Add environment from the site's Settings icon. Choose Staging (STG), give it a name and wait for the email that says it is ready, as the environments article describes. A site holds one environment of each type. Choose the name with care: it becomes the permanent name.wpenginepowered.com address and cannot be changed or reused, even after you delete the environment.

Step 2: Pull production into staging

Select the staging environment, open the Actions menu and choose Pull from, then select production as the source. A Full copy brings all files and all database tables into staging, which is what you want here, because the test should run against today's site. Add your email for the completion notice and click Pull changes. The copy article says the destination is backed up before and after, the domain is rewritten in the database, and the cache is cleared. It also asks you not to change either environment until the copy has finished.

Step 3: Update the plugin on staging and run the job it does

Log in to WordPress on the staging address, update the one plugin, then do what a visitor does: open the page with the form, submit it with a test address, and check that the entry arrives where it should. Staging is a separate install with the same server configuration and caching as production, per the environments article, so a problem here is a problem you would have had live.

Step 4: Take a checkpoint of production

In production, open Backups, click Create backup, describe it ("Before form plugin update") and add the addresses that should hear when it completes, following the backup article. Daily checkpoints exist anyway; this one marks the minute before your change.

An agent can do this step if your team already scripts its releases. WP Engine's Hosting Platform API takes a POST to the create backup endpoint with a description and notification emails, using API credentials the account owner enables on the API Access page, per the quick start. The call is asynchronous, so the human check is the completion email: nobody moves to step 5 until a person has seen that the checkpoint finished.

Step 5: Apply the same update on production

Here the support docs offer two routes, and for a single plugin the simpler one is safer: repeat on production the update that passed on staging. If it changes the database, switch on maintenance mode first from the environment's Overview page under Utilities; the maintenance article says the User Portal toggle switches itself off after 10 minutes.

The other route is Push to: from staging, a Custom copy with Files ticked and the database left out. Use it only straight after a fresh pull. The copy article calls a file system copy fully destructive: a file that exists on production but not on staging is removed, so an image uploaded to production since your pull would disappear.

Step 6: Clear the caches and test the live form

Open the Cache page in the User Portal and use Clear All Caches, which the cache article says also purges the Edge Full Page Cache. Then submit one real test lead on the live site and follow it into the CRM.

Step 7: Know how to roll back

If the live form fails, restore the checkpoint from step 4: Backups, the three-dot menu, Restore. Read the restore options first. The backup article says a restore overwrites everything to match the checkpoint, and restoring with the database brings back the posts, users and orders as they were then, so leads stored in WordPress since the checkpoint go with it. Export them first.

What WP Engine's own articles warn about

• Pushing the whole database to production. The copy article does not recommend it, because new orders or new users on the live site are overwritten.
• Assuming settings travel with a copy. Redirect rules, SSL certificates, custom cache exclusions and Nginx rules are not copied; support copies them on request.
• Working during a copy. Changes made to either environment before the copy completes are not safe.
• Reusing an environment name. Deleted names stay taken.

WP Engine sells an automated version of this routine: the plans page lists AI powered automatic plugin and theme updates as an optional add-on on Essential, and the Smart Plugin Manager article describes visual regression tests and automatic rollback, while recommending staging first for sites with custom code. The staging copy and the checkpoint are already in the plan you pay for, so the manual routine costs your time, not a second licence.

FAQ

Does the staging environment cost extra?

No. One-click staging and development environments are included on every plan in the feature table on the plans page.

Will pulling production into staging overwrite my staging work?

Yes. The destination is overwritten, after WP Engine backs it up, per the copy article, so finish or export staging work before you pull.

How far back can I restore?

Thirty days of checkpoints are kept in the User Portal, according to the backup article; older ones need a request to support.