Post-Migration Checks

After migrating from one of the supported source platforms, 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.

The post-migration check verifies the operability of the following aspects:

  • Websites
  • Mail
  • DNS
  • Databases
  • System users

For every aspect, service-specific tests are performed for every migrated object (website, mail account, system user, and so on). The details about the tests are given later in this section.

To perform the post-migration check:

  • If you are migrating via the Plesk interface, check the Check the operability of services after migration checkbox when initiating the migration. The results of the post-migration check will be included in the migration log, which is accessible from the Plesk interface once the migration is completed.
  • If you are migrating from a Plesk for Linux server via the command line, run the following command after the migration is finished:
/usr/local/psa/admin/sbin/modules/panel-migrator/plesk-migrator test-all

The post-migration check generates a report and saves it to a file named test-all-report.<date> placed in the /usr/local/psa/var/modules/panel-migrator/sessions/migration-session/ directory.

  • If you are migrating from a Plesk for Windows server via the command line, run the following command after the migration is finished:
"%plesk_dir%admin/plib/modules/panel-migrator/backend/plesk-migrator.bat" test-all

The post-migration check generates a report and saves it to a file named test-all-report.<date> placed in the <PLESK_DATA_DIRECTORY>/var/modules/panel-migrator/sessions/migration-session/ directory. To find the location of <PLESK_DATA_DIRECTORY> on your server, open the command prompt and run the following command:

reg query "HKLM\SOFTWARE\Plesk\PSA Config\Config" /v PRODUCT_DATA_D /reg:32

The report has a tree structure representing a hierarchy of customer accounts, subscriptions, and services. For every post-migration test that fails, an entry is included in the log, including details about the failure and steps to verify/resolve the potential issue.

Post-migration tests

Websites

For each migrated domain, the following items are checked:

  • Home page address.
  • Web applications installed via Plesk.
  • Addresses in the form http(s)://DOMAIN/RELATIVE_URL for the relative links located on the homepage.

For each website, the index page is requested from the source server and destination server. The contents of the index page are analyzed and all relative links in the form <a href="RELATIVE_URL"> pointing to the same domain are checked. To speed the process up, links are grouped by directory and extension, and a single link is randomly chosen from each group to be checked. For example, if http://DOMAIN/pages/about.php and http://DOMAIN/pages/contacts.php are both on the index page, only one of these links will be checked.

For each selected link, a request is sent to the appropriate address on the source and destination servers (checks follow redirections by 301 and 302 HTTP codes). The resulting web page is analyzed for the presence of HTTP errors. A test is considered successful if all of the following conditions are met:

  • HTTP(S) status codes are identical.
  • HTTP(S) status code on the destination is not 4xx or 5xx, which usually indicates an error (an exception is made for code 401 used for password-protected directories).
  • HTML <title> tags in both documents are either identical or absent.

Otherwise, the test is considered to have failed.

Mail

For each migrated domain, all mail accounts present on the source server must be present on the destination server as well. The following tests are performed:

  • For each migrated domain, the list of email accounts from the source server is compared to that from the destination server to make sure that none are missing.
  • For each mail account belonging to each migrated domain, a login to the mailbox is performed on both the source and the destination servers via SMTP, POP3, and IMAP to verify access. Then, the number of messages in the mailbox on the source server is compared to that on the destination server. If the numbers differ by more than than five, an error is reported.
DNS

For each migrated domain, all resource records must be transferred from the source server to the destination server, and IP addresses from the source server must be replaced with those from the destination server according to the IP mapping rules. The following tests are performed:

  • For each migrated domain, the list of main DNS records (such as A, AAAA, MX, CNAME, and so on) from the source server is compared to that from the destination server to make sure that none are missing.
  • For each migrated domain, the list of the main DNS records is retrieved on the destination server to make sure that the records can be resolved and point to IP addresses from the destination server.
Databases

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

  • For each database on the source server, a check is made to ensure that the database is present on the destination server and registered in Plesk.
  • For each migrated database, the list of database users from the source server is compared to that from the destination server to make sure that none are missing. In addition, an authentication attempt is performed for each database user on the destination server.
  • For each migrated database, the list of database tables from the source server is compared to that from the destination server to make sure that none are missing.
System users

For each migrated domain, all system users (users that can connect to the server via FTP or SSH / RDP) present on the source server must be present on the destination server as well. The following tests are performed:

  • For each migrated domain, the list of system users from the source server is compared to that from the destination server to make sure that none are missing.
  • For each system user, a login to the destination server is performed via FTP and SSH (Plesk for Linux only). For Windows system users, membership in the "Remote Desktop Users" group is verified.
 

Leave your feedback on this topic here

If you have questions or need support, please visit the Plesk forum or contact your hosting provider.
The comments below are for feedback on the documentation only. No timely answers or help will be provided.