How To Switch WordPress From Elementor Beta (or Elementor Developer Edition) Back to a Stable Version of Elementor or Elementor Pro

Background

We had a client who had self-designed their site using Elementor Pro, based on the “Hello Elementor” theme. While the site looked great, it was frequently unstable. Sometimes layout would become severely broken, to the point where pages were rendered unreadable and content was missing.

When the client asked us to solve the problem, we discovered they had used Elementor Beta, along with Elementor Developer Edition, to build the site. We realised that was the cause of the instability.

Not For Production!

Elementor Dev / Elementor Beta should never be used on production sites. Whenever those plugins are updated, there is a high chance of something breaking. They give that warning clearly on their page about Beta Testing:

Important! We recommend only beta testing on a development or staging site, as beta versions are not stable and may break a live production site.

Likewise in their page about the Elementor Developer Edition:

The Developer edition is an unstable version and should be used for staging sites only. We advise you to backup your website before trying the version.

Migrate Away From Elementor Beta and/or Elementor Developer Edition

So we set out to revert the site by migrating from Elementor Dev / Beta back to Elementor Pro stable release.

Before we dive in, here is a summary of the process:

  1. Implement content freeze and feature freeze on production site.
  2. Full site backup, locked so it remains available regardless of backup retention settings.
  3. Full site backup (standard – as basis for cloning).
  4. Clone site to our cloud infrastructure on temp URL.
  5. Deploy clone site, configure direct access, discourage search engines from indexing it.
  6. Briefly verify that clone site is a visual match for production site (ask client to help with this).
  7. Briefly verify that interactive components of clone site are a functional match for production site (ask client to help with this).
  8. On clone site, deactivate and delete Elementor Dev and Elementor Beta, switch to stable version.
  9. Examine site and attempt to repair broken layouts and other issues.
  10. If needed, back out at this point if it looks like a massive job, and discuss costs and a way forward. Or continue.
  11. Repeat verification steps. Tweak Elementor Pro as needed until verifications match production site.
  12. If all is well, backup clone site to cloud storage.
  13. Transfer backup of clone site to production site.
  14. Restore production site from clone site backup.
  15. Repeat verification (much quicker this time).
  16. Decommission and delete clone site.
  17. Unfreeze content and features.
  18. Resume normal component updates.

So let’s get into it!

Content & Feature Freeze

In this critical step, your team and the client’s team must agree to a date and time to pause all content updates and any other kind of modifications to the site. At this time, it is also recommended to pause any updates to WordPress core, plugins, themes, translations, or anything else that could modify the way the site looks or operates. That said, we don’t recommend pausing updates for an extended period of time, for security reasons. New vulnerabilities (and their exploits) are disclosed all the time, and the strategy of pausing updates really only applies if the entire migration process is expected to be completed in a day or two. Even then you should watch the Installed Plugins page of your admin panel closely to see if any important updates show up while the site is in freeze.

Backup and Cloning

Take a full site backup, but lock it so that retention settings don’t apply to it, if your backup plugin supports this. Most backup regimes are set up to wipe older backups past a certain age, or when retained backups reach a certain number. To avoid losing this backup, you should lock it. Next, clone the site to a new instance. We use UpdraftPlus for backups, and this allows you to clone a full site to a virtual server in the cloud. It takes a while, but when it is done it gives you a custom URL so you can access the cloned site. UpdraftPlus charges one cloning credit for the first day, then a cloning credit per week thereafter, until you decommission the clone. Once the site is cloned, work only on the clone instance from here on – don’t touch the production site again until later.

Verification and Sanity Check

Briefly confirm that the clone site is identical to the production site. It should be. If it isn’t then you have done something wrong in the cloning process. Check the visible site as well as the functionality. But do this briefly – it is fair to assume that everything should be identical, especially if you have used an automated process (such as UpdraftPlus) to do the cloning.

Time to Break Stuff!

On the clone site, prepare to deactivate the Elementor Beta and/or Elementor Developer Edition plugins:

  1. Navigate to Elementor > Developer Edition
  2. From the Elementor or Elementor Pro section, click Re-install Now. This installs the latest stable release. Our client has Elementor Pro, so we did it for both. If you see an Update Now button, click that first.
  3. Now you can deactivate: Go to Plugins > Installed Plugins.
  4. Deactivate the Developer Plugin. Usually called “Elementor Beta” or “Elementor Beta (Developer Edition)”.
  5. Still in Plugins page, reactivate Elementor Core/Pro if inactive.
  6. Go to Elementor > Tools.
  7. Click Regenerate Files & Data.

Now Repair It

This is will probably wreck the site visually and possibly some under-the-hood functionality also. This is because the site might have been made with large chunks of it depending on Beta capabilities that are now no longer active. You will need to carry out some trial and error here, as you enable some things in Elementor to try to get the clone site functional.

In our case we tried maybe 25 different things, resetting the clone each time an attempt failed. But when it came down to it, we identified 2 critical aspects that solved 90% of the problems with broken pages:

  1. Enable Flexbox: Elementor > Settings > Features > Flexbox Container. Set it to “Active”.
  2. Enable Grid Container: Elementor > Settings > Features > Grid Container. Set it to “Active”.
  3. Save Changes

In our case, there were several other minor things we needed to do also. They were quite site-specific, so I won’t go into that here. The main thing is that the above pretty much fixed the site. In your case, if the clone now looks visually identical to the production site, on both desktop and mobile, and functionality works the same, then you have succeeded in your migration away from Elementor Beta and/or Developer Edition. Consider asking the client to check the clone site to ensure it is a visual and functional match for the production site.

Replicate To Production

Time to go back to the production site. The following is best done within a maintenance window, or during off-peak times. If there were few steps to fix the clone, you could run the same steps in production, then check everything carefully. Alternatively, if it was a more complex fix (or series of fixes) you could restore the clone over the production site. Whichever method you choose, verify carefully. If everything worked, you are almost done.

Decommission

When the production site is fully functional with Elementor Beta and/or Elementor Developer Edition plugins deactivated or deleted, you can go ahead and decommission the clone.

Unfreeze

The content & feature freeze on the production site can now be lifted. Carefully carry out any updates according to your normal process, or re-enable automatic updates if you are doing that. Your team or your client can now work on the site as normal.

And You’re Done

With the site now running only stable releases of Elementor or Elementor Pro, you can look forward to your site breaking much less often and much less severely.