Migrating to WP Engine
On 22 March 2018 we migrated the University WordPress multisite installation from St Andrews to WP Engine. One month on, what has our experience been of WP Engine and what lessons have we learnt from the migration process?
Why WP Engine?
Automatic updates to WordPress core
Prior to moving to WP Engine we had to spend a lot of time looking after updates to WordPress core. The process would typically involve manually copying content from the production server to the test server then updating the test install before eventually updating the live install. Due to the time taken to do this we were always behind the latest version of WordPress. Having WP Engine take care of this updates for us is a big relief.
Great customer support
We chose WP Engine as our hosting provider for a number of reasons. Firstly, their support is excellent, with 24/7/365 access to WordPress technicians via email and online chat. With chat we have found that they have consistently been available with a few minutes of initiating an online chat session. We have been able to resolve most of our issues this way, with only one or two issues being transferred to a support ticket that is handled via a separate system.
The only problem with the online chat is that you have to type your request within a very small window. There is no way to expand the viewable space.
The online documentation is excellent and comprehensive. If you are not familiar with WP Engine, a good place to start is the documentation that describes the features of their platform.
Dedicated WordPress hosting
WP Engine just support WordPress. Their servers are optimised using a variety of technologies to ensure the best performance in a way that we could not easily achieve with our previous setup. We are now using PHP 7, with a noticeable improvement in responsiveness when accessing a site and managing the content.
The portal is used to create and manage the WordPress installs. One of the strengths of WP Engine is that the user portal is very easy to use. From here it is very easy to create backup points, copy an install to another server, manage SFTP access, etc.
Each WordPress install has a staging version. A staging site allows you to do testing that is independent of the parent site. It also benefits from not having any caching so it’s ideal for development purposes.
Creating a copy of the main site on a staging site is very easy, just one click from the main WordPress dashboard. The URL for the staging site is something like site.staging.wpegine.com.
Copying the staging site to the main site is also a simple process.
WP Engine takes backups every day and keeps up to 30 days of backups. Creating a manual backup point prior to say updating a plugin or theme is very easy to do. WP Engine will automatically take a backup before updating the core WordPress version.
WP Engine take care of ensuring our WordPress installs are kept secure. They provide a hack proof guarantee, which is very reassuring!
Before we could commit to moving to WP Engine we had to resolve how we were going to manage user logins via the University single sign on service. We use the Authorizer plugin to allow users to authenticate via the University CAS server. Configuring the plugin was straightforward, but we had issues with users having to continually login to manage their sites. In the end this was resolved by forcing all links to go over https.
WP Engine provide a plugin to enable an easy migration of WordPress sites. However, in our case we couldn’t use it as the University firewall prevented its use. Therefore we had to carry out a manual process. This involved the following steps:
- Stop users from logging into the existing site.
- Download all content from the wp-content folder to a local computer and then zip it (took about 2 hours).
- Export the MySQL database and download to a local computer and then zip it (took about 30 minutes).
- Upload wp-content to WP Engine install and ask WP Engine to unzip the file and set file permissions (took about 2 hours).
- Upload MySQL database to WP Engine and ask WP Engine to unzip and change all references in the database that referenced the old domain (took about 2 hours).
- Remove plugins that are not supported by WP Engine e.g. WordFence and configure plugins used to manage single sign on.
- Change DNS settings to point wp.st-andrews.ac.uk to the WP Engine server.
We tried out two trial migrations before the final move to ensure the process was as smooth as possible. For the final move we gave ourselves from 9am on a Wednesday through to 12 noon on the following Thursday. During this time we prevented WordPress users from logging into the existing site.
Following the migration we had a few teething issues with some sites having missing images, but these were quickly resolved by WP Engine.
One month on
Overall the migration to WP Engine has been straightforward and very positive. The issues we had to resolve were due to some custom plugins and themes that need to be removed or modified to work with WP Engine.
The recent update to WordPress 4.8.5 was completely painless and involved no interaction from us. It is a big relief to not have this responsibility any more!