Plesk Migration and Transfer Guide

Applicable Platforms

• Plesk for Linux
• Plesk for Windows

General Overview of Plesk Migrator

Plesk Migrator is a robust tool provided by Plesk designed to facilitate seamless migration to the latest Plesk versions. This powerful utility simplifies the complex process of transferring data and configurations between servers.

It incorporates essential pre- and post-migration checks, comprehensive error reporting features, and the ability to re-synchronize data between old and new servers even after the initial migration. These functionalities ensure that the transition to a new Plesk environment is as straightforward and efficient as possible.

For more detailed information on maintaining data consistency, please refer to the section on Data Synchronization. This step is crucial for ensuring the continued relevance and accuracy of your data throughout the migration process.

Plesk Migrator also serves as an effective tool for upgrading Plesk to its latest version through a process known as "Upgrade by Transfer." This method involves moving all hosting data and settings from your current Plesk server to a new server running the most recent Plesk version. A key advantage of the Upgrade by Transfer approach is its ability to minimize service downtime on your production server, as websites remain operational during the transfer. Furthermore, throughout the migration process, data on the source server (including subscriptions and customer data) remains unaltered and all services continue to run without interruption.

Planning Your Plesk Migration

Careful planning is essential for a successful migration with Plesk Migrator. This tool offers extensive capabilities, allowing you to:

Migrate To:

• Plesk Obsidian

Migrate From:

Plesk Migrator supports migration from a wide range of platforms and versions. The method of migration may vary depending on your source environment.

• Via Plesk or Command-Line Interface (CLI):
  • Plesk 8.6 and later (for both Linux and Windows installations)
  • cPanel
  • Confixx 3.3
  • Helm 3.2
  • Plesk Expand 2.3.2
  • Parallels Pro Control Panel for Linux 10.3.6
  • DirectAdmin 1.51 (Note: When migrating from DirectAdmin installed on Ubuntu 10.x, only custom migration is supported.)
• Via Command-Line Interface (CLI) Only: (For assistance with these migrations, we recommend submitting a request to the Plesk Professional Services team.)
  • Enkompass
  • HDE Controller 6
  • Hosting Controller v7 Panel
  • H-Sphere (supports migration for both Linux and Windows servers)
  • Interworx
  • ISPmanager 4 Pro
  • ISPmanager 5 Business
  • MSPControl (commercial and multi-server WebSitePanel)
  • Parallels Plesk Automation (supports migration for both Linux and Windows servers)
  • Control Web Panel
  • WebSitePanel
  • XUnitConf
• For Other Platforms or Plesk Versions Earlier than 8.6: Please refer to the specific custom migration guides:
  • For Linux
  • For Windows Server

Before initiating your migration, consider the following critical planning aspects:

1. Hardware Selection for Destination Server: It is crucial to choose hardware for the destination server that is equivalent to or superior to the source server\'s specifications to ensure optimal performance.
2. Operating System Compatibility: Select a supported operating system for your destination server. Ensure it aligns with Plesk Obsidian requirements:
   • List of Supported OSes for Plesk Obsidian
   • List of Supported Virtualization Platforms for Plesk Obsidian
   • Installation on Cloud Platforms for Plesk Obsidian
   • Note that direct migration between Linux and Windows operating systems is not supported.
   • The chosen OS must be a 64-bit (x64) operating system.
3. Plesk Licenses: Both your source and destination servers must possess valid Plesk licenses. Should you require a temporary license for the migration period, you can request a trial license. For more details, refer to the article: How to get Plesk Web Host edition trial license for migration.
4. Domain Online Method: Carefully choose the method by which your domains will be brought online on the destination server after the migration is complete.
5. Other Key Planning Considerations:
   • Review any deprecated functionality in Plesk Onyx that might impact your services.
   • If Plesk is integrated with third-party software, anticipate that certain post-migration actions may be necessary within those applications (e.g., resolving conflicts in OBAS, updating custom billing solutions).
   • For real-time applications, it is advisable to adopt a specialized migration approach. Coordinate with end-users to schedule a pause for website changes to prevent data (such as database update transactions) added after the last data synchronization and before DNS record propagation from remaining on the source server.
   • If the source server is experiencing high load or is resource-constrained, it is best practice to schedule the migration job outside of peak business hours, if feasible, to minimize impact.
   • Plesk Migrator efficiently transfers service plans, subscriptions with all associated domains, and websites including their content (such as web files, mail data, and databases). However, it is important to acknowledge that not all Plesk configurations can be transferred directly. Consult the migration limitations article for a comprehensive understanding of these restrictions.

Server Preparation for Migration

Thorough preparation of both source and destination servers is vital for a smooth Plesk migration. Follow these steps to ensure your environment is ready:

