{"id":99930,"date":"2024-12-18T15:20:44","date_gmt":"2024-12-18T07:20:44","guid":{"rendered":"https:\/\/version-2.com\/?p=99930"},"modified":"2024-12-09T15:24:07","modified_gmt":"2024-12-09T07:24:07","slug":"delta-first-or-traditional-choosing-a-migration-approach","status":"publish","type":"post","link":"https:\/\/version-2.com\/zh\/2024\/12\/delta-first-or-traditional-choosing-a-migration-approach\/","title":{"rendered":"Delta-first or traditional? Choosing a migration approach"},"content":{"rendered":"\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

<\/p>

Choosing the right migration approach for your project<\/strong><\/h2>

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 <\/span>fined over \u00a348 million<\/span><\/a> for its failure to manage the migration effectively.\u00a0<\/span><\/p>

Three migration approaches: pros and cons
<\/strong><\/h2>

1. Traditional migration (waterfall methodology)<\/span>
<\/strong><\/h3>

The traditional approach involves migrating bulk mail and drive items, followed by regular, smaller (delta) migrations of new and modified files.\u00a0<\/span><\/p>

By moving bulk data upfront and capturing recent files with delta migrations, traditional migrations minimise downtime. There are some drawbacks \u2013 you need robust processes to track, detect, and sync delta migrations accurately. And the initial bulk migration is resource-intensive.\u00a0<\/span><\/p>

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.\u00a0<\/span><\/p>

2. Delta-first migration
<\/span><\/strong><\/h3>

Delta-first migrations are like traditional migrations in reverse.\u00a0<\/span><\/p>

New and recently updated (delta) data is migrated first. Then historical (bulk) data is migrated later. It\u2019s a less conventional approach but gives users immediate functionality with minimal operational impact.<\/span><\/p>

Teams can move into the destination platform faster, and incremental delta migrations mean the bulk migration is smaller (and faster).\u00a0<\/span><\/p>

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.<\/span><\/p>

3. Google migration mould (domain switch)<\/span><\/strong><\/h3>

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\u2019re moving to a new workspace but need to keep their existing domain name and email addresses.\u00a0<\/span><\/p>

There\u2019s a specific methodology which requires temporary domains to do the bulk migration, and a domain switch during the delta migration. Google\u2019s tailored advanced migration settings such as selective data transfers and preserved permissions for shared drives, calendars, and files make the process easier.\u00a0<\/span><\/p>

There are drawbacks though \u2013 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.<\/span><\/p><\/div>

How to know which migration approach is right<\/strong><\/h2>

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:<\/p>

Goal: Limited downtime and business continuity<\/span><\/strong> <\/span><\/h3>

If <\/span>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.\u00a0<\/span><\/p>

Goal: Speed<\/span><\/strong><\/h3>

If you\u2019re looking for <\/span>speed, choosing not to migrate permissions on folders and files, selecting a specific date range (e.g. the last 12 months\u2019 data), and getting users to delete unwanted data can speed things up.\u00a0<\/span><\/p>

Goal: Vacating incumbent platform immediately<\/span><\/strong><\/h3>

If your priority is <\/span>vacating the platform immediately, a delta migration that moves recent data \u2013 say, 30 days\u2019 worth \u2013 means you can go live fast. Then, you can backfill your target destination with historical data post-cutover.\u00a0<\/span><\/p>

Other factors that influence how quickly you can complete a migration include:\u00a0\u00a0<\/span><\/p>