Issue Migration feedback - a bunch of comments

[M_N]

Server operating system version

Windows Server 2022

Plesk version and microupdate number

18.0.52

Hi

I am currently in the midst of migrating over 100 websites from one server to another.

Source server: Windows Server 2012 R2, Destination Server: Windows Server 2022
Plesk Obsidian 18.0.52 on both servers.
Plesk migrator extension version: 2.24.0-1083

While overall the migration tool is saving me a ton of time doing it manually. The tool has many issues that could be improved.

List of subscriptions:
I understand that you can only migrate a full subscription and not individual domains, but nevertheless it would help tremendously if I can see the domains in each subscription on the list. also would be extremely helpful if I can see (and filter) the status of the subscriptions and individual domains. (I have many domains on the source server that are inactive and I don't want to migrate them).

Database migration
Copying from MySQL 5.6: On the source server some domains are using MySQL 5.6 and some are using MySQL 8. The migrate tool cannot generate a dump from MySQL 5.6 (issue with generation_expression column - https://support.plesk.com/hc/en-us/...umn-generation-expression-in-field-list-1054-)
If I manually create a dump from phpMyAdmin on the source server, I am able to import that successfully in the destination server. I see no reason why the migrator cannot do that.

Copying from MySQL 8: On quite a number of websites that I have checked so far, wordpress fails to load with an errro 'error establishing a database connection'. this error is quite misleading because it does in fact connect to the database. (if I deliberately change the password in wp-config and turn on wp_debug I see that it actually fails to login, when I put back the correct password there is no error, but still wordpress reported error establishing a database connection. it turns out that the migration failed to completely copy the database and the new database was incomplete - notably the wp-options table was empty. But the migrator did not report any errors on this database. (again a manual phpMyAdmin dump on the old server was imported without a problem on the destination server).
MySQL 8 on the source server was using port 3307 (since 5.6 was using the default 3306 port). On the destination server I have just the MariaDB on port 3306. After migration I needed to manually update the db_host in wp-config.php from 'localhost:3307' to remove the :3307. Perhaps that is something that the migrator can be updated to do automatically.

PHP Version:
Source server was using php 7.3 for most php sites, destination server does not have php 7.3 installed, the migration tool correctly reports that 7.3 is not available and the site will use php 7.4, when I check the hosting settings the site is in fact set to use php7.4 but the site does not actually load (500 error). a failed request trace showed that it is actually still trying to load php 7.3 (the failed request trace included the full path to php-cgi in the path on the old server, which does not exist on the destination server). The solution is to change the hosting config to a different version of php and then back to version 7.4 which solved the problem.

Domain alias email:
For any subscription with domain aliases, the migrator reported error "Unable to create domain alias: Execute mailmng --add-alias "--domain-name=........." "--alias-name=........." --mail failed with error code 1:". (I will not be doing emails on the destination server and when migration I deselected the option to migrate email content)

Application app pool:
A bunch of app pools on source server were set to enable 32 applications, that setting was not migrated to destination server. I had to turn it on manually where needed.

I'll post more if I remember additional issues.

Once again just to be clear: Despite the issues, I would not be able to do the migration without this tool. Despite the issues it is still an amazing tool.

 

[Peter Debik]

Thank you @M_N for taking the time to let us know. This feedback is for sure a valuable contribution that enables us to understand users and your requirements better. We'll take it into account when developing Migrator further.

 

[M_N]

About the issue with domain alias email: It has occurred to me, the likely issue is that I have disabled the mail service on most domains, when you disable the mail service, plesk changes the domain in the mail server to domain.com.d (adding a .d to the domain name). When attempting to add the user for the domain alias, the logs show that the migrator is sending the regular domain name to mailenable and mailenable obviously does not find that domain. The migrator needs to check if the mail service is disabled and then send the domain with the added .d in the command to create the alias.

 

[M_N]

When doing Re-Sync on a subscription, there is a dialog where you can choose what to resync.
You can choose
Business objects
Website files
Database data
Email messages

If I choose only website files (and left 'database data' unchecked) the migrator will ignore that selection and also migrate the databases.

 

[M_N]

In the list of subscriptions, there's a dropdown menu to the right of each subscription, but nothing happens when I click on it. I don't know if it's an empty menu and the icon shouldn't be there, or there is actually a menu but it doesn't dropdown for some reason.

 

[Peter Debik]

In the list of subscriptions, there's a dropdown menu to the right of each subscription, but nothing happens when I click on it. I don't know if it's an empty menu and the icon shouldn't be there, or there is actually a menu but it doesn't dropdown for some reason.

Could you please share a screenshot? Is this still related to Plesk Migrator or a different topic?

 

[M_N]

Yes this is on the migration page, screenshot attached

 

[Peter Debik]

O.k., thank you for clarification. We have plans to overhaul Plesk Migrator during the following months anyway, so probably this will all be looked at.

 

[M_N]

Had another bug yesterday.

After a site was migrated, I made DNS changes on the source server. When I was ready to transfer that site to the new server, I resynced content and databases, and then switched DNS, I then discovered that my recent DNS changes on the source server were not resynced when I resynced content, so those changes were lost, luckily it was minor changes and I was easily able to fix it.

The resync has various checkboxes of what to sync, DNS is not one of them, which option should trigger a DNS resync? or does resync not look at DNS? Perhaps the switch DNS function needs to resync DNS data before switching?

 

[Peter Debik]

I think it just does not re-sync. There are a number of things that cannot be re-synced, but it makes some sense in such cases, because especially for DNS for example, how should Migrator know what to sync and what not if the target data has been modified in the meanwhile?

 

[M_N]

The migrator can check any values in the target, if they are different than the source AND the difference is not from the migrator itself (from the automatic changes it makes while migrating e.g. changes to the primary ip address). Since the migrator knows what changes it makes when initially migrating, it should be able to tell what is changed manually.

Or maybe add it as one of the choices when doing a resync and let me choose?

 

[M_N]

The migrator can check any values in the target, if they are different than the source AND the difference is not from the migrator itself (from the automatic changes it makes while migrating e.g. changes to the primary ip address). Since the migrator knows what changes it makes when initially migrating, it should be able to tell what is changed manually.

Or maybe add it as one of the choices when doing a resync and let me choose?

On 2nd thought, I guess if the values are different you would have no way of knowing if it was changed on the source or the destination.

 

[Peter Debik]

JFYI and for future reference: More Migrator experiences are logged in this thread by @tkalfaoglu : Input - Migration notes

 

[tkalfaoglu]

Btw, it's always best to delete and sync again.. re-sync without deleting the target can cause problems..

 

[M_N]

Btw, it's always best to delete and sync again.. re-sync without deleting the target can cause problems..

The goal is that it should not cause problems, so I'm going to point out the issues I encountered so they can hopefully be addressed in future updates where possible.