This past week it was necessary for me to spend time migrating a website and helping deploy a new design for it. It was a frustrating and humbling experience that also reminded me just how much of a challenge these things can be. It wasn’t even a particularly complicated website. I figure it’s worth sharing with you, as my pain points touched many parts of our industry.
The details of the site I moved aren’t very relevant. I was migrating from one host to another, and then I was deploying the new “design” — which was created by a third party consultant — in the new hosting environment. So the process was multi-stage:
- Move the existing site to the new host, and start the time clock. The snapshot of the database was essential to maintain since there is periodic eCommerce activity via GiveWP.
- Migrate the “new” site design, which consists of a new theme, new content (mostly on pages), and a lot of settings in different parts of the customizer, theme, and elsewhere.
- Point the domain to the new site to launch it, add SSL, and resync any lost orders. Audit and test everything.
I’m sure there were better ways to go about it, especially ones that do not require being put on the clock to maintain order history. Since I knew the sync would only include a handful of orders, I decided I was okay with the gap. Thankfully the fine folks at GiveWP gave me some advice on how to get things synced back up easily enough, as things played out.
Something I learned in this experience is to not underestimate the differences and quirks of the database environment from one host to another. It wasn’t anyone’s fault, but what seemed like a simple site to me ended up not being so simple to migrate. The database was reasonably large, with multiple table and collation types. That made it more difficult down the line when I was exporting from the old host and importing it to the new one.
Another lesson learned is just how painful it is to both work with and migrate a Divi-based website. After I successfully migrated the existing site, the new site was (most unfortunately) “built” with Divi. Gutenberg is like a fluffy cloud to Divi’s thunderstorm.
While the front-end editing may be okay with Divi (I didn’t spend much time with it), the back end modular views are a usability nightmare. Buttons have no tooltips to explain what they do, and there are settings and options everywhere. It took a good while to plant my feet trying to use it all. Thankfully, they do have import and export options, but you have to be careful. You can import theme settings, module settings (whatever that is), and the individual pages. So, I did exports/imports for every page of the website. Free plugin idea: create a bulk export of all Divi content, settings, and media. Make millions.
Once I got things moved over, tested, and felt like I had the news site mostly in order, it was reasonably straightforward to finish up. But what was “simple” ended up being a multi-day project.
As a side note, I tried using multiple tools to make things simpler. For one reason or another, things just didn’t like talking to each other very much, or the error messages for why something wouldn’t work were inconsistent. So whether I tried PhpMyAdmin, WP Migrate DB Pro, or WP CLI there seemed to be consistent problems. That isn’t to knock any of those tools, which work very well when the environments on both ends of a migration are compatible. For instance, because I didn’t have access to the consultant’s development environment, I used WP Migrate DB Pro and their media and files add-ons to successfully rip the entire site into a local install (Local by Flywheel) so that I could access everything.
I was able to get my database woes solved by asking supporters to help (duh). Pagely got me settled on the database front quite quickly, for which I’m thankful. After chiding me for not asking for help sooner, Joshua Strebel reminded me that companies are there to help their customers. Don’t be afraid to contact support. I would’ve saved myself more than a day.
My bad migration experience illustrates how painful fairly common tasks are likely to be for site owners with less institutional knowledge and fewer relationships than I have. As I became frustrated in my efforts, I was able to talk to a handful of experts who helped guide me along. Others might have given up.
The web — and migrating websites — is still a challenge. There is a lot that hosts, product companies, and especially consulting companies can still do to help improve the launch and migration experience for customers — from documentation to tooling.
This consultant was not unique, but they put absolutely no energy into how the website would go live. I’m sure the customer (the folks I was helping) did not think about the technical details of their launch either since they don’t know what they don’t know. The consultant should have been out front, asking “what is our launch plan?” If you don’t do that, you’re not finishing the job.
I have no idea if anything here will resonate with you or your business, but I touched pretty much every segment of the Post Status audience’s business model with this little project, so I thought I’d share the experience.
I am glad my first world problems brought some joy to some friends in Post Status Slack 🙂 — which is also where I got some much-appreciated help discovering my unknown unknowns.