Moving to Plesk Automation 11.5

Last updated: 2 June 2015

Contents

About This Document

4

Introduction

5

Preparing for the Move

7

1. Install the PA Moving Tool ... 8

2. Install Mail Sync Software (Windows Servers) ... 9

3. Configuring Firewalls ... 10

4. Prepare Source Servers ... 12

5. Prepare Service Nodes ... 13

Register Service Nodes in PA ... 15

Check Disk Space on Service Nodes ... 15

Install MySQL on IIS Web Server Nodes (Windows Servers) ... 16

Install Server Side Includes (Windows Servers) ... 17

6. (Optional) Create Reverse DNS Zones ... 17

7. (Optional) Prepare for Assimilating SmarterMail Servers ... 17

8. (Optional) Prepare for Assimilating Database Servers ... 19

Transfer Scenario for Plesk 8.6 and Later

21

1. Configure the Tool ... 24

2. Import Resellers to PA ... 28

3. Import Plans to PA... 28

4. Generate a Transfer List ... 30

5. Associate Subscriptions with Plans ... 33

6. Check for Possible Conflicts ... 34

7. Install MySQL on Target IIS Nodes ... 35

8. Run Transfer ... 36

9. Redirect DNS to the New Servers ... 36

10. Verify the Transferred Data ... 36

11. Finalize the Synchronization of Content ... 37

Transfer Scenario for Expand 2.3.3

38

2. Import Plans to PA... 40

3. Configure the Tool ... 41

4. Generate a Transfer List ... 45

5. Associate Subscriptions with Plans ... 47

6. Check for Possible Conflicts ... 48

7. Run Transfer ... 49

Transfer Scenario for H-Sphere 3.5 and Later

51

2. Configure the Tool ... 57

3. Generate a Transfer List ... 59

4. Import Resellers to PA ... 61

5. Associate Subscriptions from H-Sphere with Plans in PA ... 62

6. Perform the Migration ... 63

7. Set Up DNS Forwarding ... 63

8. Verify the Transferred Data ... 64

Transfer Scenario for PBAS

65

2. Connect PA to PBAS ... 68

3. Generate the Transfer Data and Configuration Files ... 70

4. Configure the Tool ... 72

5. Check for Possible Conflicts ... 73

6. Install MySQL on IIS Web Server Nodes (Windows Servers) ... 74

7. Run Transfer ... 75

8. Finalize Transfer ... 75

Transfer Scenario for Helm 3

77

2. Configure the Tool ... 82

3. Import Resellers to PA ... 84

4. Import Plans to PA... 85

5. Generate a Transfer List ... 85

6. Associate Subscriptions from Helm with Plans in PA ... 87

7. Check for Possible Conflicts ... 88

8. Run Transfer ... 89

9. Redirect DNS to the New Servers ... 90

10. Verify the Transferred Data ... 90

11. Finalize the Synchronization of Content ... 91

Transfer Scenario for Helm 4.2.2

92

2. Configure the Tool ... 96

3. Import Resellers to PA ... 98

4. Import Plans to PA... 99

5. Generate a Transfer List ... 100

6. Associate Subscriptions from Helm with Plans in PA ... 102

7. Check for Possible Conflicts ... 103

8. Run Transfer ... 104

9. Redirect DNS to the New Servers ... 105

10. Verify the Transferred Data ... 105

11. Finalize the Synchronization of Content ... 106

Troubleshooting

107

This document describes how to move from a number of independent servers controlled by some hosting panels to a multi-server environment controlled by Plesk Automation (hereafter referred to as PA).

The document is intended for administrators who are considering moving their hosting servers under the PA control and are willing to gain all benefits of centralized server management.

C

1

Currently, a large number of hosting providers use control panels like Plesk as a means to manage web hosting on a single server. Typically, such servers are administered separately, so server maintenance costs grow with each new added server. To reduce the costs and simplify server maintenance, we offer the providers to transition their existing infrastructure to a multi-server environment managed from a single web interface called Plesk Automation (PA).

PA is a web hosting control panel where one central server (management node) controls an arbitrary number of other servers with various roles - web, mail, DNS, and so on. In terms of PA, these controlled servers are called service nodes. When a customer subscribes to a web hosting plan, PA allocates all the necessary resources on service nodes and links these resources to the customer’s account. For example, when a customer subscribes to a shared web hosting plan, PA creates a webspace for the customer on one of the available web server nodes. If the subscription also

includes mail services, PA creates mailboxes for the customer on one of the mail server nodes.

Note: This document assumes you already have a working PA installation. For information about how to install PA, refer to the Plesk Automation: Deployment Guide.

Moving to PA

Moving to PA involves transferring of hosting data from existing servers to PA service nodes. All business objects (service plans, customer and reseller accounts, and other) are transferred from the servers to the PA management node. All subscriptions, websites and mailboxes are relocated to registered PA service nodes.

When migrating from Plesk or Expand, you also have the option to keep existing SmarterMail mail servers and assimilate them in a PA installation.

Supported Source Platforms

The following source platforms are supported:  Plesk 8.6 and later

 Plesk Expand 2.3.3

 Parallels H-Sphere 3.5 and later

 Parallels Business Automation Standard 4.3.1-12 and later  Parallels Helm 3.

 Parallels Helm 4.2.2

C

2

Prerequisites

You should perform the following preparation steps before performing the move: 1. Install the moving tool (on page 8).

To perform your move to PA, you should use a command-line tool called ppa-transfer, which is available from the Parallels website.

2. Install mail sync software (Windows servers) (on page 8).

This step is required only if you perform the move from Windows-based Panel servers. Without this software, the tool will be unable to transfer mail from such servers.

3. Open ports in firewalls (on page 10).

To ensure that the data transfer is possible, configure the firewalls on the source and destination servers to allow connections on the necessary ports. On Windows-based source servers, also make sure that the administrative shares (admin$, c$, d$) exist.

4. Prepare the source servers (on page 12).

Carry out several checks and install the rsync software on Windows-based nodes. 5. Prepare the destination service nodes (on page 13).

Add the required number of servers to PA and install additional software. Once the preparation is finished, you can start the data transfer.

In this chapter:

1. Install the PA Moving Tool ... 8

2. Install Mail Sync Software (Windows Servers) ... 8

3. Configuring Firewalls ... 10

4. Prepare Source Servers ... 12

5. Prepare Service Nodes ... 13

6. (Optional) Create Reverse DNS Zones ... 17

7. (Optional) Prepare for Assimilating SmarterMail Servers ... 17

