A Comprehensive Exchange 2010 to Exchange Online Migration Checklist
Want to ensure a seamless Office 365 migration? watch our free webinar on-demand “Planning for Office 365: Managing Content during Your Migration” today!
With Microsoft’s recent announcement that Exchange 2010 will stop receiving support on January 14, 2020, many organizations are finding themselves scrambling to upgrade. Luckily, upgrading to the cloud doesn’t have to be as daunting as it might seem at first blush.
Migrations to Office 365 are 90% planning and 10% execution. Deeply knowing and understanding what data you need to migrate is a must if you want to make your transition to Exchange Online as smooth as possible. To help with that, we’ve compiled some of the most important questions and considerations that every IT admin should be aware of before starting the migration process. Let’s dive right in!
Data Discovery
As alluded to above, the first step in any successful migration is to determine why and what you’re migrating. Establishing a firm timeline and set of goals is dependent on nailing down this information. During the data discovery phase, consider the following questions:
- Why are you migrating this data?
- Which platforms are the source and destination?
- Where geographically is the source and destination?
- What is the volume of data in the environment? Does the destination need to be notified about the migration?
- Are you migrating all of your data?
- How is the volume of data distributed? What size are the emails/email chains?
- What is the item count of the data to be migrated from the source environment (mailboxes, calendars, tasks, etc.)?
- Is all the data in scope necessary to migrate? Why? Are versions needed? Why?
Migration Hardware/Architecture/Modern Authentication
The underlying technologies supporting the migration are just as important as data discovery. After understanding your data, it’s time to make sure you have the adequate horsepower to migrate it. Determining the scale of these resources is key to meeting those tight deadlines. Another way to mitigate throttling is by meeting best practices for authentication with an app profile. Further considerations include:
- What resources are being allocated for the migration (number of servers, server version, server resource specifications, etc.)?
- Are your resources enough to migrate the data in a timely manner?
- Where are the migration servers? (On-Premises? SaaS? Why?)
- Where are the migration servers geographically located? (Which data center?)
- Are the migration servers in the most optimal geographic location? Should they be in a data center closer to the source or destination?
- How many members of your team are allocated to the migration? Is this adequate?
- What are the agent/server specifications?
- How many service accounts are being provisioned? Do the service accounts use MFA? (If so, we recommend leveraging an app token.)
- How many service accounts/app tokens are recommended? Why?
Obstacles and Bottlenecks
It’s always best to be overprepared than underprepared. You need an idea of how quickly your migration team can move the data in question and plan for possible delays or unforeseen issues (should they arise). Identifying possible obstacles before the migration process begins will lead to a more realistic migration timeframe and more comprehensive resource management plan. Consider the following questions when planning:
- What can potentially cause an obstacle/bottleneck? (Consider network quality, resource limitations, time of day, source and destination rate limits, migration architecture, etc.)
- How do you identify them? (Pilot migration? Testing? Pre-migration planning?)
- Which bottlenecks are identified in your pre-migration plan?
- How does the pre-migration plan address the obstacles/bottlenecks?
- How do you handle access to the source and destinations during the migration? Do you make the source read-only?
- How do you handle failed items? (The recommended best practice is to run an incremental migration a few times and wait for consistent failures of the specific item(s). Then investigate why they failed, if they were expected to fail, and if they were identified in the pre-migration plan.)
- Does the destination experience latency when populating migrated items? (Office 365 can take up to 24 hours to populate Teams/Groups/Planner.)
- During which hours is the migration going to be running and what can you expect from running the migration during these hours? When is the best performance expected for that region?
Exchange Online Migration Management
While we all wish for a one-size-fits-all migration management strategy, that’s not always feasible. Planning who is responsible for which tasks like testing, monitoring, and support are practices which result in clear communication and quicker resolutions. During this planning phase, ask yourself:
- Does the migration team understand these potential bottlenecks/obstacles?
- Is the migration team prepared/equipped to react to the identified possible issues?
- How does the migration team plan to handle unforeseen issues?
- Is the migration team equipped to identify and fix environmental issues? (Consider network, resource, connection, source and destination environments, unsupported functionality, service accounts, throttling, etc.)
Building Migration Plans for Exchange Online
When building plans, it’s best to think small. If you make small plans, then you increase the speed at which the overall migration will be completed. Another benefit of small compartmentalized plans is that if one plan has speed bumps, the rest of your migration will not be affected. This way, data is always moving to your destination. Be sure to consider:
- Is the migration going to be in waves? Why? How is it going to be broken down?
- What is the volume of data being migrated in the plan’s scope?
- How many items are in the plan’s scope?
- How is the data in scope distributed? Which containers/users have more data than others in the plan?
- Should this plan be broken down into smaller scopes/plans?
- Is there a place for the data to go in the destination? Are mappings needed? If so, are they user or domain mappings?
- How many Agents should be used for the plan? (Consider data volume and item count)
- Do the resources allocated support the plans configured?
- Should any of the plans be on a schedule?
- Does the plan’s scope have any customized features?
- Does the plan contain any data which is not supported? (Keep in mind that the migration team is responsible for discovering and addressing this before the migration.)
- Was any unsupported data discovered? (If so, contact AvePoint to discuss alternative solutions to migrate this data.)
Additional Pre-Migration Considerations
And finally, here are a few loose ends that need to be factored into your pre-migration plans:
- Which migration team member is responsible for what?
- When is the best time to kick off the migration?
- What day of the week?
- What time of day? Is it peak consumption hours for that region?
- Is the migration tool operational?
- Is the source and destination ready to begin?
- Should the end user’s access be restricted during the migration? If so, should restriction be to the source or the destination?
- Are the source and destination accessible by the service account, or is the app token still valid?
- Are the plans properly configured?
- Have the mappings been checked?
Final Thoughts
There’s no denying that the leap from Exchange 2010 to Exchange Online is a substantial one. Like I mentioned at the start of this checklist, going in with a well-established plan is 90% of the battle here. If you want to move all of your mailboxes, calendars, tasks, and messages over smoothly the most successful approach is to first step back and understand what you are moving, when you are moving and how you are moving. This is a great time to comb through the data and get rid of anything you may not need to move.
