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

The Network and Information Securities Directive (NIS) 2 aims to increase the security and resilience of essential services and digital infrastructure in the European Union. It affects essential entities (including energy, transport, and banking) and important entities (such as postal, food, and manufacturing).  

The legislation came into force on 18 October 2024, following the creation of national laws based on the directive. Key requirements include risk assessment, management and prevention, incident reporting within 24 hours, and backup and disaster recovery.

Software can help mandated organisations maintain compliance and stay ahead of cybersecurity threats. Here’s what you should look for in NIS2 compliance software.

What do you need to keep in mind when choosing a new software solution?

Fines and punishments for NIS2 are stringent – up to 2% of global annual revenue. Staying compliant isn’t just a cybersecurity matter, it’s a financial one. 

CloudM helps you meet the NIS2 implementation requirements with Backup, our solution for preventing data loss and ensuring recovery and restoration. Backup keeps data protected in the background, while you’re free to focus on the business.

For a step-by-step guide, visit our knowledge base.

No data left behind: complete Google to Google migrations

With Migrate 4.1 CloudM are leading the way in migrating many key data types of the Google ecosystem. From email, Chat and Spaces to Shared Drives, Calendars and Tasks, data and files are rehydrated into the destination tenant. This seamless transfer ensures your team can continue working without friction or disruption.