Howdy. I slept late Sunday morning (still made it to church, though), and now I can't get to sleep; so I figured I'd share some advice along the lines of moving accounts from one VPS to another without downtime, while it's still fresh in my mind.
Of course, most providers offer migration as part of the setup deal, but there are things you can do on the server you're retiring to make the process go more smoothly. This little guide, however, assumes you are doing everything yourself. It also assumes that the new VPS will have a new hostname and new nameservers, and that they have been registered before you actually start moving files. If you will be using the same nameservers, then the process is a lot simpler than what is described here.
Step One: Make a Decision to Move, and set a Date
In my recent case, I really didn't have two weeks; the service at the old datacenter had simply become intolerable. Ideally, though, make a decision to move, and then start researching new providers. Read reviews and (if you can) the company's own forum, as well as other Web hosting forums. Understand that any hosting company that has all positive reviews probably wrote them itself, so don't expect perfection. Then set a target date at least two weeks from the day you commit to the move.
Why? Well, it mainly has to do with DNS. By default, most VPS providers set rather long freshness intervals (often too long, in my opinion) on nameservers, and few clients ever bother too look at, much less change them. This is done to save resources and boost performance, but it also means that other computers requesting information from the nameservers may cache that information for several weeks. That's bad when you're moving from one server to another, and leads to step two:
Step Two: Tweak the DNS Settings on the Old Server
For at least two weeks prior to the move, the DNS settings on all the accounts on the the old server should be set to cause requesting computers to consider the information "stale" after a very short time. This will cause them to re-request the information frequently, which will help speed propagation when the change actually happens. Without getting too deep into how DNS works, I find the following settings to work well without hopelessly stressing the server:
SOA Refresh: 3600
Retry: 120
Expire: 7200
Minimum TTL: 3600
Many will suggest even shorter settings; but I think that most VPS moves are made because there are problems with the service that's being retired, so getting
too crazy could cause those problems to get even worse.
Step Three: Prepare and Test the New VPS and Company
The first test is, of course, how well the company fulfills your order. But once you have the VPS, play with it for a while. Install some software that you'll need, do some meaningless server-to-server file transfers to test the connection, do some traceroutes or a sustained MTR, rebuild Apache -- that sort of thing. And put a few tickets through to see how the support staff responds, preferably at different times of the day.
Then move a test account or two onto the server and install some gluttonous applications (galleries, forums, whatever bangs your shutters) to see how they work. Remember that in most states, you have three days to cancel the order with no obligation, so use this time productively to test and prepare your new VPS.
Step Four: Copy the Accounts
If you're using the same control panel on both servers, this is easy. Otherwise, it can be long, tedious, and time-consuming to move all the files, databases, and settings, but it's not particularly difficult unless you're a rank newbie. If you have any problems, then ask the new host for help. They want your business and usually will help you move. They also may charge for this service, although most don't.
Step Five: Back into DNS Again
Immediately upon moving the sites, go back into the
old server and change the DNS settings as follows:
- Change the A entry for the domain to the new IP address.
- Change the A entry for FTP to the new IP address.
- Change the CNAME entry for mail to an A entry with the new IP address
It may also be necessary to change the entries for subdomains, forums, etc., depending on how you have them set up.
Step Six: Change the Nameservers for the Domains
You do this in the registrar's control panel. Of course, if you will be using the same nameserver names, then all you have to do is change the IP's of the nameservers once all the sites have been copied.
Step Seven: DNS Again...
I also like to initially tweak the DNS settings on the new server. I usually set the initial DNS Zone times to something like:
SOA Refresh: 7200
Retry: 7200
Expire: 1209600
Minimum TTL: 3600
to keep them low, but in line with the RFC's. Most hosting companies set them much higher by default to save resources; and once I develop confidence in the new host, I usually increase them, as well. But initially, I want to keep them in a lower range -- just in case things don't work out so well with the new host.
Step Eight: Wait
Don't be too hasty to cancel the old VPS. First of all, it may still be handling some DNS requests that were cached in other computers. Secondly, your new server is, well, new; and it's prudent to keep the old server up and running for a week or two -- just in case your new hosting turns out to be not so good.
I like to leave the old server running for at least a week after making the NS changes on the last domain to be moved, or until it has received no requests for 24 hours. After that, you can delete all of the accounts (including its own hostname, if you like; the hosting company can access it by IP address or other ways) and close the account.
I still have a few accounts to move over to BodHost because those particular clients hold the domains themselves and have misplaced the passwords. So I'll have to call the registrars to get that straightened out. But using the above steps (except that I didn't have two weeks), I have moved all the rest of my clients' accounts, and all of my own, to my new BodHost VPS, with no downtime and no loss of mail.
I know the temptation when changing hosts is to just do it NOW, both because no one wants to pay for an additional machine, and because most often we're less-than-thrilled with the company we're leaving. But whenever possible, an orderly, planned approach will eliminate (or at least minimize) downtime and mail loss, and will help keep your clients happy.
Comments and criticism welcome.
Goodnight,
Richard