- Plesk Onyx
Table of contents
- General Information
- Planning migration
- Preparing servers
- Migration pre-check
- Migration (data transfer)
- Migration post-check
- Data synchronization
- Switching IP/DNS (moving to production)
- Limitations for migration
Upgrade by transfer is the process of switching to the latest Plesk version by moving all the hosting data and settings from the current Plesk server to a server with the latest version installed.
This approach is preferred when upgrading servers with an operating system (OS) that either falls under the end-of-life policy or is approaching its support termination date.
Upgrade by transfer also allows you to minimize the downtime of services on the production server, as websites stay online while the transfer is in progress.
This article provides some recommendations on performing a smooth Plesk transfer to the newer version.
1. Verify that your hosting platform on the source server is supported for migration.
List of supported panels for migration .
Migration from the supported hosting platforms is GUI based and automated. If your hosting panel is not yet supported, please request assistance. If your Plesk version is older than 8.6, then migration is also possible, but it cannot be done via Plesk Migrator GUI. It should be done as described in the custom migration sections: for Linux and for Windows. We recommend requesting assistance for such migrations as well.
2. Choose hardware for the destination server. It should be greater or equal to the source server hardware specifications.
3. Choose a supported operating system for the destination server.
List of supported OS for Plesk Onyx .
List of supported Virtualization platforms for Plesk Onyx.
Installation on Сloud platforms for Plesk Onyx .
- migration from Linux to Windows and vice versa is not supported
- selecting x64 OS is recommended (Plesk Onyx doesn’t support x86 OS)
5. Choose a method of bringing domains online on the destination server after migration.
6. Other factors that require decision making on the planning stage:
- check what functionality is deprecated in Plesk Onyx.
- if Plesk is integrated with 3rd-party software, some post-migration actions might be needed in that software (e.g. conflict resolving in OBAS, changes in your custom billing solution).
- if there are real time applications it is better to take a specialized approach to these websites and agree with the end users to arrange a pause for changes to the websites, so the data (e.g. database update transactions) added after last data sync and before DNS records propagation completion does not stay on the source server.
- if the source server is overloaded or is low on resources, it is better to plan the migration job outside of business hours, if possible.
- Plesk Migrator transfers service plans, subscriptions with all associated domains, and websites with content (such as websites, mail, databases, and so on). However, you should take into account that not all Plesk configuration can be transferred. See the migration limitations article for details.
1. Install Plesk on the destination server following Plesk deployment guide .
2. Make sure that all components which are in use on the source server are installed and configured on the target server. For example, if you are planning to migrate a website with an ASP.NET 2.0-specific application and MS SQL databases, make sure that ASP.NET of a compatible version with needed packages (e.g. AJAX, MVC) and MS SQL server are installed on the target server.
4. Make sure there is sufficient disk space on the source and destination servers.
5. Add the necessary amount of IP addresses on the destination server (the best practice is to have equal amount of shared and dedicated IPs on both servers for migration).
6. Install Plesk migrator extension on the destination server and verify connectivity following the Installation and Prerequisites steps.
7. Make sure your source and destination servers can communicate with each other. Since version 12.5.30, the following ports are required to be opened for migration purpose:
- 135, 139, 445 (TCP) ports for migration
- 137, 138 (UDP) ports for migration
- 10155 (TCP) for a custom Plesk Migrator service performing miscellaneous tasks
- 10156 (TCP) for rsync server(migration)
- 1434 (TCP) and all (or manually selected) TCP ports for MS SQL, if it is used as a named instance
- 22 (TCP) for SSH
8. Notify your customers about your pre-scheduled migration date. For some domains, the nameserver IP address may need to be switched to the new destination server. This step may require customer involvement, so plan ahead.
9. Decrease the TTL for DNS zones to 1 hour or less. Low TTL value allows clients to get the DNS updates faster. In case of switching a domain to the new IP they will start working with the new server earlier.
$ for domain in $(MYSQL_PWD=`cat /etc/psa/.psa.shadow` mysql -u admin psa -Ns -e"select name from dns_zone where name not in (select val from misc where param = 'FullHostName')") ; do /usr/local/psa/bin/dns --update-soa $domain -soa-ttl 1h; done
"%plesk_bin%"\dbclient.exe --direct-sql --sql="select name from dns_zone" > C:\domains.txt
FOR /F %D IN (C:\domains.txt) DO IF NOT '%D' == 'name' "%plesk_dir%\bin\dns.exe" --update-soa %D -soa-ttl 1h
1. Start migration from Plesk administration panel on the destination server:
Server Management > Extensions > Plesk Migrator > Start a New Migration .
You can always go back to this page to continue from where you left off or to start a new migration process. Plesk Migrator GUI contains hints for controls related to migration. Detailed information depending on source hosting platform including migration via command line utilities reference is in the Plesk Migration documentation .
2. Next, specify root/built-in administrator accounts for the source and destination servers and proceed to the next step by clicking Prepare Migration :
Plesk Migrator will connect to the source server, do several preliminary checks and fetch information about hosting objects from the source server.
3. On the next screen, select objects for migration. Typical scenario is migration of a set of subscriptions. In this case, on the Add subscriptions tab choose the subscriptions for migration and specify what data should be migrated (web, mail, databases).
4. When you are satisfied with the list of subscriptions to migrate and the migration options, click Migrate to proceed. Plesk will run pre-migration checks to detect potential issues and display a report:
You should always pay attention to the messages from the pre-migration checker. Estimate the importance of each message (you can ignore some messages, but some of them might indicate issues blocking the transfer process). Solve underlying problems using the instructions provided in the message. After that, Refresh the pre-migration checking status, and click Start migration again.
The Migration section of our Plesk Expert education course contains visual representation of migration steps and overviews basic techniques to troubleshoot the pre-check warnings. There is a good chance that the problem and its solution is already described in one of our Knowledgebase articles.
Migration (data transfer)
When the pre-migration check returns a clean result, click Start migration to begin migrating. The process can take several hours to complete depending on the amount of data. For example, a migration process for 300 domains can take 10 hours (this is a very rough estimation, as the time generally depends on what the data is, its amount, transfer speed and servers’ performance). In case of full migration for a notable number of accounts it might be convenient to launch the migration process overnight and do additional data synchronization in the morning. Alternatively, you can migrate customers by groups, not everything at once.
You will see a status report for every migrated subscription. It is also possible to check migration status manually (for example, it is necessary, if the migration process was launched from command line).
In case some subscriptions are migrated with errors they will be also marked by or on the Overview screen after migration and the reason will be displayed, if you click the Details link. It is necessary to fix related problems and repeat migration of the problem subscriptions.
After migrating, you can perform a post-migration check to verify that the transferred websites, email accounts, databases, and so on are available on the destination server. It can be done either automatically, or manually.
1. Automated post-check
When migrating via GUI, Check the operability of services after migration checkbox should be enabled. If you are migrating via the command line, a CLI command should be run after the migration is finished. For details, refer to Plesk documentation .
2. Manual post-check
If you would like to do additional manual checks of the migrated websites, add the corresponding record to the hosts file on the destination server and verify the websites locally (this is the recommended process, rather than site preview functionality in the Plesk panel):
- location of the hosts file:
- record format: 192.0.2.0 example.com, where 192.0.2.0 is the IP on the destination server the example.com was migrated to.
These types of manual checks and related content fixes are performed by Plesk engineers in scope of the paid migration service.
As all the services operate on the source server during migration and you may want to take time to verify everything before going online with the destination server, the migrated content can get out of sync after some time. To solve it, you can easily synchronize migrated data for each subscription from the Plesk interface without repeating the whole migration process. It can be done separately for web, databases, and mail data. It can also be done simultaneously for all domains, for one domain or a group of selected domains. When migration is completed, you will see the Re-sync option near each subscription on the Overview tab. On the Subscriptions List tab, you can also select multiple subscriptions for synchronization. It is also possible to launch the synchronization process from CLI, if necessary.
If you can suspend domains on the source server before starting migration, then the synchronization option is not needed as related data on the source server will not be changed. However, as this option means services interruption, it is only applicable if you can stop the services on the source server during the time of migration.
Switching IP/DNS (moving to production)
When all the post checks are completed and the migrated domains’ data is synchronized with the source server, it is time to turn the services online on the destination server.
The way it should be done depends on what IP/DNS switch scenario was chosen during the migration planning stage. It is either pointing domain names in DNS to the new server’s IPs or changing the IPs of domains in Plesk: for Linux , for Windows.
Limitations for migration
- The settings of Plesk services, such as installed PHP handlers, Fail2Ban settings, ModSecurity settings, firewall settings, and so on are not transferred.
- Custom configuration (e.g. permissions set not via Plesk, web server configuration changes done not via Plesk) is not transferred.
- Any server component or software that is installed separately from Plesk, like Apache or PHP modules, should be installed on the target server anew.
- Server-wide settings, such as PHP settings defined in Home >Tools & Settings, are not transferred
- Service plans with no subscriptions assigned are not transferred. Resellers and customers that do not have any subscriptions are not transferred as well.
Please read more information about the limitations of Plesk Migrator in the Knowledge base article .