This part should be easy. A good web hosting company will have account manager online most of the day to help you decide if a shared hosting, dedicated server, cloud, or VPS is best for you.

You have backed up your web site from your other web host but do not tell them that you are moving (read below for reasons why). You will want to maintain your old site until you are sure the new site works fine.

Once you have received confirmation from our New Account Setup department that your account has been set up, you can log in to your account to upload your web site onto your Superb server.

To log in to your account to upload your files, you need to have FTP (File Transfer Protocol) software on your local computer. For more on using FTP, refer to the documentation found under Support.
FTP Usage – UNIX
FTP Usage – Windows 2000/NT
FTP Usage – SPS
Once you have uploaded your website test all links, etc. exhaustively before going to Step 4:

Please note that if your links are absolute, (i.e. include your domain name), they will go back to your old site; you should make your links relative, (i.e. link to pagename.html instead of http://www.yourdomain.tld/pagename.html, or manually type in your IP with us prefix when testing the links to ensure the page is found.

Please note that you have 2 options available at this point:

1. Select your new hosting company as your new Domain Name Registrar
2. Stay with your current registrar and change the DNS records of your domain

It is recommended that you first change your Domain Name registration over to Superb.

However, even if you are doing so, you will still need to change your domain’s name servers to ours when your site is ready to go live with us, since registrar move process may take up to a month (while DNS name server change is instant at most registrars).

To change your DNS, you will need to go to your domain name registrar (i.e. Register.com, Network Solutions, etc.) to have your Domain redirected from the current nameservers. Usually you do this by accessing the Domain Manager on Register.com or the Domain Administrator on Network Solutions, or similarly on your registrar. If you do not know your registrar’s name, then do a Whois to determine this.

You will need to provide the following names servers for Superb:

NS1.SUPERB.NET
NS2.SUPERB.NET

NS3.SUPERB.NET
NS4.SUPERB.NET

NS5.SUPERB.NET
NS6.SUPERB.NET

During the transition it is advisable that you duplicate your web site identically over to Superb. It is advisable that any changes or updates to your website wait until after you make the move over and your site is running smoothly.

1. Worry about the little things – no detail is too small.

If done properly, switching Web hosts does not need to be a traumatic experience. The first step is preparing a detailed changeover plan or checklist. By following a checklist, you’ll feel more confident about what you’re doing and you’ll anticipate problems and fix them before Web site visitors encounter them. Moreover, you’ll make a smooth transition for your visitors on and after moving day.

Before preparing the checklist, you will want to decide if you want to stick with the same operating system. For example, at the old host you may have used UNIX. A move to Windows NT may require more work.

If your move involves a change in operating system, such as UNIX to Windows NT, or a change in file or database management, additional steps in the checklist will be needed. (More on this later)

2. Make a to-do list- a good plan helps to ensure nothing is forgotten.

The checklist covers preparation of the new site before public release and implementation, monitoring and follow-up.
All the way along, it is important to:

Good planning will help alleviate a lot of headaches on moving day and will help to prevent problems during and after the move onto your new Superb server.
3. Copy your web site files – even if you think you have a backup

Remember, “be sure to back up a copy of your complete web site.” Unbelievably there continue to be a large percentage of web site owners/managers who actually only maintain only one copy of their website – the one on their web host’s server.

Should you be one, then it is very important for you to make a copy of your website before you start. Absolutely back up your web site onto your computer before letting your web host know that you are moving. In fact, until you have moved you may not want to tell your current web host.

Sure it might cost you an additional month but some disreputable web hosting companies may take it badly when you notify them (unlike here at Superb). They might terminate your account before you’re ready, throttle down your bandwidth or other such petty things. If you don’t believe that such things happen, just browse the various Webmaster newsgroups and you’ll see that even worse things can occur.

To copy your files, just reverse the method that you normally take to upload your files, and download them instead. If you do it through FTP, then copy them through FTP. If you use a browser to access your site via your web hosts’ online “File Manager” (or the like), then do it that way.

4. Check your internal links

The next step is to check all your internal links to make sure they do not have any hard coded URLs to the old address. This is not a problem if you have your own domain (since your URL will not change in that case).

You might want to consider making all your internal links relative links (i.e. to simplify your relocation process. You can always hardcode links again later if that’s what you prefer. Note that your old site is still active. At this point, no one knows you’re going to shift yet (except of course you and your new host).

Upload your pages to your new host. Test all your pages. Make sure they work. Remember – you have not yet officially shifted. If you have your own domain name, you have also not yet updated your DNS to point to your new host. The whole point of this exercise is to make sure everything is functional on both ends.

5. Be prepared- preparation is everything

Begin site construction on your new Superb server by uploading pages and creating directories and files, using only the new IP address. Because the domain name is not associated with the IP address on the new server, you can expect only a few stray visitors to the new site while under construction.

Only when the new site is fully built and ready for release, should you point the domain name to the DNS at the new Web host. At that point, all visitors should be directed to the site on the new server.

Additionally this will prevent the search engine spiders from indexing and cataloging the site before it’s ready.

6. Updating your DNS records – Domain Name Holders

For those customers who have their own domain name and are moving it along with their web site, you will need to update your DNS records with your registrar but only when you’re satisfied that your new site works as intended.

If you have just registered a new domain name (and you did not have one previously), simply point the domain name to the new host. Do NOT point the domain to your old host first for any reason. This will cause additional complications that you’re in a position to avoid.

Although the registrars tell you that the update should be completed within 48 hours or so, in practice it actually takes about a week for all the name servers around the world to catch up with the new location of your domain. In that interim, only some parts of the world will be able access your domain at your new host; the rest will continue to access the old site. Note that even if you see the new site in your browser, it is not necessarily true that others will see the new site. This is normal – do not worry.

7. Things to keep in mind

Do not delete the old site during this interim. This will help you avoid losing visitors. Just maintain two copies of your site. Endure the inconvenience for this period – it’s only a short-term hassle.

Do not put up a page on your old site-redirecting people to your new domain. It may seem like a good idea, but it isn’t. Only if you have a name based web hosting accounting or dynamic content is this necessary

Do not tell your old host just yet. Give it at least one week where both sites continue to run concurrently. This applies even if you’re paying both hosts monthly fees (sure you will save a bit of money but wouldn’t you prefer your customers always find your web site). Plan to have both sites up for at least that week.

Temporarily freeze new developments or programming features you’re working on that might interfere with the transition. You’ll want to make sure you’re working with the same versions of forms, pages and programs on the both servers.

Back up a mirror version of the old site on your PC’s local hard disk, a zip disk or a CD.

Produce a directory-by-directory listing of your old site; FTP transcripts, from your FTP program or server directory listings, will show directory and file permissions you’ll need to replicate later.

Confirm with the new Web host any differences in structure of the new site or the methods by which the new site handles Web and e-mail based events, including the following:

8. Making the move – depends on whether or not you had a domain before.

Had a domain with your old web host:

If you had your own domain name previously, then when you upload your web site over to Superb using FTP, there will be little else to do. You can simply terminate your account with your old web host, and you’re done (or if you can afford it, wait a week or so longer to make sure every ISP’s DNS records has been updated).

Your visitors will probably not even know that you changed hosts. Your search engine listings are not affected since they still point to the right place: your domain. If you followed the instructions above, everything should be running smoothly.

Did not previously have a domain (must change URLs)

If you have been hosting with free web hosts or your old ISP without your own domain name previously, you’re now faced with the prospect of losing visitors. Visitors will be lost because they follow old links to your site (whether from search engines or other sites) and will not find it there. Some loss of visitors is actually unavoidable, but you can do much to reduce the number lost.

The most obvious thing to do is to put a page on your old site redirecting your visitors to your new location. For the inexperienced, there are basically two ways to write web pages that redirect your visitors

But, as we know here, there are problems with this approach. The problem with the first variety is that most people don’t bother to follow links. If they do not see what they want instantly, they’ll just hit the back button and proceed elsewhere. This is a well-documented characteristic of Internet users.

The problem with the second variety is that you will lose your search engine listing. Search engines generally do not like redirection pages. If they see a redirection page when their spider is returning to check out your site, your old URL will be deleted from their index. You don’t want your old URL deleted from their index if possible because your new URL is still new – it takes time before your new URL is listed in the search engines (sometimes it can take a month) even if you immediately index it when your site becomes live.

The Solution

The best solution would be to modify your old site’s .htaccess file. Some web hosts allow you to put a .htaccess file in your web directories telling your web server what to do when a visitor tries to access a file on your site. Check your old web host’s documentation to see if this can be done. In general, only web hosts that use the Apache server will have such a facility.

Using .htaccess can redirect visitors browsing your site to customized pages informing them that the requested page does not exist, access is forbidden or a server error has been encountered. The simplest way is to delete all the files in your old server and put a line like the following in your .htaccess file:

ErrorDocument 404 http://www.yourname.tld/

This line directs the web server to send your visitors to your new site’s main page every time they try to access a document that does not exist on your site (which will be all the time, since you’ve deleted everything).

Alternatively, if you prefer to redirect them to different parts of your new site according to which page they try to access, you might want to use lines like the following:

Redirect /oldfilename.html http://www.yourname.tld/file.html

Every time a visitor tries to access oldfilename.html on your old site, the server will tell the browser to load file.html from your new site instead. Your visitors will then be transparently redirected to the new host without the requirement that they click on a link, etc. If they do not look at the location bar on their browser, they might not even know that they had been redirected.

At the same time, when a search engine is given the above lines, the more intelligent spiders will update their index to contain the new URL. You can’t win them all though – it is thought that not all spiders do this automatically. So again, there’ll be some losses: you can only reduce them.

Using .htaccess can redirect visitors browsing your site to customized pages informing them that the requested page does not exist, access is forbidden or a server error has been encountered.

Build error pages to which visitors will be directed if the server does not successfully retrieve a page. The pages should indicate the reason for the errors, which are typically Error 404 (file not found), Error 403 (restricted access), and Error 500 (server error).

Set up an .htaccess file to handle redirection to these error pages. For example, a file containing the following code will redirect a visitor to err500.html in the /errors directory if a server error is encountered.

ErrorDocument 404 /errors/notfound.html
ErrorDocument 500 /errors/err500.html
ErrorDocument 403 /errors/restricted.html

Set up your crontab file. If you have the server perform regularly scheduled tasks, set up a crontab file on the new server, checking new paths and permissions. This can be installed after implementation.

Can not use .htaccess

If you don’t have access to .htaccess on your old site, probably the next best thing to do is to simply use a page that automatically redirects your visitor to the new location. You can do this by putting a special META tag in the HEAD section of your web page (keep it in one line on your real page):

meta http-equiv=”refresh” content=”0; URL=http://www.yourname.tld/file.html”

The “0” in the line specifies that the browser should wait 0 seconds before redirecting. If you want to display some sort of message, you can always change that to (say) 5 to tell the browser to wait 5 seconds. The content attribute would then read:

content=”5; URL=http://www.yourname.tld/file.html”

Even if you wait “0” seconds, you should still include some sort of short message in the body of your web page together with a clickable link to the correct page on your new site. This is because some old browsers might not support the META refresh tag that is used here. A visible, clickable link will give your visitors an alternative way to get to your actual page.

Note that “0” and the new URL are part of the same string that is assigned to the “content” attribute. The opening quotation marks is before the time (“0” in our case) and the closing.

9. Set up your directories and files- organization is the key to success

10. Granting permissions

Upload HTML documents and any include files to the new server. Refer to our FTP documentation to ensure that this process is done correctly. Check permissions to see if they are accurately set on all files you upload. Remember to set permissions on SSI files named with the .html or. shtml extension to be executable by all users. The UNIX command for doing this is chmod 755.

Do a search on HTML forms you use to make sure the action paths are correct for the new site. Simple text editors with search-and-replace features can accomplish this. The CGI directory will contain all the programs and configuration files transferred from the old server. Identify the new path for files in the CGI directory. For each CGI script, change the old path to reflect the path on the new server.

Change paths to Perl scripts if necessary.

For example: #! /usr/bin/perl

During the period when the new site is identified only by its IP address, any CGI scripts using the domain name must use the script on the old server because the domain name still points to the old site. To test how the scripts will run on the new Superb server, you’ll need to temporarily change the domain name in the script to the numerical IP address of the new server.

Upload the scripts to your new CGI directory, setting permissions to allow users to execute the scripts.

11. Test exhaustively for errors

Test the scripts from the Telnet command line. Running the scripts from Telnet will help identify the source of any error with the script. If you just test the scripts from your browser, any errors they contain will most likely lead to a server error without indicating the nature of the error. Scripts that run fine from the command line can then be tested with your browser.

Learn how to read and interpret your server logs. They provide invaluable information about how your server is functioning, who is visiting your site and whether they are accessing directories to which you’d rather deny access.

If you have a suite of programs that process the server log, check what you need to do differently if the location and/or format of the server logs have changed. Wait until moving day to transfer files containing content that changes through user action. But do a test run before moving day to make sure the files users update can be updated on the new server. Correct file permissions where required.

12. Carefully take care of the last-minute details

Here are a few final steps to take the day before making the move.

13. Carefully monitor the implementation process – including follow-up

Monitor server logs regularly for unusual activity. Use a simple search with a text editor, or a more sophisticated grep search. When you’re happy with the transition, upload a version of the robots.txt file that allows robots to roam your new site as required.

Print a hard copy listing of your directories, files and their permissions on your new Superb server. Keep these as a snapshot of the state of the new server for reference. You might need to compare them with corresponding listings from the old server in any post-implementation troubleshooting.

After the move, notify your old Web host you’re discontinuing service. The notice period will depend on your contract with the old hosting service.

14. Carefully monitor the implementation process – including follow-up

If your web server (old and new) has logs, or if you have a statistics counter that tracks referrals to your website, make a list of all the sites that sent visitors to your site. Visit those sites and see if they are still referring to your old URL. If so, you might want to inform the Webmaster of that site of your new URL.

If your old URL is listed in any directories, you should also take the trouble to update them. Likewise, you will want to quickly submit your new URL to the search engines. Note that some search engines take forever to list a new site, so you just have to be patient.

You can also search for links pointing to your old URL by entering either that old URL or the name of your website into the search engine and look at what turns up.

How much time do you have to update the links? It really depends. Theoretically you have as much time as you want, as long as you continue to maintain your old hosting account where you can set up redirections to your new URL. In practice however, web hosts (especially the smaller ones) sometimes notice that an account has gone dormant and will remove it. Redirection pages also tend to lose some people along the way (not everyone follows the redirection).

Our experience is that it is very difficult to exhaustively remove all links pointing to your old URL. Some webmasters can’t be bothered (particularly the webmasters of sites that have not been updated for years); some cannot be traced (no email address on the site) or you fail to notice the odd site or so that rarely sends you traffic.

15. Make random checks periodically later on

In the meantime, periodically check the old server logs. You’ll probably find a small number of users or robots are still using the IP address of your old server and not your domain name. Identify the pages they’re accessing and replace them with a page that redirects traffic to the new server.

While you may experience a few problems that have not been outlined here, you will find that a detailed checklist will pay off. At any time that you feel you do not understand or are uncertain about any element of the move, please feel free to contact our Web Hosting Moving professionals.

Follow Rich Norwoodon

by Richard Norwood