Dummies' Guide to Switching VPS Providers

[RichardM]

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:

1. Change the A entry for the domain to the new IP address.
2. Change the A entry for FTP to the new IP address.
3. 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

[BodShane]

Great Work Richard

We definitely appreciate your contribution to the forum.

[RichardM]

Thank you.

[RichardM]

One more thing:

Many of us like to run an additional instance of Exim on Port 26 (or sometimes other ports; 26 is the default for an additional Exim instance in WHM) so clients whose ISP's block Port 25 can still use our SMTP service. If you have this option enabled on your old server but not on your new one, you will start getting (often angry) calls from clients early in the morning informing you that they can't send mail.

So if you have the option to run an additional instance of Exim on port 26 (or whatever other port you use) enabled on the old server, make sure you also duplicate this setting on the new server.

Richard

[Christina]

Yes, Indeed

We made the exact changes. Ofcourse, our Bod support team responded well to it.

[Rodricks]

Thanx Richard for this informative post.

[RichardM]

You're quite welcome, and thanks for the kind words.

Richard

[RichardM]

Well, I migrated the last of my accounts over from the old server, with no loss of uptime. I did have one problem when I moved the account bearing the old server's domain hostname over, though.

What I did when I was ready to move that account was copied the files over to the new server and made the changes to the old server's DNS as described above, except that I left the entries for vps.thehostname.tld on the old server, and also created an A entry for vps.thehostname.tld on the new server, pointing back to the old one. I did this only to allow the old server to continue providing DNS services for a few days, and that part worked fine.

What didn't work out so well was that I forgot that I had created the account on the old server as root, of course, since it was also the server's hostname; so everything was owned by root. So when I moved the account, the mail and some scripts stopped working because of a permissions problem.

I had two basic options at that point.

The first was to undo the move by changing the NS entries to point back to the old server, then changing ownership of the whole account to a "reseller" that I would create on the old server, and then moving it again and carrying over the reseller privileges. This would be the easier way if I'd had a stable connection at the old DC. But even in the middle of the night, what I had was a flaky connection.

The second was to manually change all the permissions on all of the files on the new server that needed user, rather than root, ownership. Although it may seem strange, this is the option I chose.

See, there really was nothing on that domain to speak of. I used it mainly as the server hostname. There is a poem, a few bread recipes, and a phot gallery that NO ONE ever uses except me and can easily be re-created. There also were four email addresses (besides the account address, which is never used and which did acquire proper permission on the new server): mine, my parents' two, and one of my brother's.

So basically, although tedious, it was easier to manually change the permissions on the few directories and files that needed changing than it would have been to FTP even the modestly-sized tarball across that flaky connection again.

But in any event, all of accounts have now been migrated and have resolved, and I canceled the old VPS account last night. It was rather sad, actually: I'd been with that company for years, and the server itself had always performed magnificently. It was the DC that was the problem, not the server. When I turned off the old VPS for the last time, I felt like I was saying goodbye to an old friend. :(

But now I'm here, and so far everything is magnificent. I hope it is many years before I have to contend with closing a VPS account again.

Richard

[BodShane]

Richard,

We are glad that you have joined bodhost and we will always look forward to provide you with great servers and service.

[Sean]

Perhaps, email configurations are variant and they will require manual settings. However, again it is not the same situation everytime.

[RichardM]

Samantha, I think it was just because it was the previous hostname that was being copied, and that it had previously been created as root. But the way it transferred, ownership of the account itself transferred to the cPanel user name, but ownership of the files and directories still belonged to root. That was the conflict: The account didn't have permission for its own files.

I don't know if skipping the reseller privileges when creating the tarball would have prevented this, and I didn't bother to research it. With so few files to worry about, manually changing the permissions was easy enough and took less time than troubleshooting would have. There may have been a quicker fix; but sometimes, finding the "quick" fix takes more time than just going ahead and doing it the old way.

Richard

[Sean]

I definitely agree. However, few clients still have to say much about manual configurations which they had configured earlier :D