Our experience migrating to a managed Wordpress host
We recently migrated our LAMP (Linux Apache MySQL PHP) dedicated server hosting environment to a managed Wordpress dedicated server hosting solution. If you aren’t familiar, managed WordPress hosts take care of all technical aspects of server architecture, performance, resource provisioning and security while providing a portal to manage virtual hosts, DNS, SSL and other site specific configurations. In this post we’re going to review our experience and lessons learned.
Previously we had been hosting our Linux server at a managed hosting provider. We were familiar with our hosting company, on a first name basis with support staff and had a high level of confidence in their ability to maintain our high standards with regard to availability (99.9999% uptime outside of scheduled maintenance).
Our needs had grown beyond simple managed hosting and we wanted to find a host that had more Wordpress-specific expertise and could help us balance security with practicality and utility. Our dedicated environment was very secure but at the cost of flexibility. Our needs had outgrown the standard CentOS LAMP stack that we were running.
Some of the requirements for our new environment were:
- Individual sandboxes for websites
With a traditional architecture if one site crashes PHP, the server suffers. Sandboxed applications are logically separated with less opportunity for system-wide impacts. With a highly targeted platform like Wordpress, this approach also provides security benefits. - Flexibility with PHP versions and upgrades
As new versions of PHP are released, previous features and syntax are deprecated or removed completely. Being able to run different versions of PHP on different applications gives the ability to support legacy code on older versions of the framework while deploying new applications to the latest version. The ability to upgrade or downgrade PHP individual instances of PHP with the click of a button turns traditional server-wide upgrade models on their head. - Create and restore snapshots of the site efficiently
Being able to backup a site before deploying code provides peace of mind that doesn’t come along with more manual risk management approaches. We’ve always been able to make backups and use version control software that can rollback updates but that approach involves a number of manual steps.
We needed a Wordpress hosting solution that would evolve as Wordpress and our needs evolved.
Before I get into our experience, I want to urge you to do your own research. A Google search for comparisons between managed Wordpress hosting services brings up dozens of results. You’ll find that the comparisons vary depending on when the article was published. Managed Wordpress hosting companies are in a virtual arms race trying to keep up with one another’s offerings. The playing field is constantly changing. This means that the most accurate data you are going to find is by researching the companies’ websites to supplement third party critiques like this one.
After researching WP engine, Kinsta and Flywheel, we engaged with WP Engine to learn more about their offerings. Our research was primarily done by visiting the vendor’s websites and reading articles as well as more analytical head-to-head comparisons. WPE’s sales process involved an introductory call with an account services person which was followed up with some information gathering on our end and a follow-up call with one of their engineers.
They were very thorough with their approach to assessing needs. We were asked to gather a number of metrics using the Wordpress CLI (command line interface). WP Engine’s reputation rests on their ability to serve up fast performing sites so they want to ensure that they recommend the appropriate server profile. They have a few different dedicated environment offerings to fit different traffic and site usage needs.
I had two follow-up calls with WPE and one of their engineers. The engineer was good at his job and provided in-depth technically oriented answers to most of my questions. They followed up over email with answers to the few questions that I was able to stump them with.
Support as a Priority
The focus of many of my questions had to do with their support organization. Not just were they responsive and knowledgeable but did they understand the importance of their role in our business? If I was in a moment of crisis would there be someone to talk to that could affect action on their end? Would there be someone dedicated to executing and following through on items that required more than a standard response?
One of the strengths of our legacy host was the personal touch. All of the techs know us by name and if I needed to talk to the COO or CEO, I could. They were also pretty good at making sure things never get to that point. They aren’t a mom and pop operation, either; their annual revenues are in the eight-figure range but they still provide personalized customer service.
However, even though I spent close to two hours in discussions with WPE around our needs and requirements, I still didn’t ask *all* of the questions that I should have. More on that later.
Taking the Leap
After due diligence, we came to the conclusion that WP Engine was right for our hosting needs. With them we would gain some new features and functionality that would add value to our overall hosting offering. WP Engine would also provide us with tools that help to maximize our efficiency in managing our numerous sites.
The information that we didn’t have could only come with experience so there was a calculated risk.
Migrating to WP Engine
The migration process to WP Engine was, for the most part, very straightforward. WP Engine offers a plugin that moves all of your website files and data to a virtual host on their server.
There were things I found out after migrating that weren’t disclosed during onboarding or the sales process that would’ve been nice to know. None were deal breakers but the kind of things you want to know ahead of time instead of after the fact. The primary finding of note is that Wordpress revisions are disabled by default as part of the site migration regardless of the setting on your legacy site. Not knowing this led to some confusion when the Wordpress “preview” functionality was no longer working on our sites. In order to preview Wordpress post updates, post revisions need to be enabled.
Dark Skies
We experienced one major issue that brought to light some downsides when hosting with WP Engine. One of the sites that we were migrating used a custom plugin that Tenrec developed that is used to export Wordpress content to docx format (MS Word). That plugin and the associated 3rd party code that we integrate with requires a PHP module called “HTML Tidy.” HTML Tidy is a tool that parses and cleans up HTML (to ensure that it is well-formed among other things).
Our testing determined that while HTML Tidy was installed on our WPE server, it was not activated. We opened a support ticket with WPE requesting that the library be enabled for our environment. WPE support replied that this was not possible without enabling it across their entire hosting environment. WPE support indicated that they would review the library and possibly add it to their environment.
Note that, during the sales process, it was communicated that individual sites on WPE, even those on the same dedicated server, are sandboxed from one another. This allows sites to run different versions of PHP from one another among other benefits. We were surprised to learn that enabling a module like HTML Tidy for one site would require enabling it across their whole platform.
Subsequently, after conducting their review, WPE decided that the HTML Tidy module could not be enabled. We tried to engage them on this decision but, unfortunately, there is no appeal process and no account manager to advocate for us. (Our account manager proved to be more of a sales person than someone focused on customer satisfaction.) We could only interface with their front line support and their replies were more about cutting off the discussion than helping with a solution.
To compound this, there was no satisfactory explanation. What we were told was essentially that WPE wouldn’t vet HTML Tidy because not enough of their clients needed the library. We provided data stating that there were no Common Vulnerabilities or Exposures (CVE) known for the HTML Tidy module but these were given no further consideration.
The WPE platform is a lowest common denominator platform and they may not be willing or able to support your requirements. In one of the support responses that I received from them, they referenced the 90,000 websites that are successfully hosted on WPE as if there was something wrong with our site that kept it from being successful there. With current estimates of 75,000,000 Wordpress sites on the web, that leaves quite a few that are not hosted on WPE for one reason or another.
Kinsta to the rescue
We wanted to have a single platform for hosting all of our Wordpress instances so we persisted to get our docx plugin working without the HTML Tidy module on WPE. No matter how creative we got, nothing worked, at least within reason. We decided, instead, to look at another managed Wordpress hosting provider to take on this particular website. We looked at our options and decided to give Kinsta a try. My initial interaction with them went something like this:
Mike said:
I am hosting a site at WP Engine. There is functionality on the site that isn’t working because the html-tidy php extension is not enabled in their environment. Is that library enabled on your environment if I were to host that site with kinsta.com ?
Kinsta said:
Hello Mike,
Thank you for your interest in Kinsta!
We do not have that extension enabled by default, but we can certainly install the PHP extension tidy upon request!
I hope this information helps! Should you have any additional questions, please don’t hesitate to let us know.
Thanks, Melissa
Just like that we had a solution. We set up an account and migrated over the site without incident. Our docx export tool worked as expected and we didn’t have to modify a single line of code.
While it would be nice to have all of our hosted Wordpress environments on the same platform, it’s been good to have first-hand experience with both platforms. Both have some great features (and some not so great) and are evolving to further meet the needs of organizations like Tenrec that have rigid security, performance and uptime requirements.
Final thoughts on Kinsta and WP Engine
WP Engine takeaways
- WP Engine is limited to only Wordpress hosting; no non-Wordpress PHP applications. We had to commission a separate Amazon EC2 LAMP server in addition to our WPE dedicated server to fully replace our legacy LAMP server.
- You get what you get. If you need any configurations outside of the norm, WPE may not accommodate you. Thoroughly review all of the various libraries, scripts and custom functionality that you may take for granted. WPE offers a 30 day money back guarantee which is a good opportunity to test any edge cases.
What does the future hold?
Managed Wordpress hosting has lots of shiny bells and whistles and can introduce efficiencies in process and flexibility in architecture. The piece that was missing for us is having a personal relationship with our hosting provider. It is difficult to replicate the results and peace of mind that come from a relationship where we aren’t just a number.
There is a new class of tool that seeks to bridge this gap between technology and service provider. There are a number of software-based control panels that add a managed Wordpress software layer to traditional dedicated server hosting. The result is a best of both worlds solution that provides the functions, efficiencies and security benefits of a managed Wordpress host with the control and accountability provided by a traditional managed server host.
A few of the front runners in this space are SpinupWp, RunCloud and Cloudways. Tenrec has had great experiences with the tools made by Delicious Brains, the vendor of Spinup WP, so we will ‘spin up’ a pilot project using their tool in the future.
In conclusion
We hope that our experience of changing both our server architecture and hosting vendor has given you some insight if you need to make similar changes for your organization.
Addendum
During the time that this article was being written, we found an alternative solution to our HTML Tidy requirement and were able to migrate the site instance that we were hosting at Kinsta to our dedicated server on WP Engine. We’ve consolidated our technology which was our ultimate goal. Kinsta’s platform has some merits but at the end of the day, we felt that WP Engine was a better fit for our needs.
If you’d like to know more about some of the more noteworthy differences we found between the Kinsta and WP Engine platforms, please read our companion piece, A head to head comparison of Kinsta and WP Engine.