Post-migration Checks

After migration is completed, you should verify that the transferred resources are available on the destination server. To do this, issue the following command:

panel-migrator test-all config.ini

It generates a report and save it into a file - sessions/migration-session/test-all-report.<date>. This report has a tree structure that represents a hierarchy of clients, subscriptions, and subscription services. For details on how to process it refer to the corresponding section of this guide.

Post migration checks verify the following aspects:

• Websites
• Mail
• DNS
• Databases
• System users

Websites

Web pages and Web applications need to function in the same manner on the source and destination servers. For this reason, the main page and links to the same website (or relative links) located on the main page are checked.

For each migrated domain, the following items are checked:

• Address of the home page.
• APS applications registered in Plesk and placed on the site.
• Addresses in the form http(s): // DOMAIN / RELATIVE_URL for the relative links located on the homepage.
• If a site is configured to use SSL on a dedicated directory, HTTPS addresses are also used for verification.

For each site, the main page is requested from the source server and destination server. The contents of the main page are analyzed and all the relative links of the elements of the type <a href="RELATIVE_URL"> series are divided into groups according to two criteria:

• RELATIVE_URL are in the same directory. This criterion makes it possible to perform a check of rights to a subdirectory relative to the root of the website.
• RELATIVE_URL are in the same directory that have the same extension. This criterion makes it possible to check the configuration of handlers for client browsers.

From each group, one RELATIVE_URL is selected and addresses like http(s)://DOMAIN/RELATIVE_URL are compiled. For each selected object, a request is sent to the appropriate address on the source and destination servers. The resulting web page is analyzed for the presence of HTTP errors.

A result is considered positive if both of these conditions are met:

• HTTP (S) status code is 200 OK
• Headers documents coincide or are both absent

A result is considered negative if at least one of these conditions is met:

• HTTP (S) error code is received (for example, 404)
• The titles of documents are different, or only one of the titles is available

Mail

For each migrated domain, all mail accounts of the source server must be present on the destination server.

• For each migrated domain, read a list of email accounts from the source server and the target server. After receiving the list of mail accounts for all migrated domains from the source server and the destination server, check the difference between them.
• For each mailbox from each migrated domain, log in by POP3 or IMAP to the original and the resulting mailboxes. Compare the number of messages from the source server and the destination server.

DNS

Resource records should be transferred from the source server to the destination server, and IP addresses of the source should be replaced with addresses of the destination, according to the IP mapping file compiled during migration. The list of the main DNS records includes A, MX, NS records, records for domains and subdomains with the prefixes www, ipv4, ipv6, ftp, and webmail.

For each migrated domain, a list of the main DNS server entries is retrieved with the dig utility. After that, the values for the main DNS records are compared with the IP address or domain name used by the service.

Databases

For each migrated domain, all databases from the source must be present on the destination server. The following checks are performed:

• All database users are present on the source and destination servers, and they can successfully pass the authorization.
• All database tables are created.

System users

System users - users that can connect to the server over remote access protocols (FTP, and SSH / RDP) and manage files in a webspace. By default, when you create a webspace, the main system user is created, whose account can be used to log in over FTP, SSH or RDP. Also, customers can create additional users that can access the webspace only via FTP.