Migrating a Web Site
June 25, 2001

by James Mendelsohn

As companies expand, merge, or move to cut costs, migrating a Web site from one physical location to another becomes an important part of normal operations. Curiously, there is little written on the logistics of migration. This article is an attempt to fill that void, and it is organized into the following:

• A brief section on migration goals and principles
• The planning and necessary order of migrating site components

Goals: Minimizing Expense and Disruption

The goals of anyone moving a Web site from one physical location to another are:

• To minimize if not eliminate any disruption of the site, from error messages to downtime.
• To reduce the expense of moving as much as possible.

Principles: One Person in Charge and a Comprehensive Migration Document

Your Web site administrators may find it especially important to be extremely well-organized, which translates into a couple of key principles:

• Ensure that there is one and only one person who supervises the move, someone who is detail-oriented but capable of efficient management. That person will:
  
  
  • Make the important decisions about the move.
  • Address any problems that arise, from the most hands-on technical problems to coordination of resources.
  • Liaise with and call for additional help from other managers and executives when necessary.
    
    
• Organize, test, and write out in as detailed a manner as possible the entire move. Create a comprehensive migration document, which includes:
  
  
  • A schedule of the move for all components
  • Detailed procedures to be followed for each part of the move
    
    

A comprehensive migration document will be most effective if it is the result of weeks of conversation and communication among the IT staff. Therefore, you need to begin your migration project long before the move date.

Planning: Seizing Opportunities, Determining Budgets, and Assessing Downtime

As you plan for the move, realize there are both opportunities for improving site equipment as well as complex decisions that will affect how much money you spend and how long your site will be down as you migrate.

• Take advantage of the move to strengthen your site. Typically, a move is a good time to upgrade your hardware.
• Determine what duplicating hardware you can afford and what amount of downtime you can live with. The more equipment you can buy for the new site to duplicate what you have at the old site, the more you'll be able to minimize downtime. For example, additional routers, load balancers, and database machines may be too expensive to buy, but if you don't have them, your site will be down longer for user-generated requests.
• Maintain realistic expectations. Even with the best of planning, expect some stale content, the amount of which will depend on whether your site has mostly static or user-generated content. If your move is across town and you aren't buying all new equipment, you'll have a lot less downtime for user-generated requests than if you're moving cross-country, in which case downtime increases significantly.
• Assemble personnel. During the most difficult parts of the move, such as the migration of the database and applications, be sure to have all the Web site administrators on call to troubleshoot problems.

Migrating Content: Methods of Moving, Practice, and Testing

Migrating content to the new site is an exercise in repetition. Determine how you will move it; practice doing it; and test the result until you're ready for moving the most up-to-date content at the time of the actual migration.

Methods of Moving

• Static content on small sites - You're likely to archive it using tar, use FTP to move it, and then extract it using tar. If the site is relatively big, you're likely to use tape backup.
• Databases - Although taping is the more likely means for migrating, you may well follow the same procedure as the one for small sites.
• Applications running on the site - This group includes both files and configurations. You'll need to determine how you're physically going to move these applications -- whether by using tar or tape.

Practice and Test the Move
For each kind of content, practice the move well in advance until you're sure you have a successful procedure for migrating all content. You'll also want to test the results on machines at the new site to ensure content has been moved successfully. (At this point, those new machines should be in place.)

Moving and Setting Up Equipment at the New Site

As you get close to moving, install any new equipment you've purchased and cannibalize any redundant equipment from the old site. For example, a spare router at the old site becomes the primary router at the new site; the old site runs without redundancy during the time of the move.

Establishing QA: Testing the New Site in Advance

In advance of the move, create a clear QA process, a defined set of testing procedures to ensure the new site will function well once live and public. Those tests should include:

• Static content - Provide a link checker to ensure there are no broken links.
• Applications - Have someone test to ensure the applications function fully and well. Those tests should include what you input and what results you receive from the database.

During the test phase of the new site, the server should be live -- not only up and running but connected to the Web so that testing is as realistic as possible. You access the new site by using the new server's IP address or setting up a temporary host name. Since there are no users or clients for the new site, its security is effectively maintained by its secrecy.

In Advance: Changing the TTL

At least one week before the move, adjust the DNS server so that the DNS time to live (TTL) is one hour. Changing the TTL reduces the amount of time that DNS servers around the world cache the IP address for the host name of your site. As a result, when you change the IP address for the new site, the new IP address will more quickly propagate around the world than if the TTL were longer.

Timing

Try to move the site during its least active time -- when there is no new content being posted to the site and there are few visitors. That time is likely to be a weekend or 1:00 a.m. on a weekday.

The Move Itself: A Clear, Well-Scheduled Transition

While repetition is essential in preparation for the move, order is necessary during the actual migration. The following subjects identify what needs to be done and what sequence of actions should be followed.

Freezing Content and Alerting Users

• Call a freeze to any static content changes to the site. Use tar or tape for the content, and move it to the new site.
• In response to user-generated content requests at both the old and the new sites, set up a page that alerts all users the site is down for maintenance. The down-for-maintenance page should specify how long before your site will be back online. Typically, you provide this content by setting up another Web server with a different host name, such as errors.mywebsite.com, and locating that Web server on an existing piece of working hardware, either at the new or old location.

Shutting Down Applications
Next, all applications should be shut down and all requests for those applications should be redirected to the down-for-maintenance page.

Redirecting Static Content Requests
Once these last actions are performed, static content requests can be redirected to the new site using the temporary host name or IP address. Effectively, then, the old Web site is still up and running, but everyone is being shifted to the new Web site.

DNS Change
At this point, you can make the DNS change. Go into your DNS record and change the IP address of your Web site to the new IP address, which propagates immediately around the world.

That action does not mean that DNS changes are instantaneous. Because some of the DNS servers around the world will have the old IP address, some users will receive the down-for-maintenance page when they make their requests for your site. Even when you set the TTL to one hour, it typically takes a few days for the new, correct IP address to be present in all the DNS servers across the world. Nonetheless, your users are at this point being redirected to your new site, and the new IP address is being propagated.

Moving the Database
After the static content is live and working at the new site, you may move the database either by FTP or, if it is too large, by taping it over to the site. Once the database, the applications, and the data are up and running at the new site, you can turn off the down-for-maintenance page.

(Note: The down-for-maintenance page may well be handy in the future for when you upgrade or, should it arise, move again.)

Final Details
Now the new site is up and running, and the DNS changes are taking effect. Within a day or so, most users are getting to the new site. Keep the old site up for a few days to a week, and examine the log files at the old site until it is clear there is no traffic on it. Then all the old site equipment can be brought to the new location and used for redundancy.