Moving Webhosting Service

A Guide to Moving Web Hosting Services

Wordskills.com moved web hosts in May 2000.

Nobody noticed the change.

This is how we did it.

Introduction

This document is an edited version of the checklist we used when we moved our hosting service earlier this year to webwizards. If you document the planned transition from your old to new server in a checklist form like this document then

you will have far more confidence in what you're doing,
you will have anticipated potential problems and resolved them before your site visitors encounter them
you will make the transition that much more transparent to your site visitors on and after changeover day

This checklist assumes that you have an operational site hosted by Company X and intend to move the entire site to be hosted by Company Y. It covers some of the technical issues that you'll need to address. Some assumptions :

Unix to Unix transition is implied
CGI/Perl is used
You keep an up-to-date mirror of your current site on your local hard disk (eg using Dreamweaver)

Our own checklist was considerably more detailed than this as it referred to specific directories, files and content that we wanted to ensure survived the transition intact. What follows is more of a generic checklist that you may adapt for your own use.

First, start with a detailed 'to do' checklist for each stage

Stage 1 Preparation of new site before public release
Stage 2 Implementation, Monitor and follow up

At all key stages it is important to

make backups
document what you plan to do, and what you've done
test your changes

This might make the pre-implementation stage take longer, but adequate preparation means less nail-biting on changeover day and fewer problems during the post-implementation period.

Stage 1 Preparation of new site before public release

You'll want to work behind the scenes setting up the new site before anyone visits it. One way is to set up the domain name using only the new IP address. The domain name will point to the old (current) server. Once the new site is ready for release the domain name is transferred to point to the new DNS servers, and the new server goes live.

Meanwhile

Document everything
keep robots out of the new site with a version of a robots.txt file that denies all
Use dummy index.html files (chmod 700 if necessary) to prevent display and access of directory contents to accidental visitors
Freeze any new developments you're working on
Back up your hard disk site version to zip disk or CD
Produce a directory by directory listing of your old site - ( Fetch FTP transcripts will show directory and file permissions) - You'll need these later

Confirm with the new hosting service any differences in structure of the new site or the methods by which the new site handles web and e-mail based events. For example, on our old server we could pipe email content directly to a perl script, with the new server we had to set up a subsystem to pipe incoming POP mail under crontab. So take the time to figure out if any of the following need to change:

Does e-mail work differently (POP and SMTP)?
Will you need to make changes to the way your autoresponders work?
CGI scripts will need changing
- the CGI directory name may be different (eg cgibin became cgi-bin)
- the path to files and directories will almost certainly need to be changed (even if your URL remains the same)

SYSTEM

install .htaccess to handle error redirection (eg error 40x, 500 etc )
install your robots.txt file that denies access to all spiders temporarily
install crontabfile if you use it, checking paths and permissions
if you use HTACCESS to restrict access to certain directories install .htaccess files in these directories (You may need to change these if the path specified by AuthUserFile has to change)

DIRECTORIES AND FILES

Create required directories and set permissions in your webspace
In html that uses SSI make any path changes as necessary (named as shtml if your server conventions require it)
Upload html and any shtml files to webspace directories, creating these as necessary
Refer to the FTP transcripts and check permissions on all files you upload
Set permissions on shtml to 755

Do a search on html forms. The text editor BBEdit handles this nicely with its grep features. For example, the following finds all occurrences of a FORM whose action is handled by something within the wordskills domain

<form.*action.*wordskills.*

will search for html documents containing a FORM beginning <Form followed by one or more characters, followed by the string 'action', one or more characters followed by 'wordskills' and one or more characters (case insensitive selected). You can then change the action path as necessary.

CGI

You have checked that the new hosting service provides CGI/Perl and perl modules that you use (eg CGI.pm), haven't you?

Identify new path for files in cgi-bin. For each cgi script

change from /old/path/to/domain to /new/path/to/domain
change paths to perl if necessary (eg #! /usr/bin/perl)

If your new site is identified by its IP address and the domain name still points to the old site then any cgi scripts that use the domain name will use the script on the old server. To test the scripts running on the new server you'll need to temporarily change domain name to the dotted quad IP address of the new server

Upload to your new CGI directory, setting permissions to 755 as required

Test each from the command line (Telnet) - This is the first line of defence to check that they work, that all the files they need exist and have the correct permissions. Then test each from your browser

LOGS

If necessary, check what you need to do with your server logs if

the location of the server logs is different
the format of the logs is different

UPDATED FILES

On changeover day you will need to download from the old site and then upload to the new site files whose contents change through user action. Test this before changeover day. Remember to set their file permissions where required.

JUST BEFORE CHANGEOVER DAY

Replace your dummy index.html with the live version of index.html in the new site. Visitors will start to be directed towards the new site once the new DNS naming is implemented

Run a check on internal and external site links (eg with Netmechanic, Webtester) and correct any missing or incorrect links (there will almost certainly be some that you forgot)

Test everything thoroughly before changeover day, including all autoresponders and e-mail forwarding. The last thing you want is the new site falling over because there are things you forgot to install, or permissions you didn't set properly

STAGE 2 Implementation

On changeover day download from the old site and upload to the new site files whose contents change through user action (Makes sure the content is up-to-date).

Monitor the server logs for unusual behaviour. The grep feature of BBEdit allows you to look for server errors. For example

" 4..|" 500

looks for the following strings in a server log

a quotation mark, followed by a space, followed by EITHER a server error that begins with a 4 followed by any 2 characters OR a server 500 error

(Caveat! The format of your server logs may be different)

BBEdit grep could alert you to visitors attempting to access protected directories (eg you forgot to protect a directory with .htaccess)

GET /dir1|GET /dir2|GET /dir3

will highlight in the server log any visitor accessing dir1, dir 2 or dir3 if you'd rather not have visitors browsing through them

When you are happy with the transition you can then upload a version of the robots.txt file that allows spiders etc to roam your new site as required

List your directories, files and their permissions on the new server. Retain these as a snapshot of the state of the new server for reference purposes in any post-implementation problem resolution.

THE OLD SERVER

After implementation you'll want to give notice to your old hosting service to discontinue their service.

In the meantime periodically check the old server logs. You probably find that there are still users or robots that are using the IP address of your old server and not the domain name. If so, identify the pages they are accessing and replace on the old server with a page that redirects to the new server (using the IP address of the new server).

Wordskills.com | Main Page | Our Affiliate Program

Web Hosting Services

Some of the most famous names on the Internet use Web Wizards - the same web hosting service we moved to. It provides a reliable service 24 hours a day, 7 days a week. Read what others have said about Web Wizards. If you are thinking about a new web hosting service, or moving hosts then look no further than Web Wizards (They also have a 2 Tier Affiliate program that pays 15% at BOTH levels!)

Wordskills.com - in education and training

David Paul. (c) November 2000

You may freely link to this page but you may not reproduce the content without permission.

Caveat. We were commissioned to write a version of this article for publication in Webworks. Webworks went bankrupt after the article was published and we were never paid. If you are approached by Webworks and are invited, for a fee, to write an article for them please check that you will be paid before you enter into any contractual arrangement with them.