Many projects fail not because of lack of effort or expertise but rather due to lack of planning. However, we do think it’s worth exploring whether too much planning can thwart your efforts in moving to Microsoft Teams.
We regularly work with large enterprise customers that have deployed Microsoft Skype for Business Server along with Enterprise Voice. In choosing Skype for Business as their voice platform, these organizations went through detailed decision-making processes comparing the pros and cons of Skype for Business against other options. They completed careful planning along with detailed architecture and design of the on-premises solution, and then ultimately executed on their plans, deploying a number of servers into their data centers (sometimes 100+ servers if providing voice services to more than 100,000 users). These were big IT projects often taking multiple years.
Given the recent Skype for Business Online end-of-life
announcement, now these same organizations must decide how to evolve their current UC platforms. Options are limited to migrating to Skype for Business Server 2019 or Microsoft Teams, or moving off the Microsoft stack and onto an alternative platform.
Those organizations that choose to remain on the Microsoft stack and would also prefer a cloud solution will need to plan and execute their upgrade to Teams. This is where we’re seeing some analysis paralysis creep into planning and assessment exercises.
Teams is a 100% cloud-based solution. Unlike Skype for Business Server, Teams doesn’t require the use of servers.
If an organization has been using SIP trunks for public switched telephone network (PSTN) access with Skype for Business Server (aka, “bring your own SIP trunks”) to make and receive PSTN calls, then it’ll need an on-premises session border controller (SBC) if it wishes to be able to make and receive PSTN calls from Teams using the same SIP trunks (Microsoft calls this
Direct Routing). A limited exception is that some SIP trunking providers (for example,
ThinkTel or
NuWave Communications) virtualize the required SBC; in such cases, there’s no requirement for on-site SBC hardware when transitioning to Teams. Alternatively, in
select geographies (12 countries at last count), Microsoft can act as your carrier. No on-premises hardware is necessary in this case, either.
We’ve participated in Skype for Business Server deployments for hundreds of offices. These engagements require months of planning, including a significant architecture and design effort. This work culminates in detailed design documents of 100 or more pages, required to capture all configuration aspects of a deployment.
When it comes to the planning and design for Microsoft Teams, a level of due diligence work certainly needs to be done; however, our experience is that the technical effort to plan a Teams deployment is significantly less than the effort required to deploy Skype for Business Server. As a cloud service, Teams eliminates the complexities of planning for application servers and many of the related network connectivity details.
How Should You Plan for Teams?
Microsoft has made many
good planning resources available on how to roll out Microsoft Teams. The general flow you’ll follow looks like this:
Plan -> Prepare -> Pilot -> Deploy -> Upgrade -> Post Upgrade
Plan
This phase will involve bringing together the appropriate project stakeholders and defining the plan in terms of scope, timing, and goals for your upgrade journey to Teams. This includes the following steps:
- Identify the appropriate project stakeholders
- Define your project vision and scope
- Define project goals (set specific measurable results, such as: We’ll migrate 5,000 users to Teams by Oct. 1, 2021, with an average user satisfaction rating of four out of five or better)
- Identify risks and mitigation plans
- Lay out a project plan with milestones
- Define the appropriate upgrade strategy and coexistence with Skype for Business
Prepare
This phase will involve evaluating your organization’s readiness for Teams. Specifically, you should look at the following:
- Teams technical onboarding — ensure your environment is ready for Teams; complete Discovery Questionnaire
- Prepare your network for Teams — do you have enough bandwidth? Do you need to account for any firewalls or proxy servers in place today?
- Assess your organization’s readiness for change — prepare the messaging for user communities
- Announce pending launch of Teams — Communicate what’s coming, why, the user benefits, and training schedule!
- Prepare your IT staff for Teams
Pilot
In this phase, you’ll run a pilot test to confirm that your organization is ready for Teams. Running a pilot test will help you validate if your expectations of Teams aligns with the actual user experience. A pilot test gives you the opportunity to assess and refine your rollout plan. In the pilot phase, you should:
- Document your pilot logistics
- Select pilot users and scenarios you want to evaluate
- Design a test plan and feedback survey
- Create a pilot communications plan
- Conduct the pilot (remember that you’re testing the technology, as well as the communications, training, and your organization’s affinity for change)
- Assess learnings and modify your ongoing deployment plan as required
Deploy
In this phase, you’ll run Teams alongside Skype for Business. You’ll need to select the coexistence mode most appropriate for your organization (see our previous No Jitter article, “
Moving to Teams: Upgrade Paths, Untangled”).
In this phase, you’ll:
- Formally announce the launch of Teams
- Enable the appropriate coexistence mode for your users
- Monitor the Teams roadmap to identify the appropriate time for your organization to move to Teams
- Drive adoption with Teams champions and ongoing communications
Upgrade
This will be the final step in your journey to Teams. The upgrade to Teams will have you moving your on-premises users to Office 365. Their primary chat and calling functionalities will now be in Teams. Your organization will no longer use the Skype for Business client once you’ve migrated all users and meetings to Teams. This might look something like this:
- Complete all the pre-upgrade activities identified in previous phases
- Communicate to users in the various upgrade groupings. Keep the communications flowing during the upgrades
- Enable the Teams-only mode for each upgrade group
- Survey your users about their experience with the process, and make changes as necessary for subsequent groups to be migrated
Post Upgrade
After you’ve completed your upgrade, take some time to evaluate if you’ve met the goals you developed in the planning phase. Implement a plan to achieve any goals that you didn’t meet. Work with your network team to understand if the network impact you planned for is in line with what it’s seeing post upgrade. Lastly, continue to monitor for new Teams features planned for rollout.
Planning is good. Too much planning can lead to analysis paralysis or invested effort that exceeds the return on investment, unnecessarily delaying your upgrade. We believe following the above process will simplify your journey to Teams.
We spend our days working with organizations that are trying to figure out their next steps for communications and collaboration and then helping them achieve success. Are you wrestling with any key questions or encountering insurmountable technical or political obstacles on your upgrade journey? Consider sharing your challenges below.
