When to use and how to approach a Staged Migration

Staged Migrations

Some customers have a business reason or requirement to move their users to Office 365 in groups, rather than in a single cutover. This may be due to several factors, including offices in different locations requiring different timelines and large customers with multiple, independently functioning divisions.

Therefore, almost four years ago, SkyKick developed Staged Migrations to help partners meet this specific need. Since then, SkyKick partners have performed hundreds of successful Staged Migrations for their customers.

In addition to automating synchronization at appropriate times for each staging group and ensuring that users are seamlessly moved to the cloud, the SkyKick Enterprise Migration Planner helps partners set up the entire project before placing the order.

Once underway, the SkyKick Exchange Assistant can be deployed for migrations from Exchange 2010, or partners can use PowerShell scripts sent by the automation to perform required tasks at the appropriate time to ensure mailflow and Outlook connectivity as each staging group moves to the cloud.

New call-to-action

When to use

While Staged Migrations are a powerful option for partners, in most scenarios, a standard cutover migration is the better and lower-cost option, due to its simplicity, shorter timeframe, lower risk, and less manual effort.

Additionally, we have found that some partners have misused Staged Migrations, leading to unnecessary manual effort, customer dissat, or both. Before considering a Staged Migration, it is important for both partners and their customers to fully understand:

  • Staged Migrations are not the right way to test SkyKick migration technology. For a better way, see How to test SkyKick migration technology.
  • A large number of users does not necessarily require a Staged Migration. SkyKick technology has been used to successfully migrate large customers (>10,000 users) in a single cutover.
  • The impact on shared resources between the first stage cutover and the final cutover.
  • The additional effort required to manage the project.
  • A Staged Migration should not be the first migration a partner performs with SkyKick.

How to decide

To help our partners make the right choice between a Cutover and Staged Migration for a particular customer, we created the decision flow chart below, along with the details that follow. Staged Migration Decision Chart.jpg

1. A Staged Migration is not the right way to test our technology

Partners should not plan a Staged Migration to test SkyKick technology. A Staged Migration:

  • Introduces complexities, including impact on shared resources between stages that are not encountered in a cutover migration.
  • Cannot be undone in an automated fashion.

The best way to test SkyKick technology is to start a cutover project and QA the data prior to the Migration Date. Because there is no impact on the customer, and there are no charges until after cutover, many partners have found this an effective way to test the automation for both partners and customers. For further information see How to Test SkyKick Migration Technology.

2. Ensure that your customer’s environment meets requirements

Our technology provides automation when migrating from on-premises Exchange 2007+ through the Enterprise Migration Planner. This means that POP3, IMAP4, Hosted Exchange and Google environments are not compatible with this migration scenario.

In addition, it is important that your customer gives you access to their Exchange server to run static PowerShell scripts. For Exchange 2007 and 2010, these are provided via email at the appropriate time. For Exchange 2010, the SkyKick Exchange Assistant application can be installed to automatically perform the required changes. For more information regarding requirements, see Staged Migrations.

3. Is this a priority configuration or a business need for your customer?

Unless a customer has a definite business need for a Staged Migration, it is better to not introduce unnecessary work for yourself or limitations during the migration for your customer. In most cases, it is only appropriate to consider this type of migration if:

  • Migrating a large number of users (and remember, a cutover migration can be successful with large numbers as well).
  • There are groups of users in different locations who need to be migrated at separate times.
  • There are few or no shared resources between groups.
  • There are significant bandwidth limitations.

4. Be prepared for the complexities

Initial scope and planning are vital for the success of any project, but Staged Migrations are particularly more complex, as you will have to plan for and perform multiple cutovers. Taking the time to determine which users to group together, in what order, and how far apart is critical. There are also additional tasks that must be performed for each stage cutover, rather than simply performing local/public DNS changes at a single cutover. This could include running PowerShell commands and potential work to manually address customer requirements outside the automation. All these take time, and with each additional task there are potential risks that could be introduced into the project.

5. Understand the limitations and set adequate expectations

While Staged Migrations address several needs, they can be more complex, requiring more expertise and management. Before starting a Staged Migration, it is important to know the following:

  • Shared resources are not fully functional until cutover.
  • Permissions between users in separate stages will be temporarily lost.
  • Mail forwarding and Mail-enabled Users (MEU) need to be configured to maintain mail flow.
  • Exchange MEU mailbox retention policy needs to be extended beyond date of cutover.
  • Litigation hold accounts cannot be converted into MEUs.
  • Office 365 mailbox creation will occur once the order is placed.)

How to approach a Staged Migration

If after all these considerations, a Staged Migration is the right choice for a particular customer, it is important to follow these guidelines.

Set appropriate expectations with your customer

Before signing the Statement of Work, be sure to get written agreement from your customer on the limitations and any additional work required for a Staged Migration

Consult our Help Center

Read more content on Staged Migrations from our Help Center to ensure you understand all variables, requirements, and limitations of this migration scenario.

Regularly monitor the Migration Dashboard

As with any migration, regular monitoring of the project is critical. However, it is even more so with the additional complexities of a Staged Migration. The SkyKick migration application will also send time-sensitive, instructional emails regarding PowerShell commands and other tasks that may be required.

Contact our Support Team

If this is your first Staged Migration, please contact SkyKick Support to discuss the project. Also, if you have questions or concerns at any time, don’t hesitate to call Support. It is free, and we are available 24/5 to walk you through Staged Migration basics, order placement, settings, and any other details required to ensure your success.