Brief instructions on moving the site from one host to another
Those who accompany the work of web-sites, sooner or later have to face a situation when they have to change the company that provides hosting services. I will describe a situation that will allow many beginners and not only administrators to make the move to another hosting with almost no loss of both the performance of the site and the loss of data. Perhaps the actions described by me will seem to be some invention of the bicycle, but I repeatedly witnessed how an uncomplicated move was delayed for a day or more and the site did not work. I have already moved several times and at the same time the site remained accessible, the move was almost imperceptible. I will say right away that I did not use the hosting services for the move, I always did everything myself. Also, this instruction may not be applicable when moving high-load and distributed resources, but I don’t have to suggest to administrators of such resources how to organize such a move.
1 stone. Post office.
If you still use the mail service from the hoster - get rid of this dependence as soon as possible. Use a third-party service for a domain, for example, free services from Yandex.Mail for a domain or Google Apps . Or, if independent management is critical for you, raise your own mail server. Switching to a third-party service will help to avoid data loss when moving and will certainly improve the quality of postal services (for the hoster, the provision of postal services is not a priority, therefore the quality often leaves much to be desired)
2 stone. Choosing a new host
At the moment, most hosters have a trial period when you can order a free tariff for testing for a certain period (from 7 to 30 days). Do not be lazy and order from the hoster who is interested in your prices, such a test rate and bring there one of the third-level domains, or use the resulting IP address (you can see it in the control panel). Ping this IP and compare the indicators with the current indicators, try to put there something test, such as a forum on phpbb3 or the engine for the Joomla or Drupal website. Why are they - these engines are quite demanding of resources, and if in case of even a minimal installation there are problems, then the hoster is not for you. Look at the versions of the software that the hoster uses, it is highly desirable that the versions are not lower than those of your current hoster. Another important parameter that is useful for you to move is the ability to remotely access the SQL server if you use SQL database for the site. Now most good hosts provide this service. If you did not find it in the control panel of this service - ask for technical support. And do not rush to the final choice - you should be conscious of the choice, you should not take up the first available option, be sure to consider a couple more. Based on personal experience, I wouldn’t read the reviews about the chosen host - often these reviews do not contain specific and important information for you and these details will come up at the most inappropriate moment (for example, restrictions on the number of emails per hour may be critical for sites where email notifications about news or personal forum messages are used). If desired, you can even connect any service to check the availability of the resource and see its results in a few days. If everything suits you, feel free to order the tariff you need.
3 stone. SQL-base and testing the site at a new site
This step should be done if you use SQL database for data storage. It should be mentioned that there are CMSs that do not use SQL databases for their work and store everything as files — if you use this option, skip this step and simplify your task. To get started, turn on remote access to the SQL server for the new hosting provider, set up accounts to access it (for access, it is usually enough to specify the IP resource from which to access, there you should indicate the IP where your main site is located now. Connect and configure on a new hosting your domain (for the time being just connect, but do not indicate any changes in the current settings of your domain at the registrar or the current hoster). Now you need to backup data from the SQL database used for the site. If the base is small, there is usually enough money provided by the host. I use a simple and fast Sypex Dumper script for this (I recommend first trying the old version 1 and then trying version 2). Transfer this dump to a new hosting and restore it. In parallel, you can transfer files of your site via ftp to a new host. For testing, I use the capabilities of the hosts file, where you can enter the domain you need and the desired IP. Those. on your machine, enter the domain and the IP address of the new hosting host in the hosts file and through your browser you will begin to open the site from a new location. This is necessary to check the performance of the site in a new place (sometimes there are problems with the encoding). Do not forget to correct the configuration file of the site engine, where specify the new data for working with the SQL database. If everything works, move on. Remove the mention of your domain from hosts, so as not to interfere so far.
4 stone. Transparent relocation.
Read the help of the hoster, what parameters you need to specify for remote access to the SQL database. Make the current version of the SQL database and quickly restore it on the new hosting. Without losing time, correct the configuration file of your site and indicate there that the data will be read already from the remote database. At this stage, the site may slow down, but this is temporary. There may also be data loss if you have a very visited resource and data appear every second. Therefore, for this action, it is desirable to choose the least load time for the site and it is possible to briefly turn on the site maintenance mode so that users do not have time to write something that is lost when switching to another database. After switching on, check the site’s performance and proceed further. Now switch the domain management to another hosting, change the DNS server or IP addresses for the subdomains at the registrar and wait until everything spreads around the world - usually this happens within 3-4 hours, not more. After your site starts to open from the new place, use your hosts file again, enter the old IP address for the domain and copy the site files from the old place. Then delete the mentioning in the hosts of your domain and synchronize the copied files with the files on the new hosting. This will be needed for those resources where during this time any attachments, files or avatars from users could be connected. Just do not replace the configuration file, otherwise the site will stop working until you correct it again.
That's all. In the process of moving the site remains accessible to users, switching databases occurs with almost no data loss, search engines are happy, the admin is sleeping peacefully.