Supported Platforms and Configurations

Migration is available from Odin Business Automation Standard (OBAS) 4.5.5. The following items are migrated:

  • OBAS accounts. Administrator and reseller accounts are migrated only with the websites and subscriptions that belong to them.
  • Billing data.
  • Services:
    • Shared hosting provided by Plesk 8.x - 17.8 for Windows and Linux.
    • DNS hosting.

Shared Hosting

You can transfer data from source nodes to service nodes managed by Odin Automation or attach source nodes with Plesk 17.x to Odin Automation using the takeover migration mode. Takeover is available only for hosting servers running Plesk 17.5 and Plesk 17.8.

The following table explains the difference between migration and takeover.

Migration

Takeover

Data transfer

All data are transferred from source servers to Odin Automation:

  • Business-related data such as customer and billing information.
  • Settings of hosting services.

Note: After performing a full migration in the production mode, subscriptions in the source system are suspended and customers can no longer use them. No data are deleted from the source servers during migration.

All shared hosting data remain on the source servers, all services on the source servers continue to operate as usual, and the source servers are connected to the WebHosting Plesk Module of Odin Automation.

Shared hosting accounts and subscriptions are created in Odin Automation, a source server with subscriptions’ data is registered as a service node in WebHosting Plesk Module, and accounts and subscriptions are linked to the data on the connected source server.

Note: After performing a takeover migration from OBAS, subscriptions in the source system are put on hold, that is, they are not billed and customers can no longer use them. If you activate those subscriptions in OBAS, then some management issues might occur with the server that was taken over.

Reuse of existing servers

To perform migration, additional servers are needed to act as new service nodes.

Source servers can be decommissioned after migration is completed.

No additional servers are needed.

Source servers cannot be decommissioned as they are still in use.

Downtime during migration

Migration can take a significant time to complete, and there can be downtime during migration.

There is no downtime during the takeover process, and the whole process takes less time.

With takeover, you can avoid data transfer and possible issues related to it.

Transfer of server settings and applications

All server settings and configurations of services such as firewall, ModSecurity, Fail2Ban, and others are not transferred. For this reason, you will need to reconfigure all such services on the new nodes after migration.

No changes to hosting settings or content are made, so there is no need to reconfigure any settings or services on the source servers after the takeover.

After migration, websites created with Web Presence Builder (or SiteBuilder) will continue to operate, but will not be manageable through Web Presence Builder.

All websites created with Web Presence Builder will remain operable and users will be able to manage them through Web Presence Builder as usual.

Resource records in the DNS zones of websites are created based on the IP address of the WebHosting Plesk service node to which websites were migrated. Depending on the services associated with the migrated sites, the NS, A, MX, and CNAME records are created in the zones. All other types of records containing custom values are not created in the zones.

Resource records in the DNS zones of websites are re-created in the DNS zone of Odin Automation.

Available migration modes

Test migration without content, test migration with content, and production migration modes are available.

We recommend running migration in the production mode after you have run it in the test with content mode.

In the production mode, subscriptions are migrated if they were not previously migrated in the test mode. After that, a billing system is switched from the source system to Odin Automation, and DNS forwarding is configured.

Only production migration is available for the takeover migration.

DNS Hosting

There is an option to migrate domains from OBAS for which only DNS hosting is configured. Domains hosted locally on the source system will be transferred to Odin Automation and will be managed by it. Domains hosted outside the source system will be registered in Odin Automation, but will not be managed by it. During migration, the source DNS servers and OBAS SSH-managed name servers are configured directly to use forward zones for the migrated domains, to point at the DNS servers used by Odin Automation.

For all domains that have domain registration subscriptions configured in OBAS, separate DNS hosting subscriptions will be created in Billing and charged additionally. If domain registration subscriptions are not in the Active or Graced state, during migration planning, you will be prompted to include such domains in hosting subscriptions without creating additional domain subscriptions.

If you are migrating domains associated with the website hosting service in a full migration mode (as opposed to takeover), the corresponding DNS zone records will be created by the services to which the domains are migrated, for example, the WebHosting Plesk module.

