- Proof of Concept – This entails a small group of 10-20 or so users, typically all in the IT department, possibly including some favored early adopters.
- Pilot – This would be a larger group, typically includes users from the broader business (not just IT), and depending on the size of the organization could be 20-50 users, or up to as many as 10%-15% of the total user population.
- Mass Migration Phase – Here the remaining user population is split up into groups or batches of users in increasing increments. The “confidence-building” shows some improved efficiencies over the slow-and-steady approach. If a Pilot was 50 users, the next group might be 100 users. The next might be 200-300 users, and a final group might be 500-1000 users. For very large organizations (several thousand users), repeat the largest group until migrations are complete.
- The size of the largest batch is typically a function of the help desk staff and readiness to support the Teams migration. In most cases, we recommend the largest batch size be about 1000 users, so that the help desk can readily respond to any user issues on Day 1 following the cutover. However, companies with well-staffed and well-prepared help desks can increase batch sizes based on comfort and the results of the previous cut events. Enabling has had clients with large batches of 2000+ users in a single cut event after building their confidence and reviewing the metrics from prior cutover events.
What’s nice about the confidence-building approach is that it is not mutually exclusive to site-by-site migrations, and the batch sizes can be flexible. For instance, if you have a set of smaller batch sizes, you can look to use a smaller site or sites to fill in the user count. If “Group 1” should ideally be about 200 users, and you have a site of 60 users and another of 100, that’s probably “close enough” to include both sites as “Group 1”. Similarly, larger sites (offices or buildings with 500 or even 1000 users) should be held for later in the process, when the group or batch sizes can accommodate all the users in the site at one time.
For locations that use Direct Routing with Session Border Controllers (SBCs) and existing SIP trunks, it may be more expedient to keep all users in a single site in a single migration batch, since you have to do some routing configuration on the SBC(s) to support the user migrations – it’s often easier to send “all” SIP traffic to Teams, rather than to split traffic by DIDs or ranges between two systems (Teams and the legacy PBX). It’s also less risky from a routing perspective, and reduces the number of times you need to reconfigure the routing in the SBC(s).