Articles in this section

See more

Plesk Migration and Transfer Guide

Avatar
Kuzma Ivanov
Updated
Plesk for Windows Plesk for Linux ext: migrator ABT: Group B kb: auxiliary dist upgrade dist-upgrade distupgrade FR:PPM-2847

Applicable to:

  • Plesk for Linux
  • Plesk for Windows

Table of contents

 

General Information

Plesk Migrator is a tool that Plesk provides for migration to the latest Plesk versions.

It has pre- and post-migration checks, error reporting features, allows to re-sync data between an old and a new server after migration to make migration to Plesk an easy process.

Plesk Migrator can be also used for upgrading Plesk to the latest version (Upgrade by transfer): Upgrade by transfer is the process of switching to the latest Plesk version by moving all hosting data and settings from the current Plesk server to a server with the latest version installed. 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. During the migration process, data on the source server (Subscriptions', Customers' data, etc) will not be changed or removed as well as all services will be running.

 

Planning migration

With Plesk Migrator you can:

  • Migrate to
    • Plesk Obsidian

 

  • Migrate from
    • Via Plesk or command-line interface
      • Plesk 8.6 and later (Linux and Windows)
      • cPanel
      • Confixx 3.3
      • Helm 3.2
      • Plesk Expand 2.3.2
      • Parallels Pro Control Panel for Linux 10.3.6
      • DirectAdmin 1.51 (when migrating from DirectAdmin installed on Ubuntu 10.x, only custom migration is supported)
    • Via command-line interface only (for assistance, submit a request to Plesk Professional Services team)
      • Enkompass
      • HDE Controller 6
      • Hosting Controller v7 Panel
      • H-Sphere (both Linux and Windows servers can be migrated)
      • Interworx
      • ISPmanager 4 Pro
      • ISPmanager 5 Business
      • MSPControl (commercial and multi-server WebSitePanel)
      • Parallels Plesk Automation (both Linux and Windows servers can be migrated)
      • Control Web Panel
      • WebSitePanel
      • XUnitConf
    • For other platforms or if Plesk version is earlier than 8.6, refer to custom migration guides

 

  1. Choose hardware for the destination server. It should be greater or equal to the source server hardware specifications.

  2. Choose a supported operating system for the destination server.

  3. Both source and destination servers should have valid Plesk licenses. If necessary, you can request a temporary trial license for migration - refer to the article How to get Plesk Web Host edition trial license for migration for further details.

  4. Choose a method of bringing domains online on the destination server after migration.

  5. Other factors that require decision-making during 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 the 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 configurations can be transferred. See the migration limitations article for details.

 

Preparing servers

  1. Install Plesk on the destination server following Plesk deployment guide.

    Note: If the migration is Plesk-to-Plesk, the Plesk version installed on the target server must be equal to or higher than the source server.

  2. Make sure that all components that 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.

  3. Install a Plesk license on the destination server (purchased or trial license).

  4. Make sure there is enough 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 an equal amount of shared and dedicated IPs on both servers for migration).

  6. Install the 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:

    • on Linux

      • 22 (TCP) for SSH
      • 8443 (TCP) for access to Plesk XML API on the target server and on the source servers, in case of migrating from Plesk
      • 110, 143 (TCP) for POP3 and IMAP, on source and target servers for post-migration checks

    • on Windows Server

      • 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

  8. Notify your customers about your pre-scheduled migration date. For some domains, the name-server 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:

    • 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 Window 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

 

Migration pre-check

  1. Start migration from Plesk administration panel on the destination server at Tools & Settings > Migration & Transfer Manager > 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 (Linux) / administrator (Windows Server) account name for the source and destination servers and proceed to the next step by clicking Prepare Migration:


    Screenshot_2020-08-31_New_Migration_-_Plesk_Obsidian_18_0_29_1_.png

    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 "Migrating to Plesk" course on Plesk University 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 knowledge base 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).


mceclip3.png

In case some subscriptions are migrated with errors they will be also marked by an exclamation mark 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 the migration of the problem subscriptions.

 

 

Migration post-check

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: /etc/hosts or C:\Windows\System32\Drivers\etc\hosts
  • 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.

 

Data synchronization

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.

To avoid data changes on the source server it is possible to stop the services on the source server: Apache, Nginx, mail service (Postfix / Qmail). Do not stop database server, migration will fail. This option leads to web and mail services downtime, it is only applicable when you can schedule maintenance time-frame during 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 Server.

 

Transferring Plesk key from source server

Follow this guide if it's required to transfer Plesk license from source to target server.

 

Limitations for migration

To learn more about limitations, visit this KB article.

 

Additional Information

Comments

0 comments

Please sign in to leave a comment.

Have more questions? Submit a request

Related articles