Big Bang or Progressive Migration?

• Timeframe
  • Should this email migration take ten days or one hundred days?
  • Are there certain deadlines to meet?
  • Or time windows to avoid (e.g. for conflicting internal projects)?
• Scope
  • What exactly needs to be moved?
  • Only email data, or Settings, Contacts and Calendar data as well?
• Data integrity
  • What data needs to be cleaned up prior to migration?
  • To what extent does it need to be cleaned?
  • How long will this take?
  • Who will do it?
• Methodology
  • What is the preferred email migration methodology (e.g. ‘big bang’ or ‘progressive’)?
  • What are the pros and cons of each option?
• Priority segments
  • If the migration will occur in stages, what subsets of end users will be moved and when?
• Internal Constraints
  • What internal rules, government legislation, privacy restrictions, and/or communication charters need to be adhered to?
• Staffing
  • What staffing will be required for this project?
  • Does this include (additional) help desk and/or call centre staffing?
• Expert assistance
  • Does anyone else need to be involved to ensure the migration is a success (e.g. DNS and authentication/security teams)?
• Communications
  • Who will design and action the customer communications plan?

 

Choosing your email migration methodology

Of all the decisions your migration team need to make, perhaps one of the most important decisions is the choice of email migration methodology.

The most common email migration methodologies are ‘big bang’ and ‘progressive’, which each have their benefits and their challenges.

Big Bang Migration

The first option is to perform a big bang (‘forklift’ or ‘mass’) migration.

In this methodology, the entire email dataset is moved from the legacy to the target system in one operation (or finite time period) and typically involves service downtime.

The key benefits of this methodology are:

• More condensed migration and implementation time – which ideally suits a migration team with the luxury of scheduled downtime (e.g. over a weekend), so they can focus on the migration with 100 percent intensity during that period; and
• No need to operate two email platforms at the same time.

The key challenges with this methodology are:

• The larger and more complex the migration, the more hours of scheduled downtime and the more significant the user impact, due to the large data transports at once (which even the latest ETL and data movement software cannot seem to adequately alleviate);
• Even with high export speeds, a slow API can cause havoc to the best of plans, which, when two systems are not being run simultaneously, can increase the downtime and user impact; and
• If all users are affected simultaneously, there can be a colossal impact on the help desk if all users are calling at once.

Progressive Migration

The second and increasingly popular option is a progressive (‘live’, ‘proxy’, ‘iterative’, ‘trickle’, ‘phased’, ‘swing’, ‘tandem’ or ‘parallel’) migration.

A progressive migration is an incremental migration, where only specified email accounts are to be migrated at any time, and both old and new email platforms are available for the entirety of the migration.

The key benefits of this methodology are:

• A gradual introduction of the platform to users, so that if there are bumps in the road that trigger an influx of calls to the help desk, the impact of this at any one point in time can be minimised; and
• There is a natural rollback option available to the source platform.

The key challenges with this methodology are:

• Keeping the source systems synchronised until full migration is complete;
• Paying for two systems to run at the same time; and
• Coordinating the migration of distinct elements so as not to break business continuity.