CloudM typically recommends migrating all data during the bulk and delta phases—this is especially critical for Drive/File migrations to maintain data integrity.
However, for Email migrations, or where specific project requirements exist, a Phased Approach using date ranges may be utilized to enable a faster Go-Live, followed by a Backfill of historical data.
Date Range Tip: CloudM Migrate uses a 00:00 timestamp for date filters. To avoid missing data at the "cutoff" point of a phase, always include a 1-day overlap (e.g., if Phase 1 ends on the 10th, Phase 2 should start on the 9th).
Email Phasing Strategy
Email phasing is flexible because CloudM Migrate's Migration History automatically identifies and skips already migrated items. Even with an overlap in your date ranges, duplicates will not be created.
The following table outlines a strategy to isolate the last X years of active email data for the initial migration and go-live, followed by a historical backfill phase:
| Migration Phase | Target Date Range | Operational Objective |
|---|---|---|
| Phase 1: Bulk (Recent Data) | 01/01/2023 to [One month in the past] | Migrate the last X years of mail up to one month in the past (to allow for mailbox changes between phases such as read state, location updates, and deletions to be processed) to the destination. |
| Phase 2: Delta / Go-Live | 31/12/2022 to 01/01/2050 (The future) | Capture all remaining active data, including the "Working Window" excluded in Phase 1. Note: Starting one day before the Phase 1 'From' date ensures any items received at the exact 00:00 cutoff are captured. |
| Phase 3: Backfill (Historical Data) | 01/01/2000 (or "Beginning of Time") to 02/01/2023 | Migrate the remaining legacy data post-Go-Live. |
Calendar and Chats: These items can be migrated in a similar phased fashion. However, due to the highly dynamic nature of these data types, we strongly recommend following our general Recommended Migration Strategy and referring to specific platform guides to ensure correct configuration.
File Migration Phasing
File migrations require a Single Source of Truth. While users are migrating, they should only work in the source. Once users are "Live" in the destination, the destination becomes the source of truth. Running a backfill after users have started editing files in the destination creates a risk of data conflict.
Required Configuration
To successfully migrate subsets of file data, you must adjust the following settings:
-
Filter by Date:
Configuration > General > Date Range > [Data type] dates -
Change Filter Logic:
Configuration > Advanced > Document > Filter Data Type. This must be changed to File Modified Date.
This ensures that files recently worked on or created are captured in your first pass. Set to File Created Date by default, this would migrate only files created within the range, and not migrate files created outside the range that have been modified within the range.
Example File Strategy
The following table outlines a strategy to isolate the last X years of active file data for the initial migration and go-live, followed by a historical backfill phase:
| Migration Phase | Target Date Range | Operational Objective |
|---|---|---|
| Bulk Phase | 01/01/2022 > 01/01/2050 | Migrates all files created or modified within the last X years through to a future baseline date. |
| Delta 1 - GoLive | 01/01/2022 > 01/01/2050 | Captures final deltas and modifications for the active data subset prior to user cutover. |
| Delta 2 - Backfill | 01/01/2000 > 02/01/2022 | Migrates remaining historical data. Note: Contains a 24-hour overlap (01/01/2022 to 02/01/2022) to prevent data gaps caused by the date range meaning 00:00 clock on that date. |
⚠️ Caution: Data Conflicts (Files Only)
If a file is modified in both the source and destination platforms simultaneously (i.e., between the time of the Bulk pass and the Backfill), you will face a data conflict.
By default, CloudM Migrate is configured to ensure destination files are updated to match the source. If users have already cut over to the destination and begun working on files, running a subsequent migration phase (such as the Delta 2 - Backfill) will overwrite these live changes with the data from the source if those files have also been modified on the source since the previous run.
To prevent the Backfill from overwriting new destination edits with older source data, you must explicitly disable this parameter before executing the backfill pass: Configuration > Advanced > Document > Overwrite Updated Documents.
If this setting is disabled: CloudM will only migrate new, unmigrated files and will ignore source updates to files that already exist in the destination. This protects post-migration user edits from data loss in the destination, but stops the propagation of subsequent changes from the source. If specific updated files must be migrated, they should be moved manually to compare versions.
Summary
Phasing is a powerful tool to meet aggressive Go-Live deadlines. By utilizing File Modified Date for files and the Day Overlap logic for mail, you can manage large data volumes in a controlled, phased manner.