Because there is a re-sync option, the overall speed of the initial data transfer with Plesk Migration Manager (PMM) doesn't matter that much (to us), however when re-syncing the speed of the process is super important because domain web and email services on the source server must be down/offline to prevent data inconsistencies. The re-sync process currently takes roughly 1 hour per 100 subscriptions.

Here's three ways the re-sync process could be improved to minimize web and email service downtime:

# 1. Fetch configuration data ONCE

PMM batches 5 subscriptions at a time, and prior to each batch of 5, it sits for 3-4 minutes saying "Fetch configuration data from Plesk servers"

Presumably it's grabbing info on the next 5 subscriptions.

PMM should fetch configuration data for all subscriptions in the queue at the start of the re-sync, as we don't have to block access to the server during that part of the process. Once it actually moves on to copying data from the subscriptions, we would then start the downtime portion.

# 2. Always keep 5 processes running

Currently PMM batches 5 subscriptions at a time, however as the data transfers for each subscription complete, it does not start additional subscription migrations to keep 5 going at all times. That means it can be sitting migrating a single subscription (ex: with larger databases or more emails) and nothing else happening, which wastes time.

If (1) above is implemented, then PMM could always keep 5 subscriptions migrating simultaneously, such that when one completes, another subscription migration begins.

Even if (1) above is not implemented, it could at least start Fetching configuration data for the next 5 subscriptions after the first subscription (in the prior group) finishes migrating. That way the 5 processing slots would look something like this after the first subscription finishes migrating:

1. Subscription data copy
2. Subscription data copy
3. Subscription data copy
4. Subscription data copy
5. Fetch configuration data for next batch of 5

3. Allow admin to configure the number of subscriptions to migrate in each batch

Rather than a fixed value of 5, why not allow the admin to configure that. If, for example, the server has 16 cores, it would make sense to allow something like 12 simultaneous subscriptions to re-sync at once.

Or Plesk could monitor the server load and, if it's less than the number of cores on the server, automatically scale the number of simultaneous subscription migrations to match.

Implementing these options could result in reducing the total re-sync time by half or potentially more.