Outside the Cube

5 lessons learned from moving my hosting company (and moving it back)

For all of the talk from me about project management, there are times when I really step into it. This was one of those times — moving my sites from one hosting company to another.

I maintain seven websites, including this one. In my case, there are three big components for my website hosting: A company where I manage my domains (this is where “name servers” are stored), a company where my websites are hosted (where all the files are kept and managed), and a company that performs a CDN (Content Delivery Network) function that takes those stored files, distributes them around the planet and delivers the pages you see incredibly fast.

The deal is, my websites were performing well — pages loaded quickly, I was happy with my hosting company, and I was able to ignore that whole aspect of managing a platform because it was working well.

Since I also use WordPress, there is a group of hosting companies that are focused — by design — on just WordPress sites (like all of mine). They tout a couple of benefits: they build high-end hardware with limited features oriented to WordPress sites that provide a big boost in the speed of the site and a simplified administration rather than the (intimidating) cPanel offered by most hosting companies.

So even though I was happy where I was and my sites were loading fast, I thought I could do even better with a different hosting company focused on just hosting WordPress hosting.

So I moved. The before and after WAS impressive. Check out these speed graphs for Ten Keyboards, my test site, from Load Impact. This is a speed test that increases the number of users on the site dramatically over five or so minutes. I saw how, despite the increasing number of users and transactions, the pages were consistently rendered around one second.

This was encouraging.

But then stuff started to go south. The net of it ended up being two things. One, I couldn’t get the Content Delivery Network (either CloudFlare or Amazon’s CloudFront) to work with the new hosting company. This is a serious disadvantage in that the one second you see above could easily drop below the 500ms line for the sites. This is a big deal; the speed. There are lots of studies that show slow load times means people go away. We don’t want people to go away because of the slowness of our site!

The second reason was that email was surprisingly inconsistent and the web version offered was really poor to work with (the UI, or user interface, for those interested). And their instructions for setting up the email (and I’ve set up a ton of email accounts in my time) were incorrect, starting with suggesting not to use SSL (encryption for the sending/receiving of email) even though there entire server setup was SSL enabled. Apple devices, of which I have every one(!), will search for those SSL settings automatically, and they automatically found them. Very weird.

Now, I opened tickets for all of this when I couldn’t get things to work and the service and support was very responsive. But when the support team couldn’t get the Content Delivery Networks to work (either one), I was done. Especially since the two I could use were both recommended by the hosting company!

So I moved all the sites back to my original hosting company.

The thing is, from an efficiency and strategy perspective, I really could have done all of this much better. Here are the reasons:

1. I should never have moved in the first place

As I noted, I wasn’t paying any attention to my setup — it was working fine. And a few spikes at a two-second delivery time is not impacting the site – especially when the balance of the time, the delivery of the web pages was well below a second.

Because of the way websites move (via Domain Name Servers), it can take up to 36-hours to have a website fully move from one hosting company to another. And it did. I always move sites on a Friday night so by the time Monday rolls around, the sites are fully up and working from one location. Well, it also means I can’t do anything during that weekend — like creating content on the site — so I just lose the time.

And things still need doing even though most hosting companies will move your site for you. Things like getting FTP accounts set up. Get the new email settings on all your devices. It takes a lot of time all lost to creating for your audience.

2. Mail is much more important than you first think

If you have your email with the same hosting company (versus Gmail, for example), your email accounts will also move with your websites. I didn’t really prepare correctly for this move — all of my saved emails were still at my former hosting company. I didn’t copy them over and the accounts were already moved.

This could have been much worse than it was in the end because I moved back. But I needed to think through email far more than the casual way that I did when I moved the sites.

3. I didn’t have a testing plan for after the move.

One assumes things will work the same way someplace different — after all, it’s all the same code and the same files. But, that’s not the case. Certain plugins I was using did not work at the new site because of the way they built their WordPress specific environment (this is not unexpected; what was unexpected was a plugin to adjust colors and fonts on my standard theme didn’t work).

Instead of having a test plan and going through the list to see if everything was working, I sort of discovered (read: at the worst possible time) that things didn’t work the same way. It was exceptionally frustrating.

4. I didn’t have a set of goals for moving to the new site.

Sure, I wanted more speed for the sites, but that was about it. I should have had goals for email, for service, for speed, for ease of managing the sites, and how much you have to interact with the support team.

For example, I use a Spam firm that filters out spam from my email before delivering it to my email box. It’s called MailRoute and works really well. To route correctly through MailRoute, you need to set up what are called MX records so the server knows how to route your email, sending it through MailRoute first. In my old hosting company, I could do that myself. In my new hosting company, I had to open up a ticket to do that. I had to tell them exactly what the record needed, so I’d just as easily could have set it up myself.

Without these goals, I sort of went along seemingly randomly running into things that just didn’t work the same. The reason I moved back was because, at some point during the week, I simply had enough frustration and said it wasn’t worth it anymore. But that would have happened faster — with far less frustration — if I had the goals set up so I could compare.

5. Moving your hosting company will take five times the amount of time you think it will.

Yes, they moved my sites for me (very grateful for that — not ALL hosting companies will do that for you). But the amount of time I spent on getting email to work – and then work again once I moved back!! – along with the tickets to get resolved and trying different things out to get stuff to work was far more time than I thought it would take. It was like there was a clock tick-tocking in my head over the amount of time all this was taking.

In the end, I should have had a bunch of checklists to use to prepare for the move, do the move, and a testing checklist for after the move. It would have made a world of difference. Not in the decision to move back, but in the level of frustration with how things were going to accomplish the move.

By the way, I did some tweaking of the settings after I moved back to my original hosting company. Now the same test drops pages consistently around a second (the opening part is when the pages cache the first time). No spikes. It’s more than good enough.

Have you ever moved hosting companies? Moved back? I’m curious about your experience.

​Read More