CloudM Migrate has an in-progress migration estimator which calculates remaining time in a migration, using total data volume and current throughput (the rate at which the data is processed).
This estimator requires the migration to already be in progress and is a high-level estimate of remaining time. Accurately estimating migration duration prior to beginning is more difficult, due to the high number of variables involved and the varying limiting factors such as bandwidth, machine spec and platform throttling (see here for more info). Due to these factors, ideally, the following data would be gathered in order to estimate duration, both in total and per user:
- Total number of users/drives/sites to migrate
- Data volume
- Total number of email and file items
- Data distribution (number/volume of items per user)
- Number of file permissions
- Number of file folders
This data can all be obtained using Environment Scan.
The source platform information can help in designing the migration architecture, ie. the number of CloudM Migrate Self-Hosted secondary instances used in the migration. Each instance runs 20 simultaneous threads by default and, as the limiting factor in almost all migrations is cloud platform throttling and API quotas, the number of threads is key to determining the expected duration.
As platform limits are generally item per sec/user, it also means the number of items is just as, if not more, important than data volume. Our internal testing (using results of real world migrations and best practices) has determined an average of 40,000 mail items per instance/2,000 items per thread per hour. As a general rule, a migration takes as long as it's largest user, so this can be used to calculate an estimated total duration, providing there are enough threads available to complete the remaining users in this time.
Migration batches can be used to ensure the largest users utilise the available thread time in the most effective manner.
If migrating to Google Drive or Sharepoint / OneDrive, there are additional factors which should be considered. In particular, the number of permissions, as this increases the number of API calls required and the likelihood of throttling, and the number of folders, as these must be processed during every migration run (whereas files are only processed if modified since the first run).