The Plesk Migration tool is a program specific to Plesk which allows us to transfer a whole domain and all it's settings between two Plesk servers. Not only does it copy all the website files, but it will backup all e-mail accounts, inboxes, databases, logs, configuration settings, etc. from the old server and restore them on the new server.
By the end of a migration the domain should be configured just as it was on the old server, with all the files and settings intact.
Only JAB Web Solutions staff can perform a migration between servers. If you would like to discuss migrating a domain between accounts on different servers, please Submit a Ticket to our Support Team.
How does a Migration work?
At it's simplest level, a migration simply makes a note of all the configuration settings of your domain (e.g. usernames, passwords, e-mail accounts, PHP/Perl/Python settings) and then backs up all your files, e-mails and databases, before transferring them between servers.
Once transferred, the receiving server rebuilds the domain based on these settings, re-creating the e-mail accounts, databases, etc. before putting all the relevant files back into their correct places on the new server.
Depending on the size and the complexity of the domain this can take from about 10 minutes up to an hour.
Can a Migration fail?
Yes. The way Plesk performs a migration, it assumes that all the usernames, database names, etc. you have chosen on the old server don't exist on the new one. Therefore, when it tries to configure the username for your domain's FTP account, or recreate one of your domain's databases, and someone on the new server has already chosen that (user)name, it will fail.
In this case, we'll stop the migration and inform you of the problem(s) before continuing. We don't know how your domain works, such as which databases, etc. are important to it and which are not (for example the failed database may only be a development database), and believe that it's better to keep the site running on the old server while we work out the problems than attempt to run with a failed migration.
About 80-90% of migrations run without a problem, we do experience one with your domain, we'll work with you to sort it out first before continuing.
What other problems are there with a Migration?
There are a number of steps that we need to go through when performing a migration:
- Select the domain(s) to migrate and run;
- For each domain successfully migrated, reset it's DNS to the default values for the new server (updates it's IP address);
- On the old server, change the DNS settings on the domain from Master to Slave mode, and point it at the new server;
- For domains which we are the registrar, update it's name-servers to point to the new server (note that if we are not the registrar, you will need to do this yourself); and
- Wait for propagation and then shutdown the domain(s) on the old server.
Once the migration has been completed, everything else is associated with the domain's DNS (updating the records to reflect it's new IP address, & changing the name-servers), and due to the way DNS works around the Internet, these changes are not immediate.
How DNS works and why the propagation effect exists is covered in detail in the following Knowledgebase article:
For all our servers, the TTL for our DNS is 4 hours, so there will be a 4-hour window where both servers are dealing with requests for the domain (the progression is gradual, with more requests going to the new server as we move closer to the end of the 4-hour window).
However, before the new server can begin to take over, the name-servers normally need to be updated to redirect all new requests to the new server, allowing the new DNS records to be returned. This change alone can take around 24 hours to complete. Therefore, to overcome this, we set the domain's DNS on the old server from Master mode (it set's the records and replies to requests with them) to Slave mode (it picks up the records from another server and responds to requests with them instead).
This eliminates the propagation effect for the name-server change (even though the change is still taking place) as both servers will now be replying with the same data. It therefore doesn't matter which server you are talking with, reduceing the main propagation window to no more than 4 hours (the time it takes for the actual DNS records to expire).
We will also (unless specifically requested) only perform a migration in the early hours of the morning when the servers and the sites are at their quietest (as most people are asleep). This minimises the number of requests your site will handle, and by the time people wake up and/or return to work, the site will be running on the new server.
So, what effect will this have on my website?
If you, or anyone else, make any changes to the website on the old server (such as upload files, make a post on a forum, or commenting on a blog) after the migration (but before propagation has completed) then they will stay on the old server. Once propagation has completed and all requests go to the new server, any changes to the old version will be 'lost'.
If you run a site that is database-driven, we recommend that you enable maintenance mode (if available) either on the old server after the migration, or on the site before migration and re-enable it after the 4-hour window. This will prevent any changes to the site and make sure nothing is lost as part of the change.
However, we cannot do the same with e-mails and there will always be a risk that one or more e-mails may be lost as part of the transfer. If you believe an e-mail has come through to the old server and not the new server, please Submit a Ticket to our Support Team who will investigate for you.
Finally, once the DNS and name-server propagation has completed, and the settings on the old server are no longer needed, we'll suspend your account on the old server pending it's removal (after all, it's no longer being used).
