to migrate your Linux Web site to another hosting company
How to migrate your Linux Web site to another
The Web site hosting business has become more competitive in recent
years. If you can find a better hosting deal, you may be able to
save money by switching hosting providers.
But what's the best way to move your Web site? What if you have
a virtual private server (VPS) hosting several domains? What about
PHP and your SQL data? The thought of moving may be daunting, but
moving servers is not difficult if you plan properly. Here's how.
A complete migration involves transferring the site data itself,
meaning all the HTML and possibly PHP and MySQL files and CGI programs.
You also need to modify the Domain Name System (DNS) information
for the site and for the routing of the site email. DNS holds information
that translates IP addresses to human-readable domain names. For
Web site migration, the two important DNS records are the address
(A) record, which tells the browser the IP address of the Web server,
and the mail exchange (MX) record, which tells mail servers how
to route the email.
When you migrate your Web site to another hosting provider, you
need to update DNS to point browsers to the new location of your
site. However, it can take as long as 48 hours for DNS updates to
propagate to all DNS servers on the Internet. Part of your planning
will be how to deal with that delay.
Often your domain name has been registered via a third-party domain
name registration company. When you move the site, your domain name
company remains the same, and only your Web hosting company changes.
If your domain name originaly came with hosting, you may need to
contact your old hosting company to see if you can separate the
hosting package from the domain name.
The keys to a successful move are planning and preparation. Before
the move you should warn your users or customers of the forthcoming
upgrade. Prepare a "server down for upgrade" page for
your old site. Note the IP addresses of your new and old servers;
these will come in handy when DNS is still in flux.
Decide when to upgrade, meaning when your server is least busy.
If you have site statistics, use those to determine the best time.
To reduce down time, it is best to make the DNS changes several
hours before you actually move the domain. As long as your mail
server is running on the new server, you won't lose any email messages.
If you have a static site, you can copy over the data before you
switch DNS and no one will ever know your hosting provider changed.
For a dynamic site you can out a skeleton site on your new server
until you make the full move.
The DNS changes you need to make involve updating the MX and A
records to point to your new server. To do that, you need to access
the control panel provided by the domain name registration company
from which you obtained your domain name.
The new MX record will need to point to the new server. Like A
records, MX records can take a while to propagate through the Internet.
To avoid mail loss you will need to check your old mailbox at least
once a couple of days after the move. You will also need to use
the IP address of the old mail server rather than its domain name,
as you won't be able to rely on mail.domain.com to check the old
mailbox, as that will point to your new server. Depending on how
much control you have of your old server, you could shut down the
mail server after modifying the MX records, in which case incoming
mail would queue up until the new mail server is running, at which
point it would be delivered without problems.
Once you've handled the DNS information, it's time to tackle the
data itself. HTML and PHP files aren't hard to move; just use a
good FTP program and copy the data from one server to the other.
If you have SSH access to both of the servers you can copy the files
directly. If you don't, you will have to download the files to a
local machine and then upload them to the new server.
Moving databases is a bit more complex. Assuming you are using
MySQL, there are several ways to copy over the data. One is to do
a dump of the data into a file and then copy that file to the new
server and populate the new database. To do this you use the mysqldump
$ mysqldump -p -u username mydatabase > mydata.sql
Once copied onto the new server your can populate your new database
with the mysql command:
$ mysql -p -u username mydatabase < mydata.sql
If you don't have SSH access to your servers you won't be able
to use these MySQL commands, but you can still use a tool such as
phpMyAdmin that handles MySQL administration over the Web. phpMyAdmin
has excellent dump and restore features, though for the restore
there is a maximum upload file size of 2,048KB. You can use compression
to maximize your chances of squeezing all of your data into 2MB.
If you lack SSH access and you have too much data for phpMyAdmin
to handle, look into a MySQL synchronization tool called SQLyog
Job Agent (SJA).
If all else fails you will need to ask the support team of your
old hosting company to dump your database for you. Then you will
need to ask the support team of your new hosting company to populate
the new database.
If you have a site with dynamic data, such as an e-commerce site,
you need to make special provisions for the DNS update delays. As
the DNS changes propagate through the Internet some people will
see your new site and others your old. This could cause problems
for you. Imagine a customer placing an order on your old site after
you have moved all the data over to your new site.
There are two ways you can deal with this problem. First, stop
taking orders on the old site once you have started the move. At
the checkout stage display a polite notice asking customers to come
back in a couple of hours, after which they should be taken to the
new site. If you don't have that kind of control over your site
then the best thing is to close down the old site by replacing its
index.html with a notice saying the server is down for upgrades
and will be back soon. An alternative solution is to use a synchronization
tool like SJA to make sure any changes made on the old site get
propagated to the new one.
Finally, watch out for incompatibilities between the software on
your old server and that on the new. Try to make sure that any difference
in versions of crucial software like MySQL and PHP won't cause any
Virtual private servers
If you host a VPS installation then you probably
have several domains to migrate. The problems are the same, but
there is more work to do. If you have a VPS you should warn your
customers in plenty of time about the upcoming move. Call it a server
upgrade, as this will cause less worry.
An advantage of having a VPS is that you have more control of your
sites. You probably have SSH access and you can do things like shutting
down the mail server during the transition. However, if you are
hosting domains for others, then there is the problem of passwords.
When you move to the new server you will need to re-create domains
and user accounts, but you won't have access to the passwords set
by your customers. Generally you will need to issue your customers
new passwords. Again, plenty of advanced warning will help ease
If your VPS uses Plesk 7 Reloaded then migration becomes a lot
easier. This software includes a great (though still experimental)
tool called the Migration Manager that supports migrating from remote
servers using Plesk 2.5.x, 5.x, 6.x, and 7.x, as well as Confixx
2, Ensim 3.5.x, and cPanel 9.
To use the Migration Manager you need to enter the remote host
address (it is best to use the IP address), the login name (normally
root) and the password. After that you set the remote system type
(Plesk, cPanel, etc.) and click Next. The Migration Manager will
then send an agent to the remote server and offer you a list of
domains and clients on the remote server. If you migrate a client
it will bring over the client data (like username and password)
and all the domains belonging to that client. If you import a domain
you will have to have a client account ready on the new server to
take ownership of the imported domain.
Although experimental, for standard cases Migration Manager should
work well. In a recent real-life migration, 95% of the domains migrated
without a problem. There was one domain that had more than 100 subdomains
that failed; They had to be copied over by hand!
When moving servers you need to keep downtime to a minimum. If
you plan properly your users may not even notice that you have switched
servers. If possible, perform a trial run of the actual move. No
one will see your new site because you won't update DNS yet. To
enable you to see your new site, edit the /etc/hosts file on your
client and add your domain name (including the www) with the new
IP address. You should also restart your browser. Don't forget to
remove this entry when you have finished experimenting.
About the Author
Gary Sims ( www.hungrypenguin.net
) has a degree in Business Information Systems from a British university.
He worked for 10 years as a software engineer and is now a freelance
Linux consultant and writer.