8. (Optional) Prepare for Assimilating Database Servers ... 19

C

3

1. Install the PA Moving Tool

We strongly recommend that you install the tool on the management node. However, if needed, you can run the tool on any server in your network that meets the following requirements:

 CentOS 5.x/6.x or Red Hat Enterprise Linux 5.x/6.x is installed on the server.

 The server is able to connect to your hosting servers and the PA management node.



To install the tool on a server:

1. Log in to your server as root. 2. Download the installation script:

wget http://autoinstall.plesk.com/panel-migrator/installer.sh

3. Make installer.sh executable: chmod +x installer.sh 4. Install the tool by running the script:

./installer.sh

After you complete this step, the tool will be ready for operation.

The tool is automatically updated every time you run it.

Tuning the Migration Performance

By default, PA restarts Apache service on PA Apache service nodes after every change that requires a restart. There are several such changes during the transfer of a single

subscription. If the PA Apache service node carries many sites, each restart of the Apache service may take up to a minute. For example, if you transfer 10 subscriptions to a single PA Apache service node, Apache restart takes 30 seconds, and this happens 3 times during the transfer of each subscription. In this case, migration takes additional 15 minutes just to restart the Apache service.

To reduce the migration time, you can do the following: set PA’s apache-restart-interval setting to a high value before transfer, run the transfer, restore the original Apache restart interval, and then restart Apache on all Apache service nodes.

2. Install Mail Sync Software (Windows

Servers)

Important: This step is required if the source mail server on your Plesk for Windows supports IMAP. By default, the support for IMAP is turned on in all versions of Plesk for Windows starting with Plesk 9. If you use an earlier Plesk version or if you intentionally turned off the support for IMAP, skip this step.

The PA moving tool transfers mail services from Windows servers using a third-party utility called imapsync. Therefore, before transferring data from Windows servers, you should install imapsync on the same server where you installed the PA moving tool. If you are planning to assimilate a single SmarterMail server, then you do not need to install imapsync.



To install imapsync on CentOS 5, use the PA moving tool:

ppa-transfer install-imapsync



To install imapsync on RHEL 5, follow the instructions below:

1. Install EPEL repository by running the following command: On 32-bit OSes: rpm -ihv http://dl.fedoraproject.org/pub/epel/5/i386/epel-release-5-4.noarch.rpm On 64-bit OSes: rpm -ihv http://dl.fedoraproject.org/pub/epel/5/x86_64/epel-release-5-4.noarch.rpm

2. Install imapsync from the EPEL repository: yum install imapsync



To install imapsync on CentOS 6 or RHEL 6, follow the instructions below:

1. Install EPEL repository by running the following command: On 32-bit OSes: rpm -ihv http://dl.fedoraproject.org/pub/epel/6/i386/epel-release-6-8.noarch.rpm On 64-bit OSes: rpm -ihv http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm

2. For RHEL 6, install the “perl-File-Copy-Recursive” package from the CentOS 6 repository:

# rpm -ihv

http://mirror.centos.org/centos/6/os/i386/Packages/perl-File-Copy-Recursive-0.38-4.el6.noarch.rpm

3. Configuring Firewalls

If a source or destination server is behind a firewall, you need to properly configure the firewall to allow the migration data exchange.

The following ports must be opened on the source servers.

Source platform Services and ports

Linux-based servers running Plesk SSH connections  TCP port 22 Plesk API

 TCP port 8443 Windows-based servers running Plesk Files and Printers sharing

 TCP ports: 135, 139, 445  UDP ports: 137, 138 Microsoft SQL server

 TCP ports: 1433 (if using the default instance)

 UDP ports: 1434

 TCP ports: all, or manually selected (if using a named instance)

rsync

 TCP ports: 873 Plesk API

 TCP ports: 8443 POP3 and IMAP

 TCP ports: 110, 143 Windows-based servers operating as

Plesk Expand centralized mail servers

Files and Printers sharing  TCP ports: 135, 139, 445  UDP ports: 137, 138 Plesk API

 TCP ports: 8443 POP3 and IMAP

Windows-based servers operating as Plesk Expand centralized database servers

Microsoft SQL Server

 TCP ports: 1433 (if using the default instance)

 UDP ports: 1434

 TCP ports: all, or manually selected (if using a named instance)

MySQL

4. Prepare Source Servers

The preparation of source servers for transfer consists of two main steps: checking that the source servers meet the transfer requirements and installing the rsync software (only for Windows servers).

Preliminary Checking

Before you start the transfer, perform the following checks on your source servers: 1. Make sure that your source servers are capable of working as slave DNS servers. To

check this, you can:

1. Create a sample domain on your source server.

2. Select the source server’s DNS server as the slave DNS server for the domain’s zone. 3. Ensure that changes in the zone are successfully propagated from the master DNS

server to your slave DNS server.

2. Make sure your source servers meet the following disk space requirements:  At least 1 GB of free disk space.

 Additional free disk space for storing dumps of user databases. A dump may be several times larger in size than the original database.

Installing the rsync Software (Windows Servers)

To transfer data from Windows-based servers, you need to install the rsync software on them. When migrating from Expand, Helm 3, and Plesk for Windows, rsync is configured automatically.



To install and configure the rsync software on the source servers:

1. Download the installation file cwRsyncServer_4.0.5_Installer.zip from

http://autoinstall.plesk.com/panel-migrator/cwRsyncServer_4.0.5_Installer.zip. 2. Unpack the file and install rsync following the installation instructions.

Important: You must specify a user account with administrator’s privileges during installation.

3. Update the rsync configuration file rsyncd.conf with the strings given below. The file is located in the rsync installation directory (C:\Program Files\ICW by default)

uid = 0 gid = 0

hosts allow = <target_node1_IP_address>, <target_node2_IP_address>, ...

log file = rsyncd.log [vhosts]

read only = true

transfer logging = yes where

<target_node1_IP_address>, <target_node2_IP_address>, ... are the IP addresses of the Windows-based service nodes.

Important: If virtual hosts in your Plesk installation are not located in the default directory, change the value of the path variable:

1. Obtain the right path from the Windows registry: HKLM\SOFTWARE\PLESK\PSA Config\Config\HTTPD_VHOSTS_D for 32-bit systems or

HKLM\SOFTWARE\Wow6432Node\PLESK\PSA Config\Config\HTTPD_VHOSTS_D for 64-bit systems.

2. Update the value of the path variable with the path from the registry. Note that you should convert the path to the Cygwin format. For example, if your virtual hosts are located at D:\home\plesk_vhosts, the resulting path is

