Choosing the right migration approach for your project
A successful migration starts long before you move the first file, and the consequences of insufficient planning and preparation can be disastrous. Back in 2019, British bank TSB locked millions of customers out of their accounts, following a failed IT migration. In 2022, the bank was fined over £48 million for its failure to manage the migration effectively.
Three migration approaches: pros and cons
1. Traditional migration (waterfall methodology)
The traditional approach involves migrating bulk mail and drive items, followed by regular, smaller (delta) migrations of new and modified files.
By moving bulk data upfront and capturing recent files with delta migrations, traditional migrations minimise downtime. There are some drawbacks – you need robust processes to track, detect, and sync delta migrations accurately. And the initial bulk migration is resource-intensive.
Traditional migrations are linear, making it harder to change tactics once the project is in motion. This type of migration is a solid fit for high-volume systems with active users but might be too rigid for simple migrations or time-limited projects.
2. Delta-first migration
Delta-first migrations are like traditional migrations in reverse.
New and recently updated (delta) data is migrated first. Then historical (bulk) data is migrated later. It’s a less conventional approach but gives users immediate functionality with minimal operational impact.
Teams can move into the destination platform faster, and incremental delta migrations mean the bulk migration is smaller (and faster).
There are limitations, though. You need to maintain source and destination platforms throughout the migration. Separating delta and bulk data requires robust tracking mechanisms to manage transfers. Dependencies between delta and bulk data mean certain files may not function properly until the full migration is complete, and you need to sync both data types continuously.
3. Google migration mould (domain switch)
A Google migration mould lets users keep their domain name when moving from an existing Google workspace to a new one. A company could benefit from this approach if they’re moving to a new workspace but need to keep their existing domain name and email addresses.
There’s a specific methodology which requires temporary domains to do the bulk migration, and a domain switch during the delta migration. Google’s tailored advanced migration settings such as selective data transfers and preserved permissions for shared drives, calendars, and files make the process easier.
There are drawbacks though – Google API limits restrict the number of daily data transfers, and certain types of data (such as comments in a document) might not be migrated. Using a cloud migration service can get you past some of these limitations.
How to know which migration approach is right
To determine the right approach for your next migration, we recommend you work backwards. The most pressing outcome of the migration will most likely dictate the approach:
Goal: Limited downtime and business continuity
If limited downtime and business continuity are your main focus, a traditional approach ensures historical data is available for your go-live date. You can migrate users simultaneously with a big bang cutover, and avoid downtime by scheduling the migration over a weekend or planned closure.
Goal: Speed
If you’re looking for speed, choosing not to migrate permissions on folders and files, selecting a specific date range (e.g. the last 12 months’ data), and getting users to delete unwanted data can speed things up.
Goal: Vacating incumbent platform immediately
If your priority is vacating the platform immediately, a delta migration that moves recent data – say, 30 days’ worth – means you can go live fast. Then, you can backfill your target destination with historical data post-cutover.
Other factors that influence how quickly you can complete a migration include:
-
Amount and type of data
-
Data per user
-
Folder, file, and email count
-
Media (MIME) types
-
A lack of documentation for legacy systems
-
Ability to coexist in two different environments
Can you combine migration approaches?
Combining migration approaches is possible and may in some cases be necessary to work around more complex migration scenarios and conflicting goals. Here’s an example:
A multinational company wants to prioritize its specific users and teams in their migration. The company completes a bulk migration for non-critical users and shared drives during planned downtime. Then, the company completes a delta-first migration for critical teams and executives’ recent data (e.g. the last 30 days) into the target system for immediate access. Historical data is backfilled post-cutover to limit delays.
CloudM can help you make the best choice
You can count on CloudM Migrate for a smooth migration. Choose from white glove migration services where we take care of the migration for you. Or get tailored training and advice through our consulting services that equip your team with the skills to deliver frictionless migrations.
Book a call with our migration specialists today