During a takeover migration, all resource records are migrated except for NAPTR resource records from OBAS, and PTR and DS records from Plesk installations. If there are NAPTR, PTR, and DS records in the DNS zones of source domains, then you need to migrate those records manually.

Which Objects Are Transferred and Which Are Not

Which Objects Are Transferred

  • User accounts and subscriptions. During migration, shared hosting subscriptions are converted into hosting subscriptions in Odin Automation, and websites are moved to hosting service nodes managed by Odin Automation.
  • Web hosting objects: webspaces, websites, mailboxes, databases, and applications. 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 Odin Automation.
    • 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 Odin Automation. After migration of websites to Odin Automation, they will continue using the same databases.
  • DNS hosting.
    • Domains with shared hosting. During the migration of such domains from OBAS, domain subscriptions and hosting subscriptions are created in Odin Automation.
    • (Only for full migration) Under a hosting subscription, webspaces and websites are created in the WebHosting Plesk module, and website content is transferred. In this configuration, DNS records are not transferred because IP addresses might change during migration and the WebHosting Plesk module creates all the necessary DNS records. During the migration of DNS hosting subscriptions, you have the option to convert a source subscription into two subscriptions in Odin Automation: so as to charge separately for domain hosting and shared hosting. To have two separate subscriptions, during the migration planning, you need to assign a service plan to a domain. In this case, in addition to creating a hosting subscription, a domain subscription will be created. For a domain subscription, billing information, creation date, and expiration date will be taken from a hosting subscription.
    • Domains without web hosting. For such domains, DNS hosting subscriptions are created in Odin Automation and the following types of resource records are migrated: A, AAAA, CNAME, MX, SRV, and TXT. For a domain subscription, billing information, creation date, and expiration date will be taken from a source subscription. If there was no DNS hosting subscription for a domain, the current date is set as the creation date, the subscription period is taken from the target service plan (the minimal period is selected), and the expiration date is set based on the following formula: creation date + selected subscription period.

      Note: To circumvent the DNS propagation delay that will occur after migration of domains in the production mode (and that would render the migrated websites temporarily unavailable to visitors), the DNS servers responsible for the migrated domains are reconfigured to forward DNS queries to the name servers of Odin Automation.

  • Billing.
    • Payment methods supported by Odin Automation (information about banking accounts and credit cards that are in the "OK" status).
    • Information about subscription start and expiration dates, subscription periods.
    • Billing period.
    • Information about accounts (names, telephone numbers, addresses).
    • Account balance.
    • Information about resellers.