/cygdrive/d/home/plesk_vhosts

4. Create the C:\migrator directory and update the rsync configuration file rsyncd.conf with the strings given below.

[migrator]

path = /cygdrive/c/migrator read only = true

transfer logging = yes

5. Configure your firewall to allow inbound connections from target Windows nodes to the port 873.

6. Start the rsync service on behalf of the Windows administrator: net start RsyncServer

After installing and configuring rsync, go to the service settings (Services > Log On tab), and make sure that administrator’s username and password are specified, or Local system account is selected. Restart the service after changing the user.

5. Prepare Service Nodes

Before starting the transfer, you should prepare your PA service nodes for this. These service nodes must be a complete replacement for your source hosting servers: They must provide all the services provided by the source servers.

Example 1

For example, you want to migrate from two Plesk servers: one for Windows and one for Linux. To correctly prepare for the transfer, you should:

1. Prepare two clean servers: one with installed Linux and one with installed Windows operating system.

2. Register both servers in PA:

 Linux server as the node with the Apache web server / Postfix mail server / MySQL database server role.

3. Install MySQL on the Windows service node. 4. Install SSI on the Windows service node.

5. Prepare two clean Linux servers (for the DNS service). 6. Register these servers as nodes with the DNS server role.

Example 2

For example, you want to migrate from two Plesk for Windows servers. The migration should be performed on two separate Windows service nodes. To correctly prepare for the transfer, you should:

1. Prepare two clean Windows servers (replacement for your existing servers) and one clean Linux server (for the mail service).

2. Register Windows servers in PA as nodes with the IIS web server / MS SQL Server 2008 database server role.

3. Register Linux server as the node with the Postfix mail server role. 4. Install MySQL on the Windows service nodes.

5. Install SSI on the Windows service nodes.

6. Prepare two clean Linux servers (for the DNS service). 7. Register these servers as nodes with the DNS server role.

Example 3

For example, you want to migrate from Expand that controls two Plesk servers: one for Windows and one for Linux. To correctly prepare for the transfer, you should:

1. Prepare two clean servers: one with installed Linux and one with installed Windows operating systems.

2. Register both servers in PA:

 Windows server as the node with the IIS web server / MS SQL Server 2008 database server role.

 Linux server as the node with the Apache web server / Postfix mail server / MySQL database server role.

3. Install MySQL on the Windows service node. 4. Install SSI on the Windows service node.

Example 4

For example, you want to migrate from Expand that controls two Plesk for Windows servers without the mail service. The migration must be performed on two separate Windows service nodes. To correctly prepare for the transfer, you should:

1. Prepare two clean Windows servers (replacement for your existing servers) and one clean Linux server (for the mail service).

2. Register Windows servers in PA as nodes with the IIS web server / MS SQL Server 2008 database server role.

3. Register Linux server as the node with the Postfix mail server role. 4. Install MySQL on the Windows service nodes.

5. Install SSI on the Windows service nodes.

6. Prepare two clean Linux servers (for the DNS service). 7. Register these servers as nodes with the DNS server role.

Next in this section:

Register Service Nodes in PA ... 15

Check Disk Space on Service Nodes ... 15

Install MySQL on IIS Web Server Nodes (Windows Servers) ... 16

Install Server Side Includes (Windows Servers) ... 17

Register Service Nodes in PA

The transfer scenario assumes that you already have a working PA environment with service nodes that can be used as a replacement for your existing servers. Therefore, before

performing the data transfer, you should register these service nodes.

For instructions on how to register service nodes in PA, refer to the Plesk Automation: Deployment Guide, section Adding Service Nodes.

Check Disk Space on Service Nodes

Install MySQL on IIS Web Server Nodes (Windows Servers)



To add support for MySQL on the target IIS web server node:

1. Obtain the MySQL 5.1 distribution package and install it following the installation instructions.

2. Add the MySQL installation directory to the PATH environment variable.

3. Restart the PEM service by running the following commands on behalf of the Windows administrator:

Install Server Side Includes (Windows Servers)

By default, support for Server Side Includes (SSI) is not enabled on Windows servers. Therefore, if SSI was enabled on your source servers, you must turn on support for SSI on the PA Windows service nodes as well.



To turn on support for SSI on a Windows service node:

1. Connect to the node over RDP. 2. Log in to the node as Administrator.

3. Add the SSI role to the server in Server Manager > Roles > Web Server (IIS) > Add Role Services > Server Side Includes.

6. (Optional) Create Reverse DNS Zones

A reverse DNS lookup process (when a client looks up a computer name based on its address) is essential to a large number of Internet services. The processing of reverse requests is based on reverse DNS zones that store the information about IP addresses and corresponding domain names. This information is represented by PTR records contained within a corresponding reverse DNS zone.

By default, the reverse DNS lookups are disabled in PA. To enable them, you must create one or more reverse DNS zones according to your network configuration. You can do this in Administration Panel > Services > DNS Zones > DNS tab > Reverse DNS Zones. Note that you do not need to create PTR records. PA will automatically create them for all hosted domains, once you have created a suitable reverse DNS zone.

7. (Optional) Prepare for Assimilating

SmarterMail Servers

The information provided in this article is applicable only to those who migrate from Plesk 9.5 or later, or Expand 2.3, and who use Windows-based SmarterMail servers.

Starting from PA 11.5, you have the option to keep existing SmarterMail mail servers in production and connect them to your PA installation. In this case, mailboxes will remain on the SmarterMail servers and PA will control the servers just like any other service nodes. The existing SmarterMail servers can be used for serving new domains and domains transferred from Plesk or Plesk Expand.

Compared to the usual data transfer process, this assimilation offers the following advantages:

 There is no need to buy new hardware for a new SmarterMail server.

 Zero downtime for the mail services. No additional mail synchronization is required after moving. However, when migrating SmarterMail in transfer mode, the downtime can also be significantly reduced by setting low TTL values in DNS zones before migration.

 When using external DNS servers (not controlled by the source panel), you do not have to change mail DNS records.

There are also several disadvantages in the assimilation:

 You should be very careful when using the source panel after domains are moved to PA: Any changes to the mail settings of domains in the source panel might disrupt the operation of mail services.

 Assimilation cannot be reverted. Once a domain is in PA, you cannot transfer it back to the old panel. For this reason, SmarterMail assimilation must not be used when performing test migrations.

In general, we recommend performing a transfer instead of assimilation, if you can obtain new hardware and a SmarterMail license.