1. Install Plesk on the Destination Server: Begin by installing Plesk on your destination server according to the Plesk deployment guide. It is important to note that if you are performing a Plesk-to-Plesk migration, the Plesk version installed on the target server must be equal to or newer than the version on the source server.
2. Component Installation: Verify that all components actively used on your source server are also installed and properly configured on the target server. For instance, if you are migrating a website that uses an ASP.NET 2.0 application and MS SQL databases, ensure that a compatible version of ASP.NET (with necessary packages like AJAX, MVC) and the MS SQL server are installed on the target server.
3. Plesk License Installation: Install a valid Plesk license (either a purchased or trial license) on the destination server.
4. Disk Space Verification: Confirm that there is sufficient disk space available on both the source and destination servers to accommodate all data.
5. IP Address Configuration: Add the required number of IP addresses to the destination server. A best practice is to have an equal number of shared and dedicated IPs on both servers for the migration process.
6. Plesk Migrator Extension: Install the Plesk Migrator extension on the destination server and complete the Installation and Prerequisites steps to verify connectivity.
7. Server Communication: Ensure that your source and destination servers can communicate effectively with each other. Since Plesk version 12.5.30, the following ports must be open for migration purposes:
   • On Linux:
     • 22 (TCP) for SSH: Utilized for data transfer via RSync and for executing necessary actions on the source server.
     • 8443 (TCP): For access to the Plesk XML API on both the target server and the source server (when migrating from Plesk).
     • 110, 143 (TCP): For POP3 and IMAP services, on both source and target servers, primarily for post-migration checks.
   • On Windows Server:
     • (135, 139, 445 - TCP), (137, 138 - UDP): These ports are used for uploading the Plesk Migrator RPC Agent and initiating the agent on the source server. These ports are not mandatory if the agent is started manually by an administrator.
     • 10155 (TCP): For a custom Plesk Migrator service that handles various miscellaneous tasks.
     • 10156 (TCP): For the rsync server, facilitating data synchronization between servers.
     • 1434 (TCP) and all (or manually selected) TCP ports for MS SQL: Required if MS SQL is being used as a named instance.
8. Customer Notification: Inform your customers about the pre-scheduled migration date. It is possible that for some domains, the name-server IP address may need to be updated to point to the new destination server. This step might require customer involvement, so planning ahead is crucial.
9. Decrease DNS TTL: Reduce the Time To Live (TTL) for your DNS zones to 1 hour or less. A lower TTL value allows clients to receive DNS updates more quickly. This ensures that when a domain switches to a new IP, clients will begin interacting with the new server sooner.
   • On Linux:

     # 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

   • On Windows Server:

     "%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

Plesk Migration Pre-Check Procedures

Before the actual data transfer, Plesk Migrator performs critical pre-checks to identify and address potential issues. Follow these steps:

1. Initiate Migration: Begin the migration process from the Plesk administration panel on the destination server. Navigate to Tools & Settings > Migration & Transfer Manager > Start a New Migration. You can always return to this page to resume an interrupted process or commence a new migration. The Plesk Migrator graphical user interface (GUI) provides helpful hints and detailed information relevant to your source hosting platform, including references for command-line utilities.
2. Specify Server Credentials: On the subsequent screen, you will need to provide the root account name for Linux or the administrator account name for Windows Server for both the source and destination servers. After entering these details, click Prepare Migration to proceed.

   

   Plesk Migrator will then establish a connection to the source server, conduct several preliminary checks, and retrieve essential information about the hosting objects present on the source server.

3. Select Objects for Migration: On the next screen, you will choose the specific objects to migrate. A common scenario involves migrating a set of subscriptions. On the Add subscriptions tab, select the desired subscriptions and specify which data components should be migrated (e.g., web content, mail data, databases).

   

4. Run Pre-Migration Checks: Once you are satisfied with your selection of subscriptions and migration options, click Migrate to proceed. Plesk will then execute pre-migration checks to detect any potential issues and will display a detailed report.

   

   It is imperative to carefully review the messages generated by the pre-migration checker. Assess the importance of each message; some warnings might be ignorable, while others could indicate critical issues that would block the transfer process. Address any underlying problems by following the instructions provided in the messages. After resolving these issues, click Refresh to update the pre-migration checking status, and then click Start migration again.

   The "Migrating to Plesk" course available on Plesk University offers a visual representation of the migration steps and provides an overview of basic troubleshooting techniques for pre-check warnings. There is a high probability that solutions to common problems are already documented within our extensive knowledge base articles.

Executing the Data Transfer (Migration)

Once the pre-migration checks yield a satisfactory result without critical errors, you can proceed to click Start migration to begin the data transfer. The duration of this process can vary significantly, often taking several hours, depending on the volume and type of data being migrated. For example, migrating 300 domains could potentially take around 10 hours; however, this is a rough estimate, as actual time is influenced by data characteristics, total amount of data, transfer speed, and server performance.

