Using the Plesk Migrator, you can migrate from an older Plesk version to the most recent version of Plesk.
To make migrating to Plesk as simple as possible, it includes pre- and post-migration checks, error reporting facilities, and the ability to sync data between an old and a new server following a successful transfer.
Plesk Migrator can also be used to upgrade Plesk to the most recent version (upgrade by transfer): Upgrade by transfer: Upgrade via transfer is the process of upgrading to the most recent Plesk version by transferring all hosting data and settings from the current Plesk server to a new server that has the most recent version installed on it. Upgrades by transfer also help you to reduce the amount of time that services on the production server are unavailable, as websites continue to function normally while the transfer is taking place. During the migration process, no data on the source server (such as subscriptions, customers, or other information) will be updated or erased, and all services will continue to operate normally.
- Make a decision on the hardware for the destination server. It should be larger than or equal to the hardware specs of the source server.
- Select an operating system that is compatible with the destination server.
a) List of operating systems that are compatible with Plesk Obsidian.
b) List of virtualization platforms that are supported by Plesk Obsidian.
c) Plesk Obsidian installation on cloud-based platforms.
d) It is not possible to migrate from Linux to Windows and vice versa.
e) It is necessary to have an x64 operating system.
3. Inspect the target server to ensure that you have a valid Plesk licence. Any questions should be sent to the Plesk License team.
4. Following migration, determine the best approach for bringing domains back up to speed on the destination server.
5. Some other considerations that must be addressed during the planning stage are as follows.
a) Check out which feature in Plesk Onyx has been deprecated.
b) If Plesk is integrated with third-party software, it is possible that some post-migration steps will be required in the third-party programme (e.g. Changes in your custom billing solution, resolution of conflicts in OBAS, etc.)
c) As a result, if there are real-time applications, it is preferable to adopt a specialised approach to these websites and reach an agreement with end users to schedule a pause for website changes, so that data (e.g. database updates) added after the last data sync and before DNS records propagation completion does not remain on the source server.
d) Whenever possible, it is preferable to schedule the migration job outside of business hours if the source server is overcrowded or has insufficient resources.
e) In addition to service plans, subscriptions, and content-rich websites, the Plesk Migrator moves all associated domains as well as all related domains (such as websites, mail, databases, and so on). Please keep in mind that not all of your Plesk setup will be able to be carried over to the new server.
- Install Plesk on the destination server by following the instructions in the Plesk installation guide.
- Inspect the target server to ensure that all of the components that are currently in use on the source server have been installed and configured properly. ASP.NET 2.0-specific applications and MS SQL databases, for example, must be installed on the target server in a suitable version together with the necessary packages (such as AJAX and MVC).
- Installing a Plesk licence on the target server is a simple process (purchased or trial license).
- Check to see that both the source and destination servers have enough disc space available.
- Installing a Plesk licence on the target server is a simple process (purchased or trial license).Assure that the source and destination servers have enough disc space.
- 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).
- Install the Plesk Migrator extension on the destination server and verify connectivity following the Installation and Prerequisites steps.
- Check to see that your source and destination servers are able to connect with one another. Since version 12.5.30, the following ports have been required to be opened in order to facilitate migration:
A) On Linux
For SSH, use port 22 (TCP), and for access to the Plesk XML API, use port 8443 (TCP) on the target server and on the source servers, if you are migrating from Plesk, use port 143 (TCP) for POP3 and IMAP, on both the source and target servers, for post-migration tests.
B) On Windows Server
Ports 135, 139, and 445 (TCP) are available for migration.
Ports 137 and 138 (UDP) are used for migration, and port 10155 (TCP) is used by a special Plesk Migrator service that performs a variety of functions.
TCP ports 10156 (rsync server(migration)), 1434 (TCP), and all (or explicitly selected) TCP ports for MS SQL if it is used as a named instance.
9. Provide notice to your customers about the pre-scheduled transition date. It may be necessary to change the IP address of the name-server for some domains in order for them to point to the new destination server. This phase may necessitate the participation of the consumer, so plan ahead.
10. Reduce the time between requests for DNS zones to 1 hour or less. Clients benefit from a low TTL value since it allows them to get DNS changes more quickly. In the event that a domain is transferred to a new IP address, they will begin operating with the new server sooner:
for domain in $(MYSQL_PWD=`cat /etc/psa/.psa.shadow` mysql -u admin psa -Ns -e”choose name from dns_zone where no name in (select val from misc where param = ‘FullHostName’)”) ; do /usr/local/psa/bin/dns –update-soa $domain -soa-ttl 1h; done
- Migration can be started from the Plesk administrative panel on the destination server by going to Tools & Settings > Migration & Transfer Manager > Start Migration. Begin a new migration by clicking here.
You can always return to this page to pick up where you left off or to start over from the beginning of the migration process. Plesk Migrator’s graphical user interface (GUI) includes help for controls that are connected to migration. The Plesk Migration guide contains detailed information on how to migrate from one hosting platform to another, including instructions on using command line utilities to accomplish the task.
2. Specify the names of the root (Linux) or administrator (Windows) credentials on the source and destination servers in the following sequence, after which click Prepare Migration: Next Step.
Upon connecting to the source server, Plesk Migrator will perform a number of basic tests and retrieve information about hosting objects from the original server.
3. Next, pick the objects that will be transferred. A typical case is the relocation of a group of subscriptions. In this situation, choose the subscriptions for migration from the Add subscriptions tab and define the data that should be moved (web, mail, databases).
4. To proceed, click Move once you have reviewed the list of subscriptions to migrate and the migration options and are satisfied with your selection. A report will be generated by Plesk after it has completed pre-migration checks to identify any potential problems:
The messages from the pre-migration checks should always be taken into account. Determine the importance of each communication by estimating its significance (you can ignore some messages, but some of them might indicate issues blocking the transfer process). Utilize the instructions provided in the message to resolve the underlying issues.. Refresh the pre-migration checking status, and then click Start migration once more to complete the procedure.
A visual representation of migrating stages is provided in the “Migrating to Plesk” course on Plesk University, which also covers fundamental troubleshooting strategies for the pre-check warnings. You can almost certainly find a description of your problem and its solution in one of the knowledge base pages on our website.
Migration (Data Transfer)
To begin migrating after the pre-migration check has returned a clean result, click Start migration to open the migration wizard. Depending on the amount of data being processed, the procedure could take several hours to finish. For example, a migration procedure for 300 domains may take 10 hours (this is a very approximate estimate, as the time required generally depends on the type of data being transferred, the amount of data being transferred, the transfer speed, and the performance of the servers). In the case of a large number of accounts requiring full migration, it may be more convenient to begin the migration process overnight and complete more data synchronisation in the morning. Alternatively, you can migrate customers in groups rather than transferring them all at once.
Every migrated subscription will have a status report available to you. It is also possible to manually check the status of a migration (for example, it is necessary, if the migration process was launched from command line).
In the event that some subscriptions are migrated with issues, they will be marked with the .png or r .png icon on the Overview page after migration, and the cause for the migration will be provided if you click on the Details link on the Overview screen. In order to resolve the issues that have arisen, it is required to redo the migration of the problematic subscriptions.
Performing a post-migration check on the transferred websites, email accounts, databases, and other resources on the destination server is a good idea after you’ve completed your migration. There are two ways to go about it: automatically and manually.
- Post-processing checks that are automated
It is recommended that the Check the operability of services after migration checkbox is enabled while migrating via the GUI. Alternatively, if you are migrating via the command line, a CLI command should be executed once the migration has been completed.
2. Manual post-checking is required.
If you want to perform additional manual checks on the migrated websites, you can do so by adding the following record to the hosts file on the destination server and checking the websites locally (rather than using the site preview functionality in the Plesk panel): Add the following record to the hosts file on the destination server and check the websites locally:
a) record format: 192.0.2.0 example.com, where 192.0.2.0 is the IP address of the destination server to which the example.com domain was migrated. hosts file location: /etc/hosts or b)C:WindowsSystem32Driversetc/hosts record location: /etc/hosts
Manual checks of this nature, as well as related content corrections, are carried out by Plesk engineers as part of the premium migration service package.
Fortunately, you can easily synchronise data for each subscription from the Plesk interface without having to go through the entire migration process over and again. The web, databases, and mail data can all be processed separately. A single domain, a single domain group, or a selection of domains can all be changed at the same time. You will be able to see the Re-sync option near each subscription on the Overview tab as soon as the migration process is completed. It is possible to select several subscriptions for synchronisation by selecting them on the Subscriptions List tab. If necessary, the synchronisation procedure can also be initiated through the command line interface.
It is possible to disable the following services on the source server in order to avoid data changes: Apache, Nginx, and the mail service (Postfix / Qmail) The migration will fail if the database server is shut down. This option results in downtime for web and mail services, and it is only appropriate if you are able to set maintenance time-frames throughout the migration process before proceeding.
Are you stuck in the middle? Aren’t you convinced that you’ll be able to complete the migration process without losing any data? I have some exciting news to share with you. HelptoInstall offers a low-cost Plesk Migration Service that is tailored to your specific needs.