Office 365 Migration Batches: How to Group and Wave Users
One of the major areas of consideration when planning your journey to the cloud is identifying key dependencies within your organization, allowing you to perform a staged migration with minimal disruption to everyday business operations.
In this quick guide to Office 365 migration batches, we’ll outline the key challenges you should ask to help ensure a successful transition as you upgrade your IT infrastructure.
Why do we need to batch users?
When planning your migration, you need to consider if you need to batch users or not. If you can avoid it, then it is sometimes easier to do a “flash cut” of all users at once. However, the number of users, amount of data, and other factors dictate if you can do a large cutover or not. In general, if you have less than 500 users, you will want to do a flash cut of all users from one system to another. If you have between 500 and 1,250 users, you may be able to do a flash cut.
If you’re going to migrate all users at once, you should really consider a weekend maintenance window to give you as much time as possible to correct issues. If you have a 24/7/365 business model, then a flash cut may not be right for your business regardless of size.
Office 365 Migration Batch Guidelines
When conducting migrations, we primarily look at two categories of user data repository:
- Individual mailboxes and OneDrive files
- Shared data
When planning our migration waves, we have to consider who needs to be moved together. For example, if you have an Executive Administrative Assistant who supports your CEO, CSO, and CMO, they all need to migrate at the same time to ensure everything works. Otherwise, there can be huge issues with managing calendars and other such tasks.
Thus, when you’re doing a grouping exercise, it’s essential to analyze those connections and try to keep people together. It’s not perfect, and this is something everyone in the migration business struggles with, because if you split your organization into a Venn diagram and try to keep everyone together, you’ll inevitably end up with everyone in a single wave, which isn’t practical.
You’ve got to define where you’re going to cut things, and one method larger organizations typically use is having a list of executive support, or VIP users, and work with this specialist support team to define who can move when. This way, you keep your clusters of VIP users together, and then you can remove them from the mix before analysing the rest of the organization. This is usually quite successful as it tends to keep your working teams together and your executives together. Each organization is different, but many have found success with this method.
Studying shared repositories
Where things get more complicated is the second category of data – shared repositories.
Back in the day, organizations used to be very hierarchal; if you worked in the Finance department, you only worked in the Finance department.
Now, though, I might be in one work team with members from Marketing, and in another with Product Owners, and another with Developers. If we’re all sharing data on a SharePoint site, we all want to move together as well.
SharePoint, in itself, is a little easier because you can log in with a different account and get back to the data. However, for SharePoint teams and others, this becomes difficult.
For example, right now, I’m in some of our client teams, so I’m constantly switching between teams all day as I’m involved in multiple projects. For efficiency, wherever possible, we want to move everyone working together at the same time, or else users have to pop around to multiple environments. This is both an education step and not easy for all users to do.
The challenge with that is, you have to do a very robust permission analysis across all teams and try to group your users, which inevitably means a lot of manual work, and as we mentioned above, you will never hit 100% success.
Making your move
What large organizations typically run into is a segment of their business still being hierarchal. Usually, it’s your Operations team.
For example, if you think of an insurance company, their customer relations department will often take an hierarchal-based approach; staff are trained and work together in the workgroup supporting customers. They don’t do a lot of collaboration across the organization outside of sending emails to each other. Thus, you can safely move that group in one wave, or a wave per department depending on size.
Where things get more complex is in your knowledge worker community and where individuals span everywhere. Who are you going to move, and when and how?
“Coping” examples
Let’s say you have 500 users in the HR Department and 200 users in Payroll. (OK, I hope you don’t have 200 people in payroll, but you will certainly get paid on time if you did!) After looking at the permissions on Shared Mailboxes and SharePoint sites there is a lot of overlap in these departments.
You determine that 700 users is too high to move all at once. However, you put these waves directly next to each other to minimize the disruption and impact. You perhaps even do it during a quiet period for these departments (and never during a payroll run!)
To continue this example, let’s say there are 100 users in HR and 10 users in Payroll. You would then group these together and move them in one wave.
These are two of the most common techniques to keep work teams together and minimize the need to “cross” environments during a migration.
Ultimately, you want your Office 365 migration batches to cause the least amount of friction, which is why it’s essential to analyze user data and plan effectively.
Quadrotech specializes in managed migration services for Enterprise organizations, including Office 365 tenant to tenant migrations, making recommendations for the best grouping and waving of users before moving mailboxes and archive data on a fixed cost, fixed-outcome basis.
If you’d like to discuss an upcoming project, please contact us and a member of our data migration team will be in touch.