For migrations involving a substantial number of accounts, it can be convenient to initiate the migration process overnight and perform additional data synchronization in the morning to capture any changes that occurred during the main transfer. Alternatively, you may choose to migrate customers in smaller groups rather than all at once, which can help manage the process and reduce potential impact.

During the migration, you will receive a status report for each migrated subscription, providing real-time updates. It is also possible to manually check the migration status, which is particularly useful if the migration process was initiated from the command line.

Should any subscriptions be migrated with errors, they will be clearly indicated by an exclamation mark on the Overview screen after the migration is complete. Clicking the Details link will reveal the specific reason for the error. In such cases, it is necessary to identify and fix the underlying problems before repeating the migration for those problematic subscriptions to ensure a complete and successful transfer.

Post-Migration Verification

After the migration is completed, it is crucial to perform a post-migration check to confirm that all transferred websites, email accounts, databases, and other services are fully operational and accessible on the destination server. This verification can be carried out either automatically or manually.

1. Automated Post-Check

When migrating via the Plesk GUI, ensure the Check the operability of services after migration checkbox is enabled. If you are performing the migration through the command line, a specific CLI command should be executed once the migration concludes. For comprehensive instructions, please refer to the Plesk documentation on post-migration checks.

2. Manual Post-Check

For more thorough manual verification of your migrated websites, you can add a corresponding record to the hosts file on the destination server and test the websites locally. This method is generally recommended over using the site preview functionality within the Plesk panel.

• Location of the hosts file:
  • Linux: /etc/hosts
  • Windows: C:\\Windows\\System32\\Drivers\\etc\\hosts
• Record format: 192.0.2.0 example.com, where 192.0.2.0 represents the IP address on the destination server to which example.com was migrated.

Such manual checks and any necessary content fixes fall within the scope of the paid migration services offered by Plesk engineers, who can provide expert assistance.

Data Synchronization Strategies

During the period between initial migration and final DNS propagation, services continue to operate on the source server. This can lead to the migrated content on the destination server becoming out of sync with recent changes. To address this, Plesk provides robust data synchronization features.

You can easily synchronize migrated data for individual subscriptions directly from the Plesk interface without needing to repeat the entire migration process. Synchronization can be performed separately for web content, databases, and mail data. It is also possible to synchronize data simultaneously for all domains, for a single domain, or for a selected group of domains.

Upon completion of the migration, you will observe a Re-sync option conveniently located next to each subscription on the Overview tab. On the Subscriptions List tab, you have the flexibility to select multiple subscriptions for batch synchronization. If preferred, the synchronization process can also be initiated via the command-line interface (CLI).

To prevent data modifications on the source server during critical synchronization phases, you may choose to temporarily stop web services like Apache and Nginx on the source server. However, it is imperative not to stop the database server, as doing so will cause the migration to fail. This option, while effective in preventing changes, will result in web services downtime and is thus only applicable when a maintenance time frame can be scheduled during the migration.

Stopping mail services (Postfix / Qmail) is generally not necessary. New mail messages can be migrated from the source server even after subscriptions are switched (via DNS/IP) to the new target server, by performing a mail-only synchronization. To do this, click the Re-sync option next to the subscription on the Overview tab and select the "Re-sync mail messages" option. This step should be executed after updating DNS/IP records.

Furthermore, during or after the migration process, new subscriptions, domains, accounts, databases, or other business objects might be created or modified on the source server. These newly created or altered objects can also be synchronized. To perform this, click the Re-sync option for a subscription on the Overview tab and select the option "Re-sync business objects":

Synchronization of business objects is also essential if critical configurations such as account passwords, DNS records, databases, database users, FTP and Plesk users, GIT repositories, or SSL certificates were changed on the source server either during or after the initial migration.

It is strongly recommended to perform a final data synchronization immediately before switching subscriptions to the target server, and only after the sites on the target server have been thoroughly verified either manually or automatically using the post-check procedures. This ensures that the data is as current and accurate as possible, and that your sites perform exactly as expected in the new environment.

Finalizing the Switch: IP/DNS and Production Rollout

Once all post-migration checks are successfully completed and the migrated domain data is fully synchronized with the source server, the final step is to bring your services online on the destination server, moving them into production.

The exact method for this transition depends on the IP/DNS switch scenario that was selected and planned during the initial migration stages. This typically involves either updating domain names in your DNS records to point to the new server’s IP addresses, or directly changing the IP addresses associated with domains within Plesk itself. Specific guides are available for: Linux environments and Windows Server environments.

Plesk License Key Transfer

Should it be necessary to transfer your Plesk license key from the source server to the target server, please follow the detailed instructions provided in this comprehensive guide.

Known Limitations During Migration

To gain a complete understanding of any potential limitations that may affect your migration process, we highly recommend reviewing this detailed knowledge base article. This resource outlines specific scenarios and configurations that may have restrictions during migration.