When it comes to migrating to Teams Phone System, there are a number of different approaches. Some are slow and steady, some are by site or location (if there are multiple locations in play), and some are big-bang flash cuts. Slow and steady is often the preferred approach, but the longer the coexistence period with the legacy voice solution, the greater the risk for inefficiencies and anomalies. Flash cut risks are self-evident - if something goes wrong, everyone knows. The results of a misstep on a flash cut can be disastrous for long-term viability of the new technology, as well as for the IT staff attempting to implement it.
Enabling frequently prescribes a "confidence-building" approach. The idea is to start with a small group of users, and once successfully migrated, build upon the success. The approach typically follows this pattern (but can vary):
- 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).