Moving a site to a new host: best practices?

Hosting
1

I’m moving several web sites to a new host for my client.

Because domain name changes may take as much as 48 hours to propagate across the Internet, there will be a long interval when some users see the old site and some see the new one.That’s a problem for one site, because it processes transactions which update a database, and uses sessions to maintain state information. That causes technical difficulties which I need to address.

This is a problem which must affect thousands of web sites each year, and it seems to me that web developers and site administrators must have some useful experience in solving it. I’m looking for suggestions that draw on that experience, whether in the form of tribal wisdom or (preferably) codified as “best practices.”

Here is my thinking so far about the technical problems themselves:

Users who get the old site will update the old site’s database; users who get the new site will update the new site’s database. At the end of the transition we’ll have a different set of new transactions in each database, and no way to merge them.

I’ve been advised to deal with this by taking the site off-line briefly for the transition. While it is offline I’ll move the database from the old site to the new site and point the old site’s scripts to the new site’s database. When the site comes back on-line it will run in parallel on both hosts for a couple of days, but both hosts will use the same database. That appears to be a satisfactory solution.

The session problem is thornier. If a user is in the middle of a session when the domain name server they depend on is updated, they’ll be shifted from the old server, where the session is defined, to the new server, which has never heard of it. Result: error messages, lost work, general unpleasantness.

I thought about writing a session handler that stores the session data in the database, but that’s not a solution because the new server can’t get the data without the session ID, and in the scenario I just described, it won’t have the ID.

2

It doesn’t take anywhere near 48 hours for DNS to propagate. It’s closer to minutes. I’ve had DNS propagate in 5 minutes or less. The problem arises from DNS being cached. When you type in a domain name, your ISP is probably going to cache the IP address to serve future requests. Use a proxy server like hidemyass.com after the DNS change is made to see how quickly it occurs.

Most of your concerns are unwarranted. Take the old site offline in the middle of the night when traffic is low. Or redirect to your new site based on IP address. There a number of things you can do with minimal interruption.

3

You might want to consider using cookies instead of sessions to maintain state, or use a cookie in parallel with sessions stored in a database, with the cookie used to resurrect a new session.

4

Cheesedude, I worded my question carelessly; it’s cache refresh that concerns me.

My concerns arise from a warning on the old host’s (also the current registrar’s) web site that DNS changes can take up to 48 hours to take effect for all users. Is this merely overkill? If a really small fraction of users (e.g., <1%) will still see the old web site an hour or so after we pull the trigger, we can live with that. If a very much larger fraction of users take that long, it will be a serious problem.

Eastcoast, using cookies is a good thoughtful suggestion but probably not a wise approach in this particular case. The state information stored in the session is complex; we previously passed it through hidden form fields, and making all of the pieces emerge in the right place was a nightmare. Serializing it in cookies might be nearly as bad. Also, some of it raises security issues, and shouldn’t go to the customer’s computer in an accessible form. Yeah, we could encrypt it, but that would add another billable task on top of pressing it into cookies, all to support users during a few hours (at most) of transition. We can’t cut off a significant number of users for more than a short period, but we have to balance the benefit of the approach we choose against the cost.

5

Yes, it is overkill. Those warnings are from many years ago when it did take a very long time for DNS to propagate. I registered my first domain name in 2002 and it took many hours to propagate, but still no where near 48 hours.

If this is still an issue, you can always redirect visitors seeing the old version of the site to the new site by IP address. Then everybody goes to the new site.

6

you can always redirect visitors seeing the old version of the site to the new site by IP address

A good point… one that I (and the people in the first forum where I asked this question) missed completely!

Your advice about refresh is reassuring, but this suggestion solves the problem completely.

7

A consideration for the future perhaps is that if you had a load balancer that was session aware in front of your web servers (e.g pound or haproxy) then you could just plug/unplug old and new servers into it.

Remember and lower the TTL on the nameservers a few days before the switch. the One area I’ve found where DNS updates can still be slow (in the region of 48 hours) is with users on large corporate networks, where there can be another local DNS cache. The IP redirect is a good idea as long as you’re not using name based vhosts in the new server’s apache configuration.

8

EastCoast, also good advice. I didn’t realize I could control TTL on the name server. (It’s operated by one of the mass-market hosting services, so I’m not confident that I can, but I’ll look into it.)

Someone in the other forum pointed out a problem I hadn’t considered: how do I provide an SLL certificate for people who are redirected from the old site to the new site?

The new site actually has a pre-existing “domain name” of the form www.hostname.com/~accountname/. That’s something an SSL certificate could cover, but the host doesn’t provide one, and even if I can buy a certificate to cover that type of name, paying for a year of coverage to solve a 48-hour problem seems like a poor bargain.

9

During the process of moving the site to a new host, if we don’t have enough experience and skills, it might lead to downtime. This can be avoided if we follow certain steps.

  1. The very first step is to take a backup of all the files from the older server that has to be transferred to the new server. All the files such as images files, database files and text files have to be taken backup. Though it is hectic and a long process it is very important. For backing up DB files, the phpmyadmin in the control panel can be used and for transferring the other files, we can use FTP and transfer it to the local hard drive.

  2. The next step is to upload the files into new server. During this upload process, making sure the path name is correct is very important. It is preferable to use database upload software for this process. When some error occurs in the file path, during the migration process, we will have to encounter the errors.

  3. The third step is to add the email accounts to the new servers. After it is done, the 4th step is to test the temporary mirror site on your new server. All aspects such as functionality, images everything has to be checked out. If any errors occur in the database connection etc in the mirror site we have to correct it immediately.

  4. The last important step is to change the domain name. It means that we are instructing the registrars that we are changing the domain name. We can update the DNS servers. It is a common mistake to change the DNS beforehand. If this process carried out, then the site will be down during migration. After 48 hours the DNS will be updated after which we can access the site.

10

I migrate sites frequently at work… If you have enough access on one of the servers to allow remote database access, this can be one answer to keeping BOTH ends operational during the DNS migration.

Either, set the site up on the new server and tell it to use the old server’s database, or copy the database first - this will lead you to a few minutes of actual downtime while the db is shifted.

Update the DNS and wait - some users will start talking to the new server instantly, others will be using cached dns to talk to the old server. Once this has expired, you can then complete the migration and disable the old server.

11

You can do it by adding A record, DNS propagation won’t take more than 2 - 3 hours in normal case, but around global it will vary.

You can also study the less traffic time for your site and schedule a migration in that time period.

12

I can’t stress enough the need to backup. It should be a daily task and really helps in the moving process.
Obviously having the DNS name server change smoothly is also important but the content is the heart of your site so you must take care of it first.

13

I agree entirely that backups can not be stressed enough. Back your site up daily and if you have a massive amount of content that you don’t want to lose then back it up twice. Onsite and offsite as well as cloud backups are all options. Your provider may even offer additional backup services above and beyond what you may need but it never hurts to put “yes” yet, another backup into play. Data loss can be disastrous and costly in time and money.