Which Objects Are Transferred and Which Are Not

The following limitations apply only to the full migration from Plesk servers.

The following data cannot be migrated from Plesk:

• MIME-type definitions.
• SSI and Microsoft Web Deploy settings.
• ODBC data source names.
• Presence Builder sites.
• Spam filter settings (if migrating from Windows-based platforms).

Migration of Yola websites is not supported.

User accounts and mailboxes whose passwords contain an ampersand (&) cannot be migrated from Plesk 11.5 and earlier.

Web users cannot be migrated from Plesk 17.8 due to XML-API limitations.

After migration, customers will no longer be able to manage email aliases from Customer Panel, although aliases will remain operable.

DNS forwarding is not configured for wildcard subdomains in production migration.

During migration, shared hosting subscriptions are converted to hosting subscriptions in CloudBlue Commerce, and websites are moved to hosting service nodes managed by CloudBlue Commerce.

Subdomains are not migrated as separate websites. The files of subdomains will be manageable from the File Manager of the parent site, but users will not be able to manage the hosting settings of subdomains.

During migration of databases, you have the following options:

• Migrate databases from a local database server managed by Plesk to a local database management system running on the service node.
• Migrate databases from a local database server managed by Plesk to a centralized database node connected to the WebHosting Plesk Module in CloudBlue Commerce.
• If databases are hosted on external database servers connected to Plesk, you can attach the same external database servers to the WebHosting Plesk Module in CloudBlue Commerce. After migration of websites to CloudBlue Commerce, they will continue using the same databases.

After migration, databases will not be assigned to websites, even if they were assigned to websites on the source system. Customers will need to manually assign databases to their websites in Plesk.

During migration, reseller accounts from the source system are converted to customer accounts that belong to the provider. That is, the hierarchy of users under reseller accounts is not observed, and reseller accounts are not created in CloudBlue Commerce.

If you are performing a test migration of subscriptions, the billing component of CloudBlue Commerce will not bill the users of migrated subscriptions. They will bill them only after subscriptions are transferred in the production mode.

APS 1.2 apps will be migrated as usual sites with content and will be reconfigured to work with their databases after migration. However, they will not be listed as installed in the list of applications in Customer Panel.

During a full migration, A, CNAME, and MX resource records are created in the DNS zones of domains. All other resource records are discarded.

During migration, the Migration Manager will restore the hosting settings of webspaces according to the settings defined on the source Plesk servers. If you are performing a migration from Plesk 12.5 or earlier, some hosting settings will be discarded because they are no longer supported by the latest versions of Plesk.

During a takeover migration, DNS records of subdomains cannot be migrated if the subdomains have separate DNS zones operating in the master mode. To resolve this, you can either switch the DNS zones of such subdomains to the slave mode before migration, or leave them in the master mode and manually transfer resource records after migration is finished. For subscriptions with subdomains in the master mode, warning messages will be shown in migration reports.

It is impossible to re-migrate a subscription after it was migrated in the production mode. There might be situations when a customer does not pay attention to the migration notice and continues to create databases and work with website content on the source subscription. After they notice that migration has occurred, they might ask you to repeat migration so as to update their website content. However, you cannot repeat migration if subscriptions have already been migrated in the production mode. To avoid such issues, we recommend that you immediately cancel source subscriptions after migration is finished, to prevent customers from using them. In general, we suggest the following workflow:

1. Inform customers about the upcoming migration.
2. Migrate subscriptions.
3. Cancel source subscriptions to prevent customers from using them.
4. Switch the target service plan to a paid-for plan.