David Gillaspey
Mon., Jan. 8, 2007, 12:19 am
Hi everyone,
Last week I switched web hosters, as you know. In this post, I want to report my observations about this, for the benefit of others.
First, for the sake of a member who ask me offline how I went about choosing a new hoster, I'm going to start by explaining that. The member was OK with my answering the question through the forum.
I suppose one should spend a huge amount of time researching different web hosters before making a decision about a new web hoster. Well, I don't have that kind of time. And, as you'll see, I'm not entirely sure that large amounts of time spent researching hosters would have accomplished anything in my situation.
I decided to switch hosters because my old hoster couldn't resolve a recurring problem with there being too many connections to the mySQL server, resulting in lost connections. People were being knocked off the forum, which relies on a backend mySQL database. Visitors couldn't access my website, which also relies on a backend database.
(Like many people, I have to use a (always cheaper) shared server hosting plan — then and now — so it wasn’t necessarily the number of visitors to Great Church Websites [gee, don't I wish!] that periodically overwhelmed the mySQL server and caused the lost connections.)
Also, I felt I was paying too much for the features of the hosting plan. For about $250 a year, I got:
* a few gigs of web storage
* three domains (two standard with the hosting plan, plus one additional domain that I paid for)
* three mySQL databases (though each could have an unlimited number of tables)
* one dedicated I.P. address for all the domains
(Some web hosting plans allow a customer to host more than one domain with a single account. One of these domains serves as the "master" domain of the account. I have several websites I maintain or want to develop, so having the ability to host multiple domains with one hosting account (and one ftp connection) is important to me. For church webmasters, it might be a matter of having separate websites for the youth ministry, singles ministry, etc.)
The $250 a year was for basic hosting, but also included a premium charge for one additional domain, for a total of three (the company's basic hosting plan allowed for only two domains), plus a premium charge for a dedicated I.P. address. (Why is the latter important? Search engines slightly favor sites with a dedicated I.P. address. If a website doesn't have a dedicated I.P. address, but shares an I.P. address with 100s of other sites on the same shared web server, then the site appears slightly less legit to the search engine.)
I needed:
Lots of storage, mySQL, PHP, static IP(s), multiple domain hosting (as explained above), and low price. Because I needed mySQL capability and PHP, I was generally restricted to Linux-based web hosting, which is widely available. The other main option is hosting on a Windows machine, which tends to be a little more expensive.
Cutting to the chase, I just chose a new web hoster from the following list of top-rated hosters that met these qualifications.
http://www.top-10-web-hosting.com
(There are at least two other lists of top-rated web hosters that I know of: http://bestwebhostingreviews.com and http://upperhost.com. Actually, there are many lists on the internet of "top-rated" web hosters, but the lists I've cited here are relatively ad-free, which reduces the chance of bias.)
This quickly narrowed down the list of potential new hosters, which saved me time.
As noted above, I had problems with my old web hoster not being able to keep the mySQL server functioning properly. Here's the catch: I have no way of knowing if any (potential new) hoster on a list of top-rated web hosters can do a better job. All web hosters promise 99.9% uptime, that is, they promise that their servers will be up and running 99.9% of time, and will refund some of your money if you can prove otherwise. But really, I'm just shooting in the dark, hoping my new hoster can do a better job keeping the mySQL server working.
Of course, I inquired about this matter with the new hoster's tech support staff before signing up, but all they can do is make promises. This is why I stated above that I'm not sure it would accomplish anything for me to have spent a lot of time carefully researching web hosters.
I chose for my new hoster a company called IX Web Hosting (http://www.ixwebhosting.com). For $99 a year (paid in advance), I get:
* up to 8 domains, each with their own dedicated I.P. address at no additional cost
* 300G storage
* up to 100 mySQL databases
and many other features that tend to be standard with all hosting accounts
You can see that I will save $150 a year in hosting costs with the new hoster (about $100 now vs. about $250 before), and get much more for my money compared with the old web hoster. The main reason I chose this hoster was because of the high number of domains I could host.
Observations about switching hosters
Now, I want to make some observations about the process of switching hosters. I call them observations, but they're really suggestions or advice for church webmasters preparing to switch hosters in the future.
1. I happened to have registered all my domain names with a dedicated domain registrar (GoDaddy, in my case; but there are many domain name registrars from which one could choose). I didn't rely on my old web hoster to register my domain name(s). If you relied upon your web hoster to register the domain for your church website (most web hosters offer this service), well first, you may have paid too much. (There can be quite a markup.) But more importantly, the hoster to a certain extent controls your domain name, since they would have listed themselves as the technical and administrative contacts for your domain name, when they registered your domain name on your behalf.
(Web hosters aren't domain registrars, in most cases, so typically your web hoster just registered your domain with a third party, a dedicated domain name registration company. You could have dealt directly with the registrar yourself and saved money. GoDaddy [http://www.godaddy.com], I might mention, is a large domain name registrar that also now provides extensive hosting services, so GoDaddy is one company that you could use to both register a domain name and provide web hosting.)
2. One of the final steps in the process of switching hosts is to re-point the DNS name server information for your domain to your new hoster's web server. I say it's one of the final steps, but I want to mention this upfront to provide important context. (Because the rest of this list is comprised of the things you want to do first.) There are a number of databases throughout the internet that tell browsers where to find files for, say, www.greatchurchwebsites.org — which server, out of all the thousands of servers around the world that are storing and hosting websites, contains the HTML and image files for www.greatchurchwebsites.org? That's what the Domain Name Server (or System) information is all about, in briefest terms.
When you sign up for a new web hoster (or any web hoster, if you're getting ready to launch a website for your church), you can expect to get several automated emails providing important information about your new hosting account. One of these emails should include the DNS information for your website on the new hosting server. You have to provide this information to your domain name registrar. (If your web hoster registered your domain name for you, then they will take care of this matter on your behalf.)
The DNS for my new hoster looks like this:
ns7.ixwebhosting.com
ns8.ixwebhosting.com
(There's always two lines.)
As stated, this information is typically provided to you in the automated emails that you received from a new web hoster immediately after you open your hosting account. That was not the case with my new web hoster, but I found the information easily enough in my new web hosting account "control panel."
Once you update the DNS information through your domain name registrar, it begins to propagate through all the DNS databases on the internet. This process takes 24 to 48 hours to complete. (It's important to be aware of this; it can be quite vexing to a webmaster.) During that time, people visiting your church website may see files on the old web server, or files on the new web server. Unless you slightly change, say, the home page on the new server, it will be difficult to know which server you are seeing when you visit your own home page. (But more about this below.) Absolute links to other pages on your site may pull from the old server or from the new server, during this 24 to 48 hour period. (So there is some advantage in this situation to using only relative links throughout your site.)
(Those automated emails you get from your new hoster upon signing up will include a special URL to allow you to upload files to, and view pages on, your new web hoster's server during this 24 to 48 hour period.)
OTHER STEPS TO TAKE
Before you change the DNS server information for your website, which is the final step and which starts the clock ticking, you'll want to ensure other important things get done:
3. Remember to download your website log files from your old web hosting server, via ftp, before canceling your old web hosting service. In the course of my doing this, I discovered that I had failed to turn on the option to archive raw log files, a feature accessible through my old hosting account's control panel. (You might want to check to ensure that your current hosting account is configured to archive raw log files.) Thus I could only download raw log files for December 2006, that is, just the previous month. Oops.
However, what I really wanted was the Webalizer files for my site, for as far back in time as possible. Webalizer is a web statistics program commonly offered by web hosting companies for free that interprets the raw log files and displays your website visitor statistics in graphical form. The good news is that I was able to download, from my old hoster's web server, the Webalizer files for Great Church Websites going as far back as I've been with my old hoster. (Since starting Great Church Websites a few years ago, I've used about five web hosters.) Webalizer files consist of some HTML files and many, many imbedded graphics (.png format), which are charts or graphs that show your website statistics for a day or month in graphical form. That was the information I was really after. As stated, I was able to find and download these files for safe storage on my home computer.
4. My old web hoster had a feature to allow me to block I.P. addresses. This was configured via the web hosting account control panel. I used this to stop spammers who spam this forum from ever returning to my website again (in theory). I downloaded the list of blocked I.P. addresses before canceling my old web hosting account.
I was promised by tech support for the new web hoster that I could, with my new account, similarly block I.P. addresses. But, as of the time of this writing, I haven't found where to configure this in my new hosting account control panel. That's OK; it's not the end of the world. The forum software that I use for this forum (vBulletin) has its own I.P. banning feature. By contrast, I would have greatly regretted losing my website statistics files.
5. Do you use a mySQL database on your church website? Watch for the mySQL server address or path changing when you switch hosters. For many web hosters, the address or path of the mySQL server (which is used in configuring connections to a database) is simply "localhost." (Strange phrase, but that's what it is.)
This works well because webmasters who set up a web server on their home or office computer for testing purposes typically also use "localhost" as the address or path for the test mySQL server on their computer. Copy your files from local testing server to your (commercial) web hoster's web server, and your connections to the mySQL database work without a hitch. Or, copy your files from one web hoster that uses "localhost" as the address or path to the mySQL server to another web hoster that does the same, and your mySQL connections will also work without a hitch. (Almost. There's another "gotcha" that I will mention below.) Well, on my old web hoster's server, the address or path to the mySQL server was indeed "localhost." On my new web hoster's server, the mySQL server address or path is "mysql20.ixwebhosting.com." That meant I had to make some changes in certain key files.
(As with DNS information, the address or path to the mySQL server for a new web hosting account is typically provided for you in emails sent out from a web hoster when you open an account. But here again, my new web hoster fell a bit short in this regard and didn't provide this information via email. However, I found the information I needed easily enough in my web hosting account control panel.)
If you use Dreamweaver, and you use PHP and mySQL for your church website, the address or path to the mySQL server on your new web hoster's server (if different from the old) will need to be changed in a "connections" file in the "Connections" directory that Dreamweaver automatically created and uploaded for you.
By the way, have you secured that directory and its contents on your server? Each connections file within this directory contains a user name and password to access a mySQL database. You will want to make sure that that file can't be accessed by hackers.
For starters, make sure that anonymous ftp isn't enabled for your web hosting account. That was the case by default with my old web hoster. Only a few months ago did I discover this to be the case, and disabled anonymous ftp on my old web hosting account. With anonymous ftp enabled, it seems possible, and probable, that anyone could locate and download via ftp the connections file in the Connections directory of your website. (Again, I'm talking to Dreamweaver users here.) Hackers would thereby obtain the user name and password to your mySQL database, so as to hack into your database.
If you have installed a PHP-based proprietary or open-source web application on your church website, such as forum software, membership software, or a web Content Management System, and it relies on a backend mySQL database, then there will be configuration file (often called config.php or some such variation) in the application directory in the root directory of your website that similarly contains the address or path to the mySQL server. Check to ensure that it doesn't need to be updated with the address or path to the mySQL server on your new hoster's web server.
MORE STEPS TO TAKE
6. For those using mySQL databases: You'll have to re-create on the new web hoster's server the database(s) you had on your old web hoster's server. I'm only talking here for a moment about the database(s), not the tables they contain.
(You typically create and name mySQL database[s] via your hosting account control panel. Also, via the control panel, you separately create and configure users (user name/password combinations) for the databases. The actual tables in each database are created separately, later, through other means.)
Here's the other gotcha I alluded to above: in order to avoid have two customers with the same mySQL database name, web hosters tend to take the database name you submit (when creating a mySQL database using the appropriate options in your account control panel) and add a prefix to it based upon your account name. This guarantees unique names for all mySQL databases in a share server environment. Naturally I would want for my website a mySQL database named "greatchurchwebsites," for convenience sake. My old hoster added the prefix "gillaspe" (first eight characters of my last name) to this, so the actual name of the mySQL database ended up being "gillaspe_greatchurchwebsites." I had no choice in the matter.
My new web hoster adds a different prefix to my desired database name, so the same database with the same tables, on my new web hoster's server is called newprefix_greatchurchwebsites. (For security purposes, I won't give the actual prefix.) As you can see, that guarantees that Dreamweaver database connection files will be broken and need updating. It further guarantees that configuration files for your PHP+mySQL-based web applications will similarly need to be updated with the new name of your mySQL database(s).
7. If you already have one or more mySQL databases on your old web hoster's server, how will you get the data stored in them copied to your new web hoster's server? This is important because mySQL databases are not like other software programs. There are no "files" as such that you can find to download via ftp and upload again to your new web hoster's mySQL server.
Instead, you use phpMyAdmin (a free browser-based administrative interface to mySQL that is typically provided for you by web hosters) to export the data (table names plus the records stored in them) from a mySQL database as a text file. You then use phpMyAdmin to import the text file into an empty mySQL database that you've created in advance on your new web hoster's web server. The text file contains SQL statements that re-create the tables in your old database and repopulates them with the original data, included in the text file. You do this one database at a time.
I'm happy to say this worked fine for me. I was able to copy two mySQL databases from my old web hoster to my new web hoster's mySQL server in the manner described. One mySQL database contains tables for my database of well-designed church home pages as well as tables for my paid membership subscription software (aMember). (Yes, these tables ought to have been in separate mySQL databases, but with my old web hoster, I could only have a limited number of mySQL databases.) The other database contains 114 tables for this forum. A third database was for testing purposes and did not need to be copied over to the new hoster.
I regularly back up both the database for this forum and the aMember membership tables. Both programs offer backup operation as a standard feature, from their admin control panel. (The result of a backup operation is the same text file mentioned above.) So far I've not had to actually re-create a corrupted or hacked database. So I was relieved to know I could copy the databases successfully from old server to new server. I know now that I can successfully restore a corrupted or hacked database for this forum or for my paid membership software.
8. I've been talking about mySQL for a while. What about plain old HTML files and graphics? How do you actually get them from one server to another? I had planned to use the "mirror" function in my ftp program (Fetch, a popular Mac OS ftp program) to directly transfer files from my old web hoster's server to my new web hoster's server, via an ftp connection. If only it were so easy.
As I stated above, I have used a number of web hosters since launching Great Church Websites. I've not had a single hoster, then or now, whose ftp server could successfully upload or download an entire site (or even just many files) without timing out or hanging up. That was the case with both my old hoster and my new hoster. Thus my plan to "mirror" my site didn’t work. The ftp connection hung after a few minutes.
The problem with that is that it leaves you not quite sure which directory and files were successfully copied. Where did the program leave off when the ftp connection hung? So I always have to resort to deliberately selecting a handful of files and directories (out of all that need to be copied) and uploading or downloading just these. Then, I select another handful of files and directories and upload or download them. Etc.
In this way, I can carefully control the ftp process to ensure that all files for a website are eventually successfully uploaded or downloaded. If the ftp connection hangs while I am trying to upload or download a certain range of files and directories, then I only have to re-upload or re-download that range of files and directories again, not the entire site.
(If a particular directory itself contains many subfolders, then it may be necessary to upload or download a handful of the contained subfolders at a time, until all the subfolders in this directory have been successfully uploaded or downloaded.)
Alas, Fetch's mirror command didn't allow me to follow the above procedure. (It's copy all or nothing.) So, I ended up downloading to my local computer, in the manner described above, all the files on my website (except the mySQL databases). This gave me a backup of the whole site on my local computer, which is a good idea. Then I uploaded all these files, again in the manner described above, to the new web hoster's server. Some directories contained so many files or subfolders that I had to repeatedly download or upload them to achieve a successful transfer of all the selected files and directories.
This was very time-consuming. I would have preferred to be able to start Fetch's mirror operation and to have been able to walk away from the computer while the program copied all the files from my old hoster to the new hoster, without a hitch. Instead, I had to sit at my computer for something like three hours and laboriously transfer files and directories to my local computer and then to the new web hoster's server, in the manner described. I had to keep my eye on the status of the file transfer at all times.
9. Even when you have (seemingly) successfully copied files from your old web hoster's server to your new web hoster's server, you may find that web applications (e.g., forum software, e-commerce applications, etc.) may need to be reinstalled from the original installation files, in order to work properly.
First, the good news. This forum worked without a hitch on the new hoster's server, once I had copied the HTML and PHP files for the forum application from the old server to the new server and re-created the backend mySQL database. That was a relief!
Unfortunately, my membership software (for paid membership to my website) didn't work once copied over. There were several reasons for this:
a) The application includes several files containing code that is scrambled using a program called ionCube (http://www.ioncube.com). This required something called the ionCube Loader to be installed on my new web hoster's server to unscramble. I didn't realize that I needed to request, via a service ticket, that this be installed for me.
b) Probably it was these files, and possibly others, that are required to be uploaded (and downloaded) to a website in binary format. (The installation instructions actually call for all the files to be uploaded in binary format.) Fetch actually has no such option, so I use the "raw" file format instead. Based upon the error messages I was getting, I must have downloaded and/or uploaded some files incorrectly.
c) In customizing the application's HTML pages, I had made some bad choices in absolute URLs. Members were seeing pages from the old web hoster's server.
Anyway, to make a long story short, I ended up spending $40 and upgraded to the current version of aMember (my membership software). Once I had installed this latest version, the software worked fine. But for a period of about 24 hours, no one could log in to my website to browse my database of church home pages. As well, two visitors to my website wanted to join and were unable to do so. (Both were very gracious about the matter and have since joined.)
10. Count on your email not working for a day. (Ouch!) I mentioned DNS records above. This information takes 24 to 48 hours to propagate throughout the internet, once you have provided it to your domain registrar. But at least with websites, if you make a slight change in your home page, you can track whether the site is loading from the new web hoster's server or your old web hoster's server. No such luck when it comes to your email.
Where email gets sent (to which server) is controlled by "MX" records, which similarly have to propagate throughout the internet when you change hosters. (You don't, however, have to specifically request anyone or any company to transfer your MX records. It just happens, somehow, once the DNS records begin to change.) I don't know, but I would guess, that they don't propagate along with the DNS records, but rather, propagate independently. Unlike with websites (as mentioned above), it doesn't appear to me that there's any good way to track where or from which hoster your email is coming.
Anyway, for about one day, I could receive no email from either my old hoster or new hoster. (Remember, you have to set up email accounts to begin with, using the email options in your new web hosting account's control panel.) This was very frustrating. When I looked at my web mail account (that is, when I checked my email with a browser, as with Hotmail or Yahoo or MSN) on my old hoster, I saw no emails at all. (Not even spam!) I sent test messages to myself that I could see were delivered to my new hoster. I could see they were delivered, using web mail on my new hosting account, but Outlook Express would download no emails at all for about a day. There weren't even any error messages.
Eventually, I received all the emails that weren't showing up, so the good news is, your emails are only delayed for day or so, not truly lost. After a day of no email, the next morning, my email worked fine.
*****
Well, these are the lessons I learned from switching hosters. I hope this information will be helpful to others who are considering switching web hosters.
Sincerely,
David Gillaspey
President
Great Church Websites
& forum admin
Last week I switched web hosters, as you know. In this post, I want to report my observations about this, for the benefit of others.
First, for the sake of a member who ask me offline how I went about choosing a new hoster, I'm going to start by explaining that. The member was OK with my answering the question through the forum.
I suppose one should spend a huge amount of time researching different web hosters before making a decision about a new web hoster. Well, I don't have that kind of time. And, as you'll see, I'm not entirely sure that large amounts of time spent researching hosters would have accomplished anything in my situation.
I decided to switch hosters because my old hoster couldn't resolve a recurring problem with there being too many connections to the mySQL server, resulting in lost connections. People were being knocked off the forum, which relies on a backend mySQL database. Visitors couldn't access my website, which also relies on a backend database.
(Like many people, I have to use a (always cheaper) shared server hosting plan — then and now — so it wasn’t necessarily the number of visitors to Great Church Websites [gee, don't I wish!] that periodically overwhelmed the mySQL server and caused the lost connections.)
Also, I felt I was paying too much for the features of the hosting plan. For about $250 a year, I got:
* a few gigs of web storage
* three domains (two standard with the hosting plan, plus one additional domain that I paid for)
* three mySQL databases (though each could have an unlimited number of tables)
* one dedicated I.P. address for all the domains
(Some web hosting plans allow a customer to host more than one domain with a single account. One of these domains serves as the "master" domain of the account. I have several websites I maintain or want to develop, so having the ability to host multiple domains with one hosting account (and one ftp connection) is important to me. For church webmasters, it might be a matter of having separate websites for the youth ministry, singles ministry, etc.)
The $250 a year was for basic hosting, but also included a premium charge for one additional domain, for a total of three (the company's basic hosting plan allowed for only two domains), plus a premium charge for a dedicated I.P. address. (Why is the latter important? Search engines slightly favor sites with a dedicated I.P. address. If a website doesn't have a dedicated I.P. address, but shares an I.P. address with 100s of other sites on the same shared web server, then the site appears slightly less legit to the search engine.)
I needed:
Lots of storage, mySQL, PHP, static IP(s), multiple domain hosting (as explained above), and low price. Because I needed mySQL capability and PHP, I was generally restricted to Linux-based web hosting, which is widely available. The other main option is hosting on a Windows machine, which tends to be a little more expensive.
Cutting to the chase, I just chose a new web hoster from the following list of top-rated hosters that met these qualifications.
http://www.top-10-web-hosting.com
(There are at least two other lists of top-rated web hosters that I know of: http://bestwebhostingreviews.com and http://upperhost.com. Actually, there are many lists on the internet of "top-rated" web hosters, but the lists I've cited here are relatively ad-free, which reduces the chance of bias.)
This quickly narrowed down the list of potential new hosters, which saved me time.
As noted above, I had problems with my old web hoster not being able to keep the mySQL server functioning properly. Here's the catch: I have no way of knowing if any (potential new) hoster on a list of top-rated web hosters can do a better job. All web hosters promise 99.9% uptime, that is, they promise that their servers will be up and running 99.9% of time, and will refund some of your money if you can prove otherwise. But really, I'm just shooting in the dark, hoping my new hoster can do a better job keeping the mySQL server working.
Of course, I inquired about this matter with the new hoster's tech support staff before signing up, but all they can do is make promises. This is why I stated above that I'm not sure it would accomplish anything for me to have spent a lot of time carefully researching web hosters.
I chose for my new hoster a company called IX Web Hosting (http://www.ixwebhosting.com). For $99 a year (paid in advance), I get:
* up to 8 domains, each with their own dedicated I.P. address at no additional cost
* 300G storage
* up to 100 mySQL databases
and many other features that tend to be standard with all hosting accounts
You can see that I will save $150 a year in hosting costs with the new hoster (about $100 now vs. about $250 before), and get much more for my money compared with the old web hoster. The main reason I chose this hoster was because of the high number of domains I could host.
Observations about switching hosters
Now, I want to make some observations about the process of switching hosters. I call them observations, but they're really suggestions or advice for church webmasters preparing to switch hosters in the future.
1. I happened to have registered all my domain names with a dedicated domain registrar (GoDaddy, in my case; but there are many domain name registrars from which one could choose). I didn't rely on my old web hoster to register my domain name(s). If you relied upon your web hoster to register the domain for your church website (most web hosters offer this service), well first, you may have paid too much. (There can be quite a markup.) But more importantly, the hoster to a certain extent controls your domain name, since they would have listed themselves as the technical and administrative contacts for your domain name, when they registered your domain name on your behalf.
(Web hosters aren't domain registrars, in most cases, so typically your web hoster just registered your domain with a third party, a dedicated domain name registration company. You could have dealt directly with the registrar yourself and saved money. GoDaddy [http://www.godaddy.com], I might mention, is a large domain name registrar that also now provides extensive hosting services, so GoDaddy is one company that you could use to both register a domain name and provide web hosting.)
2. One of the final steps in the process of switching hosts is to re-point the DNS name server information for your domain to your new hoster's web server. I say it's one of the final steps, but I want to mention this upfront to provide important context. (Because the rest of this list is comprised of the things you want to do first.) There are a number of databases throughout the internet that tell browsers where to find files for, say, www.greatchurchwebsites.org — which server, out of all the thousands of servers around the world that are storing and hosting websites, contains the HTML and image files for www.greatchurchwebsites.org? That's what the Domain Name Server (or System) information is all about, in briefest terms.
When you sign up for a new web hoster (or any web hoster, if you're getting ready to launch a website for your church), you can expect to get several automated emails providing important information about your new hosting account. One of these emails should include the DNS information for your website on the new hosting server. You have to provide this information to your domain name registrar. (If your web hoster registered your domain name for you, then they will take care of this matter on your behalf.)
The DNS for my new hoster looks like this:
ns7.ixwebhosting.com
ns8.ixwebhosting.com
(There's always two lines.)
As stated, this information is typically provided to you in the automated emails that you received from a new web hoster immediately after you open your hosting account. That was not the case with my new web hoster, but I found the information easily enough in my new web hosting account "control panel."
Once you update the DNS information through your domain name registrar, it begins to propagate through all the DNS databases on the internet. This process takes 24 to 48 hours to complete. (It's important to be aware of this; it can be quite vexing to a webmaster.) During that time, people visiting your church website may see files on the old web server, or files on the new web server. Unless you slightly change, say, the home page on the new server, it will be difficult to know which server you are seeing when you visit your own home page. (But more about this below.) Absolute links to other pages on your site may pull from the old server or from the new server, during this 24 to 48 hour period. (So there is some advantage in this situation to using only relative links throughout your site.)
(Those automated emails you get from your new hoster upon signing up will include a special URL to allow you to upload files to, and view pages on, your new web hoster's server during this 24 to 48 hour period.)
OTHER STEPS TO TAKE
Before you change the DNS server information for your website, which is the final step and which starts the clock ticking, you'll want to ensure other important things get done:
3. Remember to download your website log files from your old web hosting server, via ftp, before canceling your old web hosting service. In the course of my doing this, I discovered that I had failed to turn on the option to archive raw log files, a feature accessible through my old hosting account's control panel. (You might want to check to ensure that your current hosting account is configured to archive raw log files.) Thus I could only download raw log files for December 2006, that is, just the previous month. Oops.
However, what I really wanted was the Webalizer files for my site, for as far back in time as possible. Webalizer is a web statistics program commonly offered by web hosting companies for free that interprets the raw log files and displays your website visitor statistics in graphical form. The good news is that I was able to download, from my old hoster's web server, the Webalizer files for Great Church Websites going as far back as I've been with my old hoster. (Since starting Great Church Websites a few years ago, I've used about five web hosters.) Webalizer files consist of some HTML files and many, many imbedded graphics (.png format), which are charts or graphs that show your website statistics for a day or month in graphical form. That was the information I was really after. As stated, I was able to find and download these files for safe storage on my home computer.
4. My old web hoster had a feature to allow me to block I.P. addresses. This was configured via the web hosting account control panel. I used this to stop spammers who spam this forum from ever returning to my website again (in theory). I downloaded the list of blocked I.P. addresses before canceling my old web hosting account.
I was promised by tech support for the new web hoster that I could, with my new account, similarly block I.P. addresses. But, as of the time of this writing, I haven't found where to configure this in my new hosting account control panel. That's OK; it's not the end of the world. The forum software that I use for this forum (vBulletin) has its own I.P. banning feature. By contrast, I would have greatly regretted losing my website statistics files.
5. Do you use a mySQL database on your church website? Watch for the mySQL server address or path changing when you switch hosters. For many web hosters, the address or path of the mySQL server (which is used in configuring connections to a database) is simply "localhost." (Strange phrase, but that's what it is.)
This works well because webmasters who set up a web server on their home or office computer for testing purposes typically also use "localhost" as the address or path for the test mySQL server on their computer. Copy your files from local testing server to your (commercial) web hoster's web server, and your connections to the mySQL database work without a hitch. Or, copy your files from one web hoster that uses "localhost" as the address or path to the mySQL server to another web hoster that does the same, and your mySQL connections will also work without a hitch. (Almost. There's another "gotcha" that I will mention below.) Well, on my old web hoster's server, the address or path to the mySQL server was indeed "localhost." On my new web hoster's server, the mySQL server address or path is "mysql20.ixwebhosting.com." That meant I had to make some changes in certain key files.
(As with DNS information, the address or path to the mySQL server for a new web hosting account is typically provided for you in emails sent out from a web hoster when you open an account. But here again, my new web hoster fell a bit short in this regard and didn't provide this information via email. However, I found the information I needed easily enough in my web hosting account control panel.)
If you use Dreamweaver, and you use PHP and mySQL for your church website, the address or path to the mySQL server on your new web hoster's server (if different from the old) will need to be changed in a "connections" file in the "Connections" directory that Dreamweaver automatically created and uploaded for you.
By the way, have you secured that directory and its contents on your server? Each connections file within this directory contains a user name and password to access a mySQL database. You will want to make sure that that file can't be accessed by hackers.
For starters, make sure that anonymous ftp isn't enabled for your web hosting account. That was the case by default with my old web hoster. Only a few months ago did I discover this to be the case, and disabled anonymous ftp on my old web hosting account. With anonymous ftp enabled, it seems possible, and probable, that anyone could locate and download via ftp the connections file in the Connections directory of your website. (Again, I'm talking to Dreamweaver users here.) Hackers would thereby obtain the user name and password to your mySQL database, so as to hack into your database.
If you have installed a PHP-based proprietary or open-source web application on your church website, such as forum software, membership software, or a web Content Management System, and it relies on a backend mySQL database, then there will be configuration file (often called config.php or some such variation) in the application directory in the root directory of your website that similarly contains the address or path to the mySQL server. Check to ensure that it doesn't need to be updated with the address or path to the mySQL server on your new hoster's web server.
MORE STEPS TO TAKE
6. For those using mySQL databases: You'll have to re-create on the new web hoster's server the database(s) you had on your old web hoster's server. I'm only talking here for a moment about the database(s), not the tables they contain.
(You typically create and name mySQL database[s] via your hosting account control panel. Also, via the control panel, you separately create and configure users (user name/password combinations) for the databases. The actual tables in each database are created separately, later, through other means.)
Here's the other gotcha I alluded to above: in order to avoid have two customers with the same mySQL database name, web hosters tend to take the database name you submit (when creating a mySQL database using the appropriate options in your account control panel) and add a prefix to it based upon your account name. This guarantees unique names for all mySQL databases in a share server environment. Naturally I would want for my website a mySQL database named "greatchurchwebsites," for convenience sake. My old hoster added the prefix "gillaspe" (first eight characters of my last name) to this, so the actual name of the mySQL database ended up being "gillaspe_greatchurchwebsites." I had no choice in the matter.
My new web hoster adds a different prefix to my desired database name, so the same database with the same tables, on my new web hoster's server is called newprefix_greatchurchwebsites. (For security purposes, I won't give the actual prefix.) As you can see, that guarantees that Dreamweaver database connection files will be broken and need updating. It further guarantees that configuration files for your PHP+mySQL-based web applications will similarly need to be updated with the new name of your mySQL database(s).
7. If you already have one or more mySQL databases on your old web hoster's server, how will you get the data stored in them copied to your new web hoster's server? This is important because mySQL databases are not like other software programs. There are no "files" as such that you can find to download via ftp and upload again to your new web hoster's mySQL server.
Instead, you use phpMyAdmin (a free browser-based administrative interface to mySQL that is typically provided for you by web hosters) to export the data (table names plus the records stored in them) from a mySQL database as a text file. You then use phpMyAdmin to import the text file into an empty mySQL database that you've created in advance on your new web hoster's web server. The text file contains SQL statements that re-create the tables in your old database and repopulates them with the original data, included in the text file. You do this one database at a time.
I'm happy to say this worked fine for me. I was able to copy two mySQL databases from my old web hoster to my new web hoster's mySQL server in the manner described. One mySQL database contains tables for my database of well-designed church home pages as well as tables for my paid membership subscription software (aMember). (Yes, these tables ought to have been in separate mySQL databases, but with my old web hoster, I could only have a limited number of mySQL databases.) The other database contains 114 tables for this forum. A third database was for testing purposes and did not need to be copied over to the new hoster.
I regularly back up both the database for this forum and the aMember membership tables. Both programs offer backup operation as a standard feature, from their admin control panel. (The result of a backup operation is the same text file mentioned above.) So far I've not had to actually re-create a corrupted or hacked database. So I was relieved to know I could copy the databases successfully from old server to new server. I know now that I can successfully restore a corrupted or hacked database for this forum or for my paid membership software.
8. I've been talking about mySQL for a while. What about plain old HTML files and graphics? How do you actually get them from one server to another? I had planned to use the "mirror" function in my ftp program (Fetch, a popular Mac OS ftp program) to directly transfer files from my old web hoster's server to my new web hoster's server, via an ftp connection. If only it were so easy.
As I stated above, I have used a number of web hosters since launching Great Church Websites. I've not had a single hoster, then or now, whose ftp server could successfully upload or download an entire site (or even just many files) without timing out or hanging up. That was the case with both my old hoster and my new hoster. Thus my plan to "mirror" my site didn’t work. The ftp connection hung after a few minutes.
The problem with that is that it leaves you not quite sure which directory and files were successfully copied. Where did the program leave off when the ftp connection hung? So I always have to resort to deliberately selecting a handful of files and directories (out of all that need to be copied) and uploading or downloading just these. Then, I select another handful of files and directories and upload or download them. Etc.
In this way, I can carefully control the ftp process to ensure that all files for a website are eventually successfully uploaded or downloaded. If the ftp connection hangs while I am trying to upload or download a certain range of files and directories, then I only have to re-upload or re-download that range of files and directories again, not the entire site.
(If a particular directory itself contains many subfolders, then it may be necessary to upload or download a handful of the contained subfolders at a time, until all the subfolders in this directory have been successfully uploaded or downloaded.)
Alas, Fetch's mirror command didn't allow me to follow the above procedure. (It's copy all or nothing.) So, I ended up downloading to my local computer, in the manner described above, all the files on my website (except the mySQL databases). This gave me a backup of the whole site on my local computer, which is a good idea. Then I uploaded all these files, again in the manner described above, to the new web hoster's server. Some directories contained so many files or subfolders that I had to repeatedly download or upload them to achieve a successful transfer of all the selected files and directories.
This was very time-consuming. I would have preferred to be able to start Fetch's mirror operation and to have been able to walk away from the computer while the program copied all the files from my old hoster to the new hoster, without a hitch. Instead, I had to sit at my computer for something like three hours and laboriously transfer files and directories to my local computer and then to the new web hoster's server, in the manner described. I had to keep my eye on the status of the file transfer at all times.
9. Even when you have (seemingly) successfully copied files from your old web hoster's server to your new web hoster's server, you may find that web applications (e.g., forum software, e-commerce applications, etc.) may need to be reinstalled from the original installation files, in order to work properly.
First, the good news. This forum worked without a hitch on the new hoster's server, once I had copied the HTML and PHP files for the forum application from the old server to the new server and re-created the backend mySQL database. That was a relief!
Unfortunately, my membership software (for paid membership to my website) didn't work once copied over. There were several reasons for this:
a) The application includes several files containing code that is scrambled using a program called ionCube (http://www.ioncube.com). This required something called the ionCube Loader to be installed on my new web hoster's server to unscramble. I didn't realize that I needed to request, via a service ticket, that this be installed for me.
b) Probably it was these files, and possibly others, that are required to be uploaded (and downloaded) to a website in binary format. (The installation instructions actually call for all the files to be uploaded in binary format.) Fetch actually has no such option, so I use the "raw" file format instead. Based upon the error messages I was getting, I must have downloaded and/or uploaded some files incorrectly.
c) In customizing the application's HTML pages, I had made some bad choices in absolute URLs. Members were seeing pages from the old web hoster's server.
Anyway, to make a long story short, I ended up spending $40 and upgraded to the current version of aMember (my membership software). Once I had installed this latest version, the software worked fine. But for a period of about 24 hours, no one could log in to my website to browse my database of church home pages. As well, two visitors to my website wanted to join and were unable to do so. (Both were very gracious about the matter and have since joined.)
10. Count on your email not working for a day. (Ouch!) I mentioned DNS records above. This information takes 24 to 48 hours to propagate throughout the internet, once you have provided it to your domain registrar. But at least with websites, if you make a slight change in your home page, you can track whether the site is loading from the new web hoster's server or your old web hoster's server. No such luck when it comes to your email.
Where email gets sent (to which server) is controlled by "MX" records, which similarly have to propagate throughout the internet when you change hosters. (You don't, however, have to specifically request anyone or any company to transfer your MX records. It just happens, somehow, once the DNS records begin to change.) I don't know, but I would guess, that they don't propagate along with the DNS records, but rather, propagate independently. Unlike with websites (as mentioned above), it doesn't appear to me that there's any good way to track where or from which hoster your email is coming.
Anyway, for about one day, I could receive no email from either my old hoster or new hoster. (Remember, you have to set up email accounts to begin with, using the email options in your new web hosting account's control panel.) This was very frustrating. When I looked at my web mail account (that is, when I checked my email with a browser, as with Hotmail or Yahoo or MSN) on my old hoster, I saw no emails at all. (Not even spam!) I sent test messages to myself that I could see were delivered to my new hoster. I could see they were delivered, using web mail on my new hosting account, but Outlook Express would download no emails at all for about a day. There weren't even any error messages.
Eventually, I received all the emails that weren't showing up, so the good news is, your emails are only delayed for day or so, not truly lost. After a day of no email, the next morning, my email worked fine.
*****
Well, these are the lessons I learned from switching hosters. I hope this information will be helpful to others who are considering switching web hosters.
Sincerely,
David Gillaspey
President
Great Church Websites
& forum admin