Incompatible Gateways

Teams introduces a new feature known as Direct Routing that allows existing Session Border Controllers (SBCs) to be integrated into teams. In practice, however, it should be noted that some of the SBCs and gateways already in use in the company might not be supported by Teams or might require a software upgrade. SBCs can also be linked to Skype for Business Online; however, this requires admins to provision a local Skype for Business server or integrate a special edition of Skype for Business (known as a Cloud Connector) between the SBC and the Microsoft cloud (Figure 2). This scenario is referred to as Hybrid Voice. Based on direct routing, the existing SIP trunks or standard ISDN (E1) connections in the enterprise can be integrated into Teams, as can existing phone systems and analog end devices in the company.

Figure 2: The previous communication model in Skype for Business.

Microsoft recommends a local breakout (direct connection) to the Internet for every office or branch office on the network (Figure 3). The idea is to improve real-time communication in Teams. Microsoft's primary goal in terms of the network design for Teams is to minimize latency by reducing the round-trip time (RTT) from the user's network to the Microsoft Global Network (Microsoft's public network backbone that connects all Microsoft data centers and cloud application entry points). The concept of local breakouts is different from the "hub-and-spoke" network model that large enterprises have implemented for local Skype for Business use. For this reason, when migrating from Skype for Business to Teams, you need to assess the effect of network architecture changes on network operations.

Figure 3: Changes to the communication model for Microsoft Teams.

Important Migration Issues

With all the arguments that Microsoft has for switching to Teams, practice has shown that, although a quick switch from Skype for Business to Teams is possible, the pitfalls of such a migration lie, as always, in the details. Sometimes the ad hoc approach works, but often enough such an approach results in chaos. The following integration questions therefore need to be an integral part of every Microsoft Teams installation:

• Have the expectations been defined (in writing)?
• Are the management's expectations for the project known?
• Has interoperability been planned properly, and are appropriate verification functions defined?
• Is it possible to pilot Teams initially with IT staff?
• Will the results from the pilot users be incorporated into improving the migration strategy?
• How can users be told what to expect and when?
• Are the results regularly measured and documented?

The planning and implementation of the above steps naturally requires time and commitment. Doing the right thing always means going the extra mile. A step-by-step migration requires more work in terms of evaluating, testing, managing, and implementing Teams, but it significantly improves the chances of achieving satisfactory results.

Migrating from Skype for Business to Teams

The effective use of Teams requires an understanding of how aspects such as the configuration of Teams and the channels it uses can be designed correctly and how messages can be communicated effectively within Teams. When migrating to Teams, users are often confused. Let me repeat: Teams is not the next version of Skype for Business. Teams offers additional features and new functionality, although Teams features can supplement and overlap the familiar Skype for Business features. If a company is already using Skype for Business and wants to introduce Teams, the following migration paths are possible: coexistence with Teams, parallel operation of both solutions, or the exclusive use of Teams.