Known Limitations

  • DNS hosting.
    • DNS registrar settings, plugins, and credentials to registrar APIs are not migrated. For this reason, you need to configure domain registrar plugins and domain service plans in Odin Automation before migration. After migration, you can enable users to manage the domain registration settings from Odin Automation, as described in the article at https://kb.cloudblue.com/en/130651.
    • For a list of domain registrars supported by Odin Automation, refer to Provider's Guide > Adding Domain Registrars.
    • (Applicable only to full migration of shared hosting from OBAS) For domains connected to shared hosting accounts, custom DNS records are not migrated. If there were custom DNS records on the source platform, users will have to recreate them manually after migration.
  • Service plans are not migrated. You need to configure service templates and service plans in Odin Automation according to your needs and use them during migration planning.
  • Accounts and subscriptions.
    • User accounts and mailboxes whose passwords contain an ampersand (&) cannot be migrated from Plesk 11.5 and earlier.
    • Resellers can only be migrated as hosting customers and only if they have their own hosting subscriptions. After migration, you can convert customers back to resellers by assigning reseller service plans to them.
    • All customers of resellers in OBAS will become the provider's customers in Odin Automation. After migration, you can move customers back to their resellers by using the option Transfer to Another Vendor in Billing.
    • Inactive OBAS subscriptions are not migrated. Before starting migration, you need to activate all the subscriptions that you want to migrate and that are not in the active status.
    • All accounts are migrated as "personal accounts". After migration, you can convert accounts back to "business accounts" by using the option Convert to Company Account in Billing.
  • Billing.
    • Billing history (previous orders, documents, and paid invoices) is not migrated.
    • Transactions history and other billing-related information and settings are not transferred. For this reason, you might want to export the transactions history to an Excel spreadsheet for future reference.
    • During the migration of subscriptions, if a suitable subscription term was not found in Odin Automation, then the first suitable subscription term under the service plan is used.


      (Only for full migration) If you are performing a test migration of subscriptions, the Billing component of Odin Automation will not bill the users of migrated subscriptions. They will be billed only after subscriptions are transferred in the production mode:

      • (Only for full migration) After performing a test migration, the status of source subscriptions remains unchanged, and it is switched to the "ordered" status in Odin Automation.
      • (For full migration and takeover) After performing a production migration, subscriptions in the source OBAS system are put on hold, and the migrated subscriptions in Odin Automation are switched to the "active" status, that is, the users of subscriptions start being charged. The billing system at the source platform is switched off, and Billing is switched on.
  • Shared hosting (applicable only to full migration).
    • 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.
    • The passwords of additional FTP user accounts, web users, and protected directory users are not migrated. You can set new passwords for such accounts after migration.
    • Web users cannot be migrated from Plesk 17.8 due to XML-API limitations.
    • 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.
    • The history of web and mail statistics is not migrated.
    • Migration of subscriptions with shared IPv6 addresses is not supported. Such subscriptions will be migrated without IPv6 addresses.
    • A list of preferred website index files in the document root is not migrated. For this reason, after migration, we recommend that you log in to the Plesk-managed web hosting service node as administrator and adjust web server settings (in Provider Panel > Services > WebHosting Plesk > Websites tab > as Administrator (in the Manage in Hosting Panel column) > Web Server Settings, or Apache and Nginx Settings, or IIS Settings).
    • Cron jobs for Plesk websites are not migrated.
    • Mail content for mail servers that do not support the IMAP protocol (such as Mail Enable) is not migrated.
    • When migrating from Plesk 8 and 9, only one auto-reply configuration is migrated per each mail account.
    • After migration, customers will no longer be able to manage email aliases from Customer Panel, although aliases will remain operable.
    • During the migration of mailboxes from Windows-based platforms, spam filter settings are not migrated.
    • Migration of databases from Microsoft SQL Server 2000 is not supported.
    • 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.
    • Website backups are not migrated.
    • For Plesk 8.6, 9.x, if there are two identical domain names with the same name, but one is with the “www” prefix, the domain with the "www" prefix is not migrated.
    • Migration of ColdFusion, Tomcat, and MIVA third-party Plesk components is not supported.
    • All server settings and configurations of server-wide services such as firewall, ModSecurity, Fail2Ban, and others are not transferred. For this reason, you will need to reconfigure all such services on the new nodes after migration.
    • (For full migration and takeover) During the migration of mail accounts from Windows-based servers, mail forwarding configurations that refer to email addresses containing non-UTF symbols will not be migrated.
    • (For full migration and takeover) DNS forwarding is not configured for wildcard subdomains in production migration (OBAS with Plesk).
    • Inactive add-on domains and subdomains that might be present under Plesk Client and Plesk Domain subscriptions are migrated as active.
    • SSI and Microsoft Web Deploy settings are not migrated.
  • Web Presence Builder (SiteBuilder) sites.
    • After migration, websites created with Web Presence Builder (or SiteBuilder) will continue to operate, but will not be manageable through Web Presence Builder.
  • Application hosting.
    • 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.
    • (Only for full migration) During migration, coinciding database names and database user names may be changed to avoid conflicts. Migration tools automatically configure a limited set of applications (Drupal, Joomla, Magento, Prestashop, and WordPress) to use the new database names and database users. You will need to manually update the settings of all other APS applications that use databases. After renaming, the new database and database user names will be shown in Provider Panel > System > Migration Manager > Migration Projects > Completed tab > migration project name > Summary tab. Users will need to edit the configuration files of their applications: correct the database names and database user names.
  • Dedicated hosting is not supported yet.
  • SSL hosting is not supported yet.

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