Supported Software Versions

 SmarterMail 8-11. Versions earlier than 8 are not supported.  Plesk 9.5, 10.4, 11.0, 11.5.

 Parallels Expand 2.3.2 with centralized mail based on Plesk 9.5, 10.4, 11.0, 11.5.

Prerequisites

1. Connect the existing SmarterMail server to PA as a regular service node. Refer to Deployment Guide to learn how to do it: http://download1.parallels.com/ppa/11.5/docs/en-US/online/ppa_deployment_guide/71931.htm.

2. Configure a service template for SmarterMail migration.

You need to configure a service template that includes the Mail Service resource that is provisioned to a SmarterMail node. When creating service template with the Add Shared Hosting Template wizard, set Mail Hosting to SmarterMail-based.

Refer to Operations Guide to learn how to create a new service template:

http://download1.parallels.com/ppa/11.5/docs/en-US/online/ppa_operations_guide/70934.htm.

3. Check whether SmarterMail and the newly created service template are properly configured:

a Based on the service template, create in PA a test subscription with a webspace and mail resource.

b Make sure that there are no failed tasks related to the subscription in PA’s task manager (in Operations > Tasks).

c Log in to the hosting panel (Operations > Subscriptions > subscription name > Managed By > Login as Customer), and try creating a mailbox (Mail tab > Create Email Address).

e (Optional) Make sure that this mailbox can receive new messages and that you can send new messages from that email address.

Running the Transfer

Run the data transfer as described in the following chapters. During the transfer, you will not need to use any special settings or additional configuration steps to ensure that the

mailboxes will not be transferred.

8. (Optional) Prepare for Assimilating

Database Servers

You have the option to keep existing database servers in production and connect them to your PA installation.

In this case, databases and database users will remain on the existing database servers and PA will control the servers like any other external database servers. The existing database servers can be used for serving new domains and domains transferred from other hosting platforms.

Compared to the usual data transfer process, this assimilation offers the following advantages:

 There is no need to buy new hardware.

 There is no need to reconfigure existing customers’ applications that use databases.  In case of Microsoft SQL Server (or other commercial solutions) there is no need to buy

additional licenses.

There are also several disadvantages in the assimilation:

 You should be very careful when using the source panel after domains are moved to PA: for example, when you remove a domain from the source panel, databases will be removed too.

 Two instances of the same web application (on the source and on the target server) use the same databases, which may lead to conflicts. You should consider that and be careful when testing migrated web applications.

In general, we recommend performing a transfer instead of assimilation, if you can obtain new hardware, licenses, and reconfigure web applications after migration.

Prerequisites

1. Connect existing database servers to PA as external database servers. To

do this, use the

Add Database Server wizard in Administration Panel > Infrastructure >

Database Servers.

When specifying database server administrator’s credentials, do not use “root” as the username.

2. Create resource types for these servers. To do this, go to

Products > Resources

> Add New Resource Type > Database Service, type a name, for example

“assimilated MySQL server”, select a database server type, and specify the

IP address and port of the external database server.

3. Configure service templates that use these resources. Refer to

Operations

Guide to learn how to create a new service template:

http://download1.parallels.com/ppa/11.5/docs/en-US/online/ppa_operations_guide/70934.htm

.

You can specify the resources when creating a service template with the wizard, or you can manually add the resources to any service template.

4. Check whether the service templates and external database servers are

properly configured:

a Based on a service template, create in PA a test subscription with a webspace and a database.

b Make sure that there are no failed tasks related to the subscription in PA’s task manager (in Operations > Tasks).

c Log in to the hosting panel (Operations > Subscriptions > subscription name > Managed By > Login as Customer), and try creating a database and a database user.

d (Optional) Make sure that you can log in to the external database server with new database user’s credentials, and that the database is present on the server.

Running the Transfer

Run the data transfer as described in the following chapters. During the transfer, you will not need to use any special settings or additional configuration steps to ensure that the

The transfer of hosting data requires you to have a working PA environment with service nodes that can be used as a replacement for your existing servers: All hosting data are transferred to particular PA nodes. Thus, all business objects such as plans, customer and reseller accounts are transferred to the PA management node.

Subscriptions from your existing servers are transferred to certain service nodes.

Performing the Data Transfer

The process of transferring hosting data consists of the following steps: 1. Configure the ppa-transfer tool.

The tool is configured with the help of a configuration file. It defines various communication parameters such as server IP addresses, the administrator’s credentials, and so on.

2. Import resellers to PA (on page 28).

The ppa-transfer tool does not fully automate the transfer of resellers to PA: It automatically transfers reseller accounts while you need to manually configure these accounts and reseller plans before transferring resellers’ customers and domains.

3. Import plans (templates) to PA (on page 28).

Service plans are not automatically registered in PA during transfer. Therefore, you should either create your plans in PA manually or use the ppa-transfer tool for this purpose.

4. Create a transfer list (on page 30).

A transfer list is a file that specifies what objects (plans, reseller accounts, and subscriptions) should be transferred to PA from source servers.

5. Associate subscriptions and plans (on page 33). Associate subscriptions with certain imported plans. 6. Check for possible conflicts and limitations (on page 34).

Before moving to PA, we strongly recommend that you perform a preliminary check for possible transfer conflicts. For example, two different service plans on different Panels may have the same name. Based on the check results, the tool generates a report with all found conflicts.

7. Install MySQL on target Windows-based IIS service nodes. 8. Run the transfer process (on page 36).

Once all preparation steps are completed, you can run the transfer. In this step, the tool transfers all subscriptions from your existing servers to registered PA service nodes.

9. Redirect DNS to the new servers (on page 36).

After DNS services are relocated to PA, you need to update all your NS records on the registrar’s DNS servers with the IP address of your PA DNS server.

C

4

10. Verify that the data were transferred correctly (on page 36).

The operability of web, mail, DNS, and FTP services for each transferred domain is checked.

11. Finalize the synchronization of content (on page 37).

Ensure that any changes to the content made by your customers during the transfer process are transferred as well.

12. (Optional) Create reverse DNS zones (on page 17).

As PA does not automatically create reverse DNS zones for used IP network addresses, this should be done manually.

In this chapter:

Multiple Webspaces in a Single

Subscription

In PA, several sites can be hosted either in one subscription, or in individual

subscriptions. By default, when transferring sites from Plesk 8 or 9, every domain of a user is transferred to a separate subscription. This results in domain owners having multiple subscriptions to manage, which is not very convenient. To avoid this

inconvenience, the migration tool provides the option to transfer all domains of a user into multiple webspaces under one subscription.

To use this option, you need to do the following:

