Movin’ on up
We’ve finally found a new home for the SlideShowPro website and the move was completed last weekend with only about 30 minutes of downtime. How’d we do it? Why’d we move? Who did we choose? Read on to find out.
The Why
First, why move in the first place? Moving a website to another host is a pain. Just like a house or apartment, the longer you stay at one host the more embedded you get and the harder it is to move. The SlideShowPro site has been hosted on a shared account at Dreamhost since its inception in early 2005 and includes a variety of components (customer management application, statistical tracking, user forums, etc) all of which use their own database. Moving all that wouldn’t be easy, so there must have been a compelling reason for the move, right?
Dreamhost became the darling of shared web hosts a few years ago and this very blog is hosted there (and will remain there) as a matter of fact. However, over the last year or so, we’ve encountered several setbacks with Dreamhost that included quite a bit of downtime as well as our site getting hacked a few times. In June alone, we had 2 or 3 complete site outages ranging from 3 hours to (in one case) over 12 hours. So, the reason is very simple: Downtime equals money. And if our site goes down for 12 hours, it hurts and at the end of June our sales numbers showed just how much. Turns out that many of the outages were caused by another account on our server getting DOS’d (Denial of Service attack), which Dreamhost remedied by continually changing the IP address of the server which caused DNS lookups to fail.
A non-technical way of putting this: Imagine owning a store. Randomly, a security guard comes by and throws people out of your store, then locks the doors. When will he come back? Well, you have to call the security company, leave a message and they will get back to you. They eventually do, and you find out that the reason your store was closed down was because of what the store next to you was doing. That is very similar to what happens in shared hosting environments.
The Who
We chose Media Temple for a lot of reasons, but mostly because of how impressed we were with their people and the good things we had heard about their Dedicated Virtual system. In a DV setup, the server’s assets are apportioned to you and only you, so you are guaranteed a certain amount of those resources and any other account on the same box will never be able to touch them. You also have full root access, so you can set up the server however you please.
We got the keys to our new server the first week in July and started getting things setup. A big thanks to Chris Lea and the rest of his team at (mt) for providing great support along the way. We even had a little fun trying to track down one of the strangest problems any of us had seen in a while. If it were Dreamhost, something tells me I would still be trying to convince them there was a problem in the first place.
How to minimize downtime
One of the more painful portions of migrating to a new host is the time it takes for the new DNS settings to resolve. A few years ago, this could take 2-3 days and even though it is better now (most of the time less than 24 hours), it still means downtime since some of your users will be visiting the old site while some will be directed to the new one. When everything is built on top of a database (or in our case, databases), that can be a very messy situation.
Once we had the new box up and working with a snapshot of some old data, we were ready to migrate the live data. What we did was take the site down for about 30 minutes just after midnight on Saturday. We used a rewrite rule to make sure any request was routed to a “Be right back” page, ensuring that no purchases, forum posts, or any other data was added or modified. During those 30 minutes we dumped all of our databases to SQL files, transferred them to our new server and used the dump files to populate the new database. Then it was as simple as pointing all of our existing config files to use the new database, that way both sites would be using the same data set and provider. Once that was done, we could change the DNS whenever we wanted. Even if users landed on the old site, it would be using the new database so nothing was stale or lost.
One tip for doing this: Point a domain that you aren’t using for anything to the new server early in the process (we did this as soon as we setup the new server). This will give you an external domain to test with and use to reference the database so that it is not tied to your main domain, which is what makes this work through the DNS switch.
All in all, we couldn’t be happier. The site is snappy and we fell much better knowing that we have full control of our box and will no longer feel the pain of the “bad neighbor” effect of shared hosting. It’s also nice to know that a solid, prompt support team will be ready to help if and when things go south.