Web Hosting Talk







View Full Version : Need help with checklist for moving big customer from one host to another.


electric
10-25-2001, 09:43 PM
Hi everyone, I'm planning to move a major customer to a different hosting provider.. and I was wondering if you could look over my plan of attack to make it happen as smoothly as possible. :confused:

As you read this, here are some specific things I need help with:

1. For step 5, do you think I should send only one note to the company admin person and let him distribute.. or is it appropriate to send an email to each employee directly?
2. Does anyone have a sample email they've used for something similar? (Hasn't *anyone* here moved from one host to another?!)
3. For step 7, is there some way to find out within 1 minute that the new account is active? (Like an automated process that will ring a bell on my computer when it is working, etc..?)
4. Am I forgetting anything? The last thing I want is for some employee to call me up and tell me that they've lost all their email or something!! :eek2:

----------- BEGIN PLAN OF ATTACK ------------------

Wednesday morning (2 days before move date..)

(1.) Copy all website files (databases, HTML, etc..) to new host.
(2.) Make note of protected directories, etc... - recreate on new host
(3.) Check out website files - confirm they are working on new host. (scripts, db, etc..)
(4.) Make note of all email account names - recreate accounts on new host (I must create new passwords since I don't know their old ones.)
(5.) Send "Your email account info will change soon..." note to customer. A note will go to each email account (every employee - there are 75 of them) and will contain their new email username/password and setup info. (Every employee must reconfigure their email client, since their new email accounts will use a different naming mechanism. The new host uses "jimbob@company.com" instead of just "jimbob".

The email will also let them know that the change will occur sometime after Friday at 3:00pm and that they will know about it when the "incorrect username/password" error pops up when they check their email. (At which point they should plug in the new username/password..)

Friday @ 3:00pm (In anticipation that 1/2 of the employees will not work on weekend...)

(6.) Change DNS entry to point to new nameservers.
(7.) Create test HTML page on new host. When this page is reachable, the domain has propagated.

Immediately after domain has sucessfully propagated:

(8.) Copy email files for each account from old host to account on new host. (Hopefully I can do this before an employee plugs in their new info and realizes their email is not there yet!)

After it's all over:

(9.) Send "Everything went as planned.." email to customer. (Also, remind employees to change passwords, info on how to use new webmail program, etc..)
(10.) Remove test HTML page, and then cancel account with the old host.

----------- END PLAN OF ATTACK ------------------

Thanks everyone for your thoughts! I don't know if it makes a difference, but the old account has a static IP address and the new one does not. (It is a name based virtual account..) :(

Cheers!

haji
10-25-2001, 10:07 PM
Hi,

If you have scripts (perl,php) running, then make sure the paths on your old host and new host are the same. Then you can create tar files and transfer. To find out how to do this, refer to the thread I started in the "technical issues" forum.

choon
10-25-2001, 10:32 PM
Hello electric,

Are you from SitePoint ;)

BTW, good luck with your move :D

Regards,
Choon

manuchao
10-26-2001, 07:15 AM
Be careful with the IPs that could be hardcoded inside scripts. Make notice of the Perl binary location and also the /home/client changes that may need to be done in PHP/Perl scripts.

Make sure that .htpasswd files point to the correct path. Also, check on the OS version, Perl version etc for possible incompatibilities.

If you have to transfer binaries as well (for example Matt's counter.cgi that works with a graphics binary) make sure they can run there (no library incompatibilities).

If your customer by his own maintains his server then you have to be extra careful of things he may have done (compiled C scripts with hardcoded paths or depended libraries).

If you have access to httpd.conf (Apache) then do a permanent redirect to the old server after you are sure that the new server (under a temp canonical domain) is up and running fine.

Nick

manuchao
10-26-2001, 07:20 AM
Also remember that your client's ISP's nameserver may not take the DNS update immediately.

In this case you may have a problem with mail being delivered to the old SMTP server or your client's employees POPing to the wrong POP server.

This could be tricky. Nameservers can take 5 to 7 days, or perhaps even more to update due to DNS zone caching.

Nick