1. Before starting a transfer, create in PA a service template that will provide enough web hosting and mail hosting resources. In service template properties (in Products > Service Templates > template name > Resources tab), set the following types of resources to unlimited or equal to the number of migrated sites: Apache Webspace, IIS Webspace, Postfix Mail, SmarterMail, and Subscription.

1. Configure the Tool

Since the ppa-transfer tool communicates with a number of servers, you should provide it with server IP addresses, administrators’ credentials, and other information. The tool is configured with the help of the config.ini file, which is not created by default. For your convenience, the directory /etc/ppa-migrator/ contains the

config.ini.plesks.template file which you can use as a basis for creating your own config.ini.



To configure the tool:

1. Create the config.ini file based on the template. For example: cp /etc/ppa-migrator/config.ini.plesks.template config.ini

2. Edit the config.ini file to configure the tool. The description of file sections is provided below.

The Structure of the Configuration File

The config.ini file consists of several sections of two types:

 Predefined. These sections contain information about your PA management node and various aspects of data transfer. The names of the sections [GLOBAL] and [ppa] are predefined by the tool and you should not change them.

 Custom. These sections contain information about your existing servers. You can use arbitrary names for such sections. For example, [plesk1], [plesk2], and so on.

Also, each section has a number of settings of two types:  Mandatory. You must define these settings.

 Optional. You do not have to define these settings. The value that will be assumed when you do not define a setting is specified in the configuration template file inside that setting’s description. That description also has a commented line with the setting and its default value: if you want to change the value, uncomment that line and change the value in it.

The meaning of each setting is described in the configuration template file.

Examples of the Configuration File

Example 1.

In this example, we are going to transfer data from three Panel servers (two on Linux and one on Windows).

[GLOBAL]

source-type: plesk

source-plesks: plesk1, plesk2, plesk3

[ppa] ip: 192.168.0.1 panel-username: admin panel-password: setup ssh-username: root ssh-auth-type: password ssh-password: 123qwe webmail-ip: 192.168.0.21 [plesk1] ip: 192.168.0.100 os: unix panel-username: admin panel-password: setup1 ssh-username: root ssh-auth-type: password ssh-password: 123qwe [plesk2] ip: 192.168.0.101 os: unix panel-username: admin panel-password: setup2 ssh-username: root ssh-auth-type: password ssh-password: 234wer [plesk3] ip: 192.168.0.102 os: windows panel-username: admin panel-password: setup3E windows-username: Administrator windows-password: 345ertYU

Example 2

In this example, we are going to transfer data from Panel server on Linux, and for security reasons, we do not want to reveal privileged user’s password in the config.ini file. Instead of using the password, we will set up the key-based authentication.

[GLOBAL]

[ppa] ip: 192.168.0.1 panel-username: admin panel-password: setup ssh-username: root ssh-auth-type: password ssh-password: 123qwe webmail-ip: 192.168.0.21 [plesk1] ip: 192.168.0.100 os: unix panel-username: admin panel-password: setup1 ssh-username: root ssh-auth-type: key ssh-key: /root/.ssh/id_rsa

Example 3

In this example, we are going to transfer data from Panel server on Linux, which uses an external PostgreSQL server to host user databases. That PostgreSQL server is registered in Panel using its IP v4 address (192.168.0.200).

Example 4

In this example, we are going to transfer domains from a Plesk 8 server on Linux to PPA subscriptions with multiple webspaces.

[GLOBAL] source-type: plesk source-plesks: plesk1 transfer-domains-to-subscription: same [ppa] ip: 192.168.0.1 panel-username: admin panel-password: setup ssh-username: root ssh-auth-type: password ssh-password: 123qwe webmail-ip: 192.168.0.21 [plesk1] ip: 192.168.0.100 os: unix panel-username: admin panel-password: setup1 ssh-username: root ssh-auth-type: password ssh-password: 123qwe

Example 5

In this example, we are going to transfer domains from a Plesk 11 server on Windows to PA, and assimilate an existing SmarterMail server.

2. Import Resellers to PA

The ppa-transfer tool has the following limitation: It allows you to transfer reseller accounts to PA but it does not automatically transfer reseller plans. Therefore, to seamlessly import existing reseller accounts from your servers, you should first manually create reseller plans in PA that correspond to the ones on your servers, and subscribe the resellers to these plans after the transfer. See the detailed instructions below.



To import resellers to PA:

1. Create reseller plans (templates) in PA that correspond to reseller plans (templates) in your hosting solution.

Learn how to do this in the Plesk Automation: Operations Guide, section Creating Reseller Service Templates.

2. Generate a transfer list file called migration-list, by issuing the following command: # ppa-transfer generate-migration-list config.ini

3. Edit the transfer list file migration-list (located in your session directory) to exclude reseller accounts that you do not want to transfer to PA. To exclude a certain account from transfer, comment out or delete the corresponding line from the list. The lines look like Reseller: <reseller’s username>.

4. Perform the transfer of reseller accounts to the PA management node by running the command:

# ppa-transfer import-resellers config.ini

All resellers that exist in your hosting solution will be transferred to PA. 5. Subscribe the transferred resellers to the newly created reseller plans.

Learn how to do this in the Plesk Automation: Operations Guide, section Subscribing Resellers to Templates.

6. Configure hosting service templates on behalf of the reseller.

Learn how to do this in the Plesk Automation: Operations Guide, section Creating Shared Hosting Templates.

3. Import Plans to PA

The ppa-transfer tool does not perform the transfer of service plans to PA. Therefore, you should do this manually.



To import plans to PA:

2. Configure subscription provisioning by assigning proper provisioning attributes to the templates.

4. Generate a Transfer List

A transfer list defines the list of objects (plans, reseller accounts, user accounts, and subscriptions) that should be transferred from source Panels to PA. The transfer list file can be automatically generated by the ppa-transfer tool. By default, after the

generation, it contains all objects that are present on source servers (see the example below).



To generate the transfer list, if you have not done this in step 2, run the

following command:

# ppa-transfer generate-migration-list config.ini

After you run the command, the tool will create the migration-list file in the session directory defined in your config.ini. You will need this file during further transfer steps.

Transfer List Structure

After generation, the list contains all subscriptions that exist on source Panels. In addition, the file contains plans, reseller and customer accounts to which the subscriptions are related.

The list comprises a number of sections - one section per each reseller. The sections are marked with a line Reseller: Reseller’s name.

Each section consists of a number of subsections - one subsection per each service plan of the reseller. These subsections are marked with a line Plan: Plan name. Note that plan names cannot contain the # symbol.

