Note that transferring email is not included in the framework above. As email has its own DNS records, it can be transferred separately as another (somewhat similar) process.<\/p>\n\n\n\n
Understand Hosting Requirements of the Website<\/h2>\n\n\n\n
Among first things to be verified is to make sure the new server to which we are transferring the website has all the major software required to run the website. Along with major software, we should also check the software is running compatible versions. And finally, we need to check for any necessary modules or compilation configurations within the required software.<\/p>\n\n\n\n
- Major Software<\/li>
- Software Versions<\/li>
- Modules & Compilation Configuration<\/li><\/ul>\n\n\n\n
In reality, if you have full (root) control of the new host, on a simple site, you can be somewhat lazy with this step as you can install and configure any needed requirements on the new hosting server during the testing phase based on errors that arise. Mostly we make sure to verify the current transfer isn't the rare case where proprietary software is running as a system service. Most websites, even if they have proprietary software, will have the software as part of the website and not as a service installed on the server, so it will get copied over as part of the file system transfer.<\/p>\n\n\n\n
Most websites need three major services:<\/p>\n\n\n\n
- Web Server<\/li>
- Database Server<\/li>
- Scripting Language Interpereter<\/li><\/ul>\n\n\n\n
Specifically, the set up is most often a LAMP (Linux, Apache, MySql, PHP) configuration:<\/p>\n\n\n\n
- Apache (Web Server)<\/li>
- MySql (Database Server)<\/li>
- PHP (Scripting Language Interpereter)<\/li><\/ul>\n\n\n\n
Within each of those services, specific versions may be required. For example PHP has depreciated a lot of functions over the years. If you the site you are transferring was originally programmed on a version of PHP lower than PHP 5.X, you are probably going to have a lot of code break if the new server is running PHP 7.X. Again, you'll find this out in the testing phase before you move the public traffic to the new server, but it's good to get an idea of what type of struggles you are going to have to complete the transfer.<\/p>\n\n\n\n
Rather than installing old software versions on the new server, we always look to upgrade the code to be compatible with the latest software versions. Most of the time this is not a big issue, it usually arises when a client contracts proprietary software to be coded (i.e. via Upwork.com) that can't be updated with a few clicks like a commercial or open source CMS (Content Management System) could. NOTE: If you are running a CMS, it may be easier to simply install the CMS on the new server and use a tool to export the website content and its configurations from the old server and import it to the new server. For instance, if you are using WordPress, simply search for \"WordPress Migration Plugin<\/a>\" to move the website to a fresh installation of WordPress on the new server. You can still us the testing techniques described below to verify functionality before switching the public traffic.<\/p>\n\n\n\n
Export databases to backup files<\/h2>\n\n\n\n
The next step to complete in a website host transfer is to export any databases to files. For simplicity, we export the databases to files within the file system to be copied over to the new server. Typically the client has a MySQL database and the command to export the database is fairly simple:<\/p>\n\n\n\n
mysqldump --opt -uUSER_NAME<\/span> -p DATABASE_NAME<\/span> | gzip > \/PATH\/TO\/FILESYSTEM\/DATABASE_NAME<\/span>.gz <\/p><\/blockquote>\n\n\n\n
Obviously, you'll need to replace the red all-capitals with the website's information. And don't save this file to the public html directory where it could be exposed to the public.<\/p>\n\n\n\n
Search for and export cron jobs<\/h2>\n\n\n\n
Though it's rare, some websites will have their own cron jobs<\/a> which need to be found and transferred to the new server.<\/p>\n\n\n\n
Cron Table:<\/em><\/p>\n\n\n\n
The first place to look is in the users 'crontab'. Run the following command (as the user) to view if the user for the website has any cron jobs in its cron table:<\/p>\n\n\n\n
#Show the user's cron table:
crontab -l<\/p><\/blockquote>\n\n\n\nIf there are cron jobs, take a look at the commands to see what's needed. You may need to update any file links if the new server has a different file system structure.<\/p>\n\n\n\n
To dump the crontab to a file that can be transferred during the secure copy to the new server:<\/p>\n\n\n\n
#Save the users cron table to a file:
crontab -l\u00a0 > \/PATH\/TO\/FILESYSTEM<\/span>\/crontab.data<\/p><\/blockquote>\n\n\n\nAgain, don't save this file to the public html directory.<\/p>\n\n\n\n
Cron Directories:<\/em><\/p>\n\n\n\n
Next, you'll need to make sure any links weren't put in the system cron folders. Cron folders tend to differ based on the Linux flavor (Ubuntu, Fedora, Red Hat, CentOS, Debian, etc).<\/p>\n\n\n\n
For CentOS a quick way to check for files is to run a command like the following:<\/p>\n\n\n\n
#Search for links in the cron directories:
ls -la \/etc\/cron* | grep USERNAME<\/span><\/p><\/blockquote>\n\n\n\nThis will show any files or links owned by your user in the cron directories. You may just want to pipe this information into a file within the file system to manually recover on the new server.<\/p>\n\n\n\n
#Search for links in the cron directories:
ls -la \/etc\/cron* | grep USERNAME<\/span> > \/PATH\/TO\/FILESYSTEM<\/span>\/cron.links.data<\/p><\/blockquote>\n\n\n\nCopy the file system to the new server<\/h2>\n\n\n\n
The next step is to get everything over to the new server. This can be done with scp<\/a> or rsync<\/a>.<\/p>\n\n\n\n
#scp - logged into the new server
#Note the dot \".\" at the end of the remote file system as it is needed to copy hidden files starting with a .
scp -rp\u00a0USER_NAME@DOMAIN.COM:\/PATH\/TO\/FILESYSTEM\/. \/PATH\/TO\/NEW\/FILESYSTEM\/<\/p>#rsync - logged into the new server
#Note the trailing slash on the remote filesystem and the lack of it on the local system
rsync -avz --delete\u00a0USER_NAME@DOMAIN.COM:\/PATH\/TO\/FILESYSTEM<\/span>\/ \/PATH\/TO\/NEW\/FILESYSTEM<\/span><\/p><\/blockquote>\n\n\n\nSet up and import databases<\/h2>\n\n\n\n
On the new server you'll need to set up your databases. Typically you'll want to set them up with the same database name and credentials as the previous server, as these credentials will likely be hard coded in the website's application (usually in a \"config\" file).<\/p>\n\n\n\n
Creating Databases:<\/em><\/p>\n\n\n\n
Setting up the database can typically be done with phpMyAdmin or with a couple simple mysql commands:<\/p>\n\n\n\n
#Logged in as a MySQL user on the new server with permissions to create users & databases
CREATE DATABASE DATABASE_NAME<\/span>;
GRANT ALL PRIVILEGES ON DATABASE_NAME<\/span>.* TO 'DATABASE_USERNAME<\/span>'@'localhost' IDENTIFIED BY 'DATABASE_PASSWORD<\/span>' WITH GRANT OPTION;<\/p><\/blockquote>\n\n\n\nImporting Databases:<\/em><\/p>\n\n\n\n
Now you'll want to get the database you previously exported (and compressed) and transferred over to the new server as part of the file system into the database. You can use phpMyAdmin or commands similar to the following:<\/p>\n\n\n\n
gzip -dc \/PATH\/TO\/FILESYSTEM\/DATABASE_NAME<\/span>.gz | mysql -u DATABASE_USERNAME <\/span>-p DATABASE_NAME<\/span><\/p><\/blockquote>\n\n\n\n
Set up cron jobs<\/h2>\n\n\n\n
Now you'll need to restore any cron jobs.<\/p>\n\n\n\n
#Restore the users cron table to the new server's cron table:
#NOTE: If the file system paths have changed from the old server to the new server, you'll need to first edit this file
crontab \/PATH\/TO\/FILESYSTEM<\/span>\/crontab.data<\/p><\/blockquote>\n\n\n\nIf the file system path has changed from the old server to the new server, you'll likely need to make changes to the crontab file before importing or the any paths will be corrupt. For instance, if the user's directory used to be located at \"\/users\/home\/USERNAME\" and its now at \"\/home\/USERNAME\", you'll probably have updates to make.<\/p>\n\n\n\n
Test the website on the new server<\/h2>\n\n\n\n
This is where the fun really begins, because this is where you'll find the differences between the old and the new servers. You'll spend most of your time in this step figuring out how to get the website running smoothly. You'll have to fix configuration issues with different software versions, update code, install needed modules and much, much more.<\/p>\n\n\n\n
There are too many issues that will typically arise to fully discuss here. The good news is that you can fix all the issues on the new server while the public traffic is still going to the old server.<\/p>\n\n\n\n
One caveat to watch out for<\/span><\/strong> is that if the old server is still collecting data (ie memberships, newsletter emails, etc), you may need to re-import that data into the new server. \u00a0If the data is located in a database, before you switch public traffic via DNS to the new server, have to go back to the old server, export the database again, copy it to the new server and re-import the database. \u00a0This should not be a big issue if you don't have to make changes to the database for it to run on the new server. \u00a0If you do have to alter the database for some reason during testing, then be sure to track your changes so you can re-implement them when you re-import the database before switching public traffic over to the new server.<\/p>\n\n\n\n
Some articles will tell you to test using a special url on the new server or by using the IP address of the new server.<\/p>\n\n\n\n
#Some articles will tell you to test the new website in a browser with a url like:
http:\/\/NEW_SERVER_IP_ADDRESS<\/span>\/~USERNAME<\/span>\/<\/p><\/blockquote>\n\n\n\nIf configured by the web server, that may work, but often times you'll struggle with the website itself redirecting you back to your domain (on the old server - because you haven't changed DNS yet). \u00a0Some websites do this because they have multiple domains pointing to them (SEO reasons). \u00a0Most often it more specifically happens because whoever set up the server was trying to remove having duplicate websites at http:\/\/www.domain.com and http:\/\/domain.com, which search engines don't like. \u00a0So when the code sees the URL is not for the specific domain, it may redirect (WordPress does this).<\/p>\n\n\n\n
The trick I like to use is to fool your local computer into thinking the domain's DNS has been transferred even though you haven't yet done so. On a windows machine you do this in the hosts file by hard-coding the new server's IP address onto the domain name. Windows checks this hosts file for domains before reaching out to authoritative DNS servers to get an IP address for a given domain. If a domain match is found in the hosts file, Windows does not check any further. Also, updates are immediate, meaning you can change the IP address as much as you want in the hosts file and there's no waiting for the changes to propagate.<\/p>\n\n\n\n
# On Windows, edit your hosts file to point the domain to the new server
# The file is located at: C:\\Windows\\System32\\drivers\\etc\\hosts
# You'll need to open the editor with administrator privileges (right click the icon and choose \"run as administrator\".
# Add a line of the following format:
IPADDRESS DOMAIN_NAME<\/p><\/blockquote>\n\n\n\nIf we were transferring DedicatedManagers.com to the IP 169.48.115.29, the line(s) would look like:<\/p>\n\n\n\n
169.48.115.29 dedicatedmanagers.com
169.48.115.29 www.dedicatedmanagers.com<\/p><\/blockquote>\n\n\n\nNow, as far as your local computer is concerned, the website is now located at the new server's IP address. (By the way, the power of editing this file is how a hacker can get you to visit a malicious version of a website without you knowing it.)<\/p>\n\n\n\n
Another caveat to note<\/span><\/strong> is that since the website will be exactly the same on the new server as the old server (especially once it's running smoothly) you'll want to have a way to verify that you are seeing the new server when you load it in your browser. \u00a0I like to make a small change to the header or footer of the website. \u00a0Usually, I'll put \"new server\" in the footer somewhere. <\/p>\n\n\n\n
Also, Chrome has great debugging tools that lets you disable the cache while the debugger is open and you can also view the IP address of the currently loaded page. In the screen shot below, I've opened the debugging inspector by right-clicking (anywhere) on the page and choosing \"Inspect\". Then I clicked on the \"network\" tab (you may need to reload the page if it's empty). Also note that even thought I have had \"disable cache\" checked, and other websites said it should clear them, 301 permanent redirects do not seem to be cleared. My solution was to open an \"incognito window\" which seems to not store 301 redirects between incognito sessions.<\/p>\n\n\n\n
![\"web](\"https:\/\/www.dedicatedmanagers.com\/wp-content\/uploads\/2017\/09\/Chrome-IP-and-Disable-Cache.2-857x1024.png\")
<\/figure>\n\n\n\nYou can test with this setup for as long as you need to test using the actual website url and fix errors until the website is running smoothly on the new server. Just remember to take the entries out of your local computer's hosts file when you are done with the transfer.<\/p>\n\n\n\n
Transfer DNS to point the public traffic to the new server<\/h2>\n\n\n\n
Once your testing is complete and you've got the website running without any issues on the new server, you can log into wherever your DNS is controlled and change the IP address to the new server. The public traffic will switch over by the end of the TTL time set in your DNS. Years ago, the TTL value was typically set at 24 hours to reduce server loads. As bandwidth has increased and computers have gotten faster, we typically see a 4-8 hour TTL. If you want instant gratification, prior to your switch, change the TTL value for the DNS record to around 5 minutes (do so longer before than the TTL Value), so that when you perform the switch, all your traffic will come to the new server right away. This also has the advantage of being able to very quickly switch back if, for some reason, your testing wasn't thorough enough and you need to get the traffic back to the old server quickly while you fix whatever problems arose (Changing the TTL value should probably be s step in itself!).<\/p>\n\n\n\n
Wait to verify there are no uncovered issues<\/h2>\n\n\n\n
If you've got the time to keep the old server running, wait a few days before deleting the files and your service on the old server. This will give you a chance to go back to the old server and solve and subtle issues that may arise. Typically an extra week is plenty.<\/p>\n\n\n\n
Delete website on old server<\/h2>\n\n\n\n
After you've had enough traffic at the new server, and you are confident there are no issues, its time to delete your files on the old server and cancel your service.<\/p>\n\n\n\n
Conclusion<\/h1>\n\n\n\n
In conclusion, this article was written to help point out the typical major tasks involved in transferring a website to a new host. This is not an all-encompassing guide. There are plenty of nuances to overcome. Please use this article as a starting point or initial framework to help guide your research into your endeavor to move your website to a new host. Realize, if your website is simple, some of the tasks above will not be required; they are documented to help those with a more difficult set up prepare to transition to a new hosting server.<\/p>\n\n\n\n