Each plan subsection contains a list of customer accounts subscribed to that plan, and the domain names of the customers’ subscriptions. Customer account names are marked with a line Customer: customer’s name.

By default, customer accounts are listed below the corresponding reseller accounts. You can move the customer account to other resellers, including the administrator, using the transfer list.

Each subscription must be assigned to a customer. By default, administrator’s subscriptions are assigned to a special customer called ppa-admin. Reseller’s subscriptions are assigned to a special customer called

ppa-<reseller_username>. If such customer accounts already exist in PA, the migration tool will transfer subscriptions without checking whether the subscriptions belong to those accounts.

Note: You can assign subscriptions to nonexistent customers. In such a case, the migration tool will create the corresponding customer accounts in PA (without any personal information prefilled) and will transfer subscriptions to them.

Note that your hosting plans are not grouped under a certain section: They go at the beginning of the file before the reseller sections. Depending on the source panel type, the initial content of the file may differ:

 If a source panel is Panel 10.x and later, the tool automatically determines

association between plans and subscriptions. Thus, each plan section contains the list of associated subscriptions. The only exceptions are custom subscriptions - subscriptions that are not associated with a certain plan. Custom subscriptions are placed outside of plan sections. Typically, all you need is to move custom

subscriptions to a certain plan section.

 If a source panel is Panel 9.x or earlier, the file will contain an unsorted list of all subscriptions and service plans (templates). You should associate subscriptions with the plans by moving them to corresponding plan sections.

An Example of the List

# The list of subscriptions

# These subscriptions must be moved to a section of a certain service plan. Otherwise, the tool will not start transfer.

Customer: ppa-admin admins-subscription1.tld Customer: bobs

customer1-subscription1.tld customer1-subscription2.tld

# Administrator’s service plans and subscriptions Plan: Gold hosting

Customer: ppa-admin admins-subscription2.tld Customer: jacks

customer2-subscription1.tld customer2-subscription2.tld Plan: Bronze hosting

Plan: Silver hosting # Resellers

Reseller: johns_123

# The subscriptions that are not assigned to a certain service plan. They must be moved to a section of a certain service plan of this reseller.

Customer: ppa-johns_123 notassigned1.tld

# Reseller’s service plans Plan: Unlimited

Customer: ppa-johns_123

# The subscriptions of this reseller reseller-subscription1.tld

reseller-subscription2.tld

# The customers of this reseller subscribed to this plan Customer: johndoe

Reseller: toms

# Reseller’s service plans Plan: Reseller Plan 2

# The customers of this reseller subscribed to this plan Customer: katie_23

5. Associate Subscriptions with Plans

In this step you should associate subscriptions that exist on your servers with certain service plans you have imported to PA in the previous step. This is done by adjusting the transfer list file.

As all subscriptions in PA should be associated with certain plans (templates), this step is obligatory for all hosting platforms:

 Panel 9.x and earlier do not support association between plans (templates) and subscription. Therefore, you should associate them before performing the data transfer.

 In Panel 10.x and later all subscriptions are associated with certain plans (these associations are automatically reflected in the file). The only exceptions are custom subscriptions - subscriptions that are not the instances of certain service plans. As PA does not support custom subscriptions, you need to associate them with certain plans using the transfer list.



To associate subscriptions with certain service plans, edit the transfer file.

The association is performed by placing the corresponding subscription line under a certain plan section, or placing a line describing a plan (Plan: <plan name>) above the lines describing subscriptions.

Note that the tool will not start the transfer until there are subscriptions which are not associated with plans. If you do not want to associate certain subscriptions with plans, comment out the corresponding lines or delete them.

Note: All plans from the list must exist in PA. Otherwise, the tool will be unable to complete the transfer.

For example, to associate the custom subscription admins-subscription.tld with the Gold hosting plan move the corresponding line under the plan section.

Before After

# Custom subscriptions Customer: ppa-admin admins-subscription.tld Plan: Gold hosting Customer: bob

customer1-subscription1.tld Plan: Silver hosting

Plan: Gold hosting Customer: ppa-admin admins-subscription.tld Customer: bob

6. Check for Possible Conflicts

Before performing a transfer, we strongly recommend that you perform a preliminary check for possible conflicts that can cause issues during the data transfer process or even make switching to PA impossible. Such a check is performed by the ppa-transfer tool and includes a number of checks concerning various aspects of hosting panels’ functionality. Below we describe the most important checks that may require your attention:

 Check for customer / reseller accounts with the same e-mails and contact names. There are three account parameters that the tools use to identify an account: username, e-mail, and contact name. Let us look closer at the system behavior when these parameters match for different accounts:

 Usernames, e-mails, and contact names are the same.

The system considers such accounts to represent the same person or company: Only one of them will be transferred to PA. The priority is given to the account from the panel that is listed first in the sources string of config.ini.

Accounts from other panels are ignored: Their subscriptions are also registered in PA, but these subscriptions become associated with the customer / reseller account which had the priority during the transfer. If you want each of such accounts to be transferred to PA, specify another e-mail and username for conflicting accounts.

 Usernames and contact names are the same, e-mails are different. The move to PA will be impossible until you specify another username for conflicting accounts.

 Usernames and e-mails are the same, contact names are different.

The move to PA will be impossible until you specify the same contact names (if these are the same persons) for conflicting accounts.

 E-mails are the same, usernames and contact names are different.

The move to PA will be impossible until you specify other e-mails for conflicting accounts.



To perform the preliminary check:

$ ppa-transfer check config.ini

Based on the check results, the tool generates a report. The report contains messages of two types:

 WARNING. These messages warn you about the potential issues that may affect your further work in PA but are not critical for the transfer process.

7. Install MySQL on Target IIS Nodes

While Plesk for Windows provides support for MySQL databases, IIS-based web server nodes in PA do not do that. This means that before transferring customer databases from Windows-based Plesk servers, you should first add support for MySQL to the target node.



To add support for MySQL on the target IIS web server node:

1. Obtain the MySQL 5.1 distribution package and install it following the

installation instructions.

2. Add the MySQL installation directory to the PATH environment variable.

3. Restart the PEM service by running the following commands on behalf

of the Windows administrator:

8. Run Transfer

Once all preparation steps are done, you can run the transfer process.



To run the transfer:

1. Issue the following command:

ppa-transfer transfer-accounts config.ini

The tool performs the transfer of your hosting data to certain service nodes. 2. Test the transferred domains:

ppa-transfer test-all config.ini--skip-dns-forwarding-test The test-all command helps you verify that the transferred domains are operating properly. However, it does not check whether mail can be sent and received. You should manually check that.

3. If any issues were found by the tool, resolve them and re-run the command in step 2 to verify they are resolved.

The tool does not require you to resolve all of these issues. You can resolve only the important ones.

Note that this command allows specifying a different transfer list, which can be useful when a transfer has failed for many domains, and you do not want to test these domains. In such a case, specify the latest list with successfully transferred domains, for example:

ppa-transfer test-all config.ini--skip-dns-forwarding-test--list-file migration-session/successful-subscriptions.1385955582.55

9. Redirect DNS to the New Servers

As the DNS service is relocated to the PA DNS server, you should update all your NS records on the registrar’s DNS server with the IP addresses of your PA DNS servers. Also, make sure that DNS propagation has ended. This means that you should wait for the period of time which is equal to the sum of TTL and SOA refresh interval.

10. Verify the Transferred Data



To check the operability of web, mail, DNS, and FTP services for each

transferred domain, issue the following command:

 Websites. It checks the main page and links to the same website (or relative links) located on the main page.

 DNS. It checks that all the main DNS records are present in the DNS zone of the domain and point to the correct server.

 Mail. For each migrated domain, it checks all mail accounts and the number of transferred email messages.

 User accounts. On behalf of system users, it tries to log in via FTP to each subscription at the destination server.

 Databases. It checks whether all databases are present on the destination server. After you run the command, the tool will report the results of the check. If all domains were transferred correctly, the report will show “All domains were transferred correctly.” Otherwise, it will show all detected issues and a short summary on the issues. For each issue that might need resolving, the tool will suggest a solution. After resolving all issues, we recommend that you restart the check.

11. Finalize the Synchronization of

Content



To complete the synchronization of content between the source and the

destination servers, do the following:

1. Copy the content that could be added by your customers during the transfer process from your source servers.

 To copy mail content:

ppa-transfer copy-mail-content config.ini  To copy website content:

ppa-transfer copy-content config.ini  To copy databases:

ppa-transfer copy-db-content config.ini

In this step, the tool will update the content of the transferred subscriptions with any changes that were made during the transfer. Note that the tool makes a full copy of databases (as opposed to mail and web content where only new content is copied) which may require significant time.

2. Check that the transfer completed successfully.

a Issue the command ppa-transfer test-all config.ini.

Transferring of hosting data from Plesk Expand 2.3.3 (hereafter referred to as Expand) requires you to have a working PA environment with service nodes that can be used as a replacement for your existing servers: All hosting data are transferred to particular PA nodes. Thus, all business objects such as plans, customer and reseller accounts are transferred to the PA management node. Subscriptions from your existing servers are transferred to certain service nodes.

Expand, as a multi-server solution, provides the support for two specific server types: central mail servers and central DNS servers. The services from these servers are transferred in the following way:

 Central mail servers.

Mailboxes and their content are relocated from such servers to a mail server node registered in PA.

 Central DNS servers.

DNS services are relocated to DNS servers registered in PA: They store all DNS zones from the Expand’s central DNS server. After the transfer, Expand’s DNS server starts to forward all requests to a PA’s master DNS server. This allows keeping all existing NS records on a registrar’s DNS server as is.

Performing the Data Transfer

The process of transferring hosting data consists of the following steps: 1. Import resellers to PA (on page 40).

Reseller accounts are not automatically transferred to PA: you should do this manually.

2. Import plans (templates) to PA (on page 40).

Service plans are not automatically registered in PA during transfer: you should do this manually.

3. Configure the ppa-transfer tool (on page 41).

The tool is configured with the help of a configuration file. This defines various communication parameters such as server IP addresses, the administrator’s credentials, and so on.

4. Create a transfer list (on page 45).

A transfer list is a file that specifies what objects (plans, reseller accounts, and subscriptions) should be transferred to PA from source servers.

5. Associate subscriptions and plans (on page 47). Associate subscriptions with certain imported plans.

C

5

6. Check for possible conflicts and limitations (on page 48).

Before moving to PA, we recommend that you perform a preliminary check for possible transfer conflicts. For example, two different service plans on different Panels may have the same name. Based on the check results, the tool generates a report with all found conflicts.

7. Run the transfer process (on page 49).

Once all preparation steps are completed, you can run the transfer. In this step, the tool transfers all subscriptions from your existing servers to registered PA service nodes.

In this chapter:

1. Import Resellers to PA

The ppa-transfer tool does not automatically transfer reseller accounts to PA. You should do this manually.

To import resellers to PA:

1. Create reseller plans (templates) in PA that correspond to reseller plans (templates) in your hosting solution.

Learn how to do this in the Plesk Automation: Operations Guide, section Creating Reseller Service Templates.

2. Create all reseller accounts you want to transfer as described in the Plesk Automation: Operations Guide, section Creating Reseller Accounts.

3. Subscribe the resellers you created in step 2 to the newly created reseller plans. Learn how to do this in the Plesk Automation: Operations Guide, section Subscribing Resellers to Templates.

4. Configure hosting service templates on behalf of the reseller.

Learn how to do this in the Plesk Automation: Operations Guide, section Creating Shared Hosting Templates.

2. Import Plans to PA

The ppa-transfer tool does not perform the transfer of service plans to PA. Therefore, you should do this manually. Note that this refers to all types of service plans: hosting plans, reseller plans, and hosting plans of your resellers.



To import hosting plans to PA:

1. Create service plans (templates) in PA that correspond to hosting plans in Expand. Learn how to do this in the Plesk Automation: Operations Guide, section Creating Shared Hosting Templates.

2. Configure subscription provisioning by assigning proper provisioning attributes to the templates.

The provisioning attribute is a tag that links a plan and nodes on which the services included into the plan should be set up. Learn more about attributes in the Plesk Automation: Operations Guide, chapter Customers and Resellers.



To import reseller plans to PA:

1. Create reseller plans (templates) in PA that correspond to reseller plans in Expand. Learn how to do this in the Plesk Automation: Operations Guide, section Creating Reseller Service Templates.



To import hosting plans of a certain reseller to PA:

1. Create service plans (templates) in PA that correspond to the hosting plans of this reseller in Expand. To do this, use the Add New Service Template button in Operations > Resellers > select a reseller > Subscriptions tab > Service templates.

2. Configure subscription provisioning by assigning proper provisioning attributes to the templates.

The provisioning attribute is a tag that links a plan and nodes on which the services included into the plan should be set up. Learn more about attributes in the Plesk Automation: Operations Guide, chapter Customers and Resellers.

3. Configure the Tool

Since the ppa-transfer tool communicates with a number of servers, you should provide it with server IP addresses, administrators’ credentials, and other information. The tool is configured with the help of the config.ini file, which is not created by default. For your convenience, the directory /etc/ppa-migrator/ contains the

config.ini.expand.template file that you can use as a basis for creating your own config.ini.

Important: We strongly recommend that you create a separate directory for each transfer operation and perform the transfer being in this directory.



To configure the tool:

1. Create the config.ini file based on the template. For example: cp /etc/ppa-migrator/config.ini.expand.template config.ini

2. Edit the config.ini file to configure the tool. The description of file sections is provided below.

The Structure of the Configuration File

The config.ini file consists of several sections of two types:

 Predefined. These sections contain information about your PA management node and various aspects of data transfer. The names of the sections [GLOBAL] and [ppa] are predefined by the tool and you should not change them. The [expand] section contains the information about your Expand server.

 Custom. These sections contain information about your existing servers. You can use arbitrary names for such sections. For example, [plesk1], [plesk2], and so on.

 Optional. You do not have to define these settings. The value that will be assumed when you do not define a setting is specified in the configuration template file inside that setting’s description. That description also has a commented line with the setting and its default value: if you want to change the value, uncomment that line and change the value in it.

The meaning of each setting is described in the configuration template file.

An Example of the Configuration File

Let us take a look at the example of the config.ini file.

Example 1

In this example, we are going to transfer data from Expand with the following servers connected: two Panel servers (one on Linux and one on Windows), one centralized mail server, and one centralized DNS server. The PA installation in this example is deployed with webmail on a separate service node with IP address 192.168.1.21. [GLOBAL]

source-type: expand

windows-username: Administrator windows-password: 234werTY [cm1] ip: 192.168.0.4 os: unix panel-username: admin panel-password: setup3 ssh-username: root ssh-auth-type: password ssh-password: 345ert [cd1] ip: 192.168.0.5 ssh-username: root ssh-auth-type: password ssh-password: 456rty

Example 2

In this example, we are going to transfer data from an Expand installation that has one Linux-based web hosting server, and one centralized Windows-based mail server running SmarterMail. The mail server will be assimilated.

panel-username: admin panel-password: setup

windows-username: Administrator windows-password: setup

4. Generate a Transfer List

A transfer list defines the list of objects (plans, reseller accounts, user accounts, and subscriptions) that should be transferred from source Panels to PA. The transfer list file can be automatically generated by the ppa-transfer tool. By default, after the

generation, it contains all objects that are present on source servers (see the example below).



To generate the transfer list, run the following command:

# ppa-transfer generate-migration-list config.ini

After you run the command, the tool will create the migration-list file in the session directory defined in your config.ini. You will need this file during further transfer steps.

Transfer List Structure

After generation, the list contains all subscriptions that exist on source Panels. In addition, the file contains plans, reseller and customer accounts to which the subscriptions are related.

The list comprises a number of sections - one section per each Expand reseller. The sections are marked with a line Reseller: Reseller’s name.

Each section consists of a number of subsections - one subsection per each service plan of the reseller. These subsections are marked with a line Plan: Plan name. Note that plan names cannot contain the # symbol.

Each plan subsection contains a list of customer accounts subscribed to that plan, and the domain names of the customers’ subscriptions. Customer account names are marked with a line Customer: customer’s name.

By default, customer accounts are listed below the corresponding reseller accounts. You can move the customer account to other resellers, including the administrator, using the transfer list.

Each subscription must be assigned to a customer. By default, administrator’s subscriptions are assigned to a special customer called ppa-admin. Reseller’s subscriptions are assigned to a special customer called

ppa-<reseller_username>. If such customer accounts already exist in PA, the migration tool will transfer subscriptions without checking whether the subscriptions belong to those accounts.

You can reassign all subscriptions (including the administrator’s and resellers’ subscriptions) to any customers using the transfer list.

Note that your hosting plans are not grouped under a certain section: They go at the beginning of the file before the reseller sections.

The tool automatically determines association between plans and subscriptions. Thus, each plan section contains the list of associated subscriptions. The only exceptions are custom subscriptions - subscriptions that are not associated with a certain plan.

Custom subscriptions are placed outside of plan sections. Typically, all you need is to move custom subscriptions to a certain plan section.

An Example of the List

# The list of subscriptions

# These subscriptions must be moved to a section of a certain service plan. Otherwise, the tool will not start transfer.

Customer: ppa-admin admins-subscription1.tld Customer: bobs

customer1-subscription1.tld customer1-subscription2.tld

Customer: johns_123 # Expand Plesk resellers are converted into PA customers.

notassigned1.tld

# Administrator’s service plans and subscriptions Plan: Gold hosting

Customer: ppa-admin admins-subscription2.tld Customer: jacks

customer2-subscription1.tld customer2-subscription2.tld

Customer: johns_123 # Expand Plesk resellers are converted into PA customers.

reseller-subscription1.tld reseller-subscription2.tld Customer: johndoe

# The subscriptions of this customer reseller1-customer1-subscription1.tld Plan: Bronze hosting

Plan: Silver hosting # Expand Resellers Reseller: exp_ress1

Plan: PA plan for exp_ress1 customers Customer: jake

site1.tld site2.tld

Customer: robert # Expand Plesk resellers are converted into PA customers.

5. Associate Subscriptions with Plans

In this step you should associate subscriptions that exist on your servers with certain service plans you have imported to PA in one of the previous steps. This is done by adjusting the transfer list file.

By default, the file already contains such associations for all subscriptions. As PA does not support custom subscriptions, you need to associate them with certain plans using the transfer list.

Note: The list contains plans and subscriptions only from the Expand server. Plans from Panel servers connected to Expand are ignored.



To associate subscriptions with certain service plans, edit the transfer file.

The association is performed by placing the corresponding subscription line under a certain plan section, or placing a line describing a plan (Plan: <plan name>) above the lines describing subscriptions.

Note that the tool will not start the transfer until there are subscriptions that are not associated with plans. If you do not want to associate certain subscriptions with plans, comment out the corresponding subscription lines or delete them.

Note: All plans from the list must exist in PA. Otherwise, the tool will be unable to complete the transfer.

For example, to associate the custom subscription admins-subscription.tld with the Gold hosting plan, move the corresponding line under the plan section.

Before After

# Custom subscriptions Customer: ppa-admin admins-subscription.tld Plan: Gold hosting Customer: bob

customer1-subscription1.tld Plan: Silver hosting

Plan: Gold hosting Customer: ppa-admin admins-subscription.tld Customer: bob