Whether you’re on-premises PBX business (CUCM) or a cloud-first Webex business, the allure of migrating to Teams Phone can’t be ignored.

Often the final part of the Teams puzzle, businesses migrate to Teams Phone to genuinely unify their communications and benefit from a single platform.

Deciding is the easy part. Actually carrying out the implementation, however, can unveil some bumps in the road.

Here’s how to migrate your Cisco PBX setup to Teams Phone…

1. Audit your existing setup

Since you installed your Cisco PBX, there’s a good chance that multiple administrators have worked on it/owned it. 

If you’re one of those organizations, it can be eye opening of how much drift has happened within the system. 

There may be:

  • Old extensions
  • Trunks
  • Hunt groups

that are no longer being used. Without a full audit of the system, it is tough to know what needs to be moved and what needs to be pruned.

Utilizing automated tools, like Univonix, to do a discovery and gap analysis of the existing platform can speed the migration along by giving you an idea of what can be done quickly and what doesn’t need to be brought forward.

“Univonix is working out to be a great tool. Trying to do a large migration without it would be much more challenging.” – Director of IT Infrastructure, State/Local Government.

2. Check for feature parity

While introducing Teams (and Teams Phone) introduces new ways of working (async chat, voice notes, etc.), some PBX features are non-negotiable.

Check out the table below to make sure everything you need is supported in Teams Phone.

Feature CategoryCisco UCM (Call Manager)Microsoft Teams PhoneParity/Notes
Basic CallingYes (IP phones, softphones, legacy SCCP/SIP support)Yes (Teams clients, SIP gateway for supported devices)Parity
Video CallingYes (native support)Yes (native support, but limited in interoperability mode)Parity, except Direct Routing (audio only)
Call TransferYes (attended, blind, early attended)Yes (attended, blind)Parity
Call ForwardingYes (Unconditional, Busy, No Answer)Yes (Unconditional, Busy, No Answer)Parity
Call Hold/ResumeYes (with Music on Hold)Yes (with Music on Hold)Parity
Three-way ConferencingYesYesParity
VoicemailYes (Unity Connection, MWI)Yes (Exchange/Teams Voicemail)Parity; centralized voicemail possible
Call ParkYesYesParity
Single Number ReachYes (ring desk phone & mobile/Teams)Yes (simultaneous ring, call forwarding)Parity
Auto AttendantYesYesParity
Hunt GroupsYesYesParity; some advanced features may need review
Call QueuesYesYesParity
Extension MobilityYes (login to any phone)Yes (hot desking, Teams devices)Parity
Device SupportBroad (IP phones, video endpoints, analog devices)Teams-certified devices, SIP Gateway for some Cisco phonesParity for most common use cases
Contact Center IntegrationYes (native & third-party)Yes (via certified solutions)Parity
Unified MessagingYesYesParity
MeetingsYes (Webex, video conferencing)Yes (Teams Meetings)Parity
File Sharing/CollabLimited (Webex integration)Yes (deep M365 integration)Teams stronger in collaboration
Security/EncryptionYesYesParity
Direct RoutingYes (via CUBE, PSTN, SIP trunks)Yes (Direct Routing, Operator Connect)Parity; video not supported in CUBE interop
Shared Line AppearanceYes (shared lines across devices)Limited/Not supported in interop modeCisco stronger
Callback/Call CompletionYesLimited/Not supported in interop modeCisco stronger

By utilizing the information in Step 1 and doing a gap analysis with a tool like Univonix, you can help make this step go quickly in identifying the “low hanging fruit” as well as the areas where you might need to work with the business in order to improve their productivity via the new system.

3. Enable the Teams Phone environment

You now need to document your design choices and enable/configure the features within Teams.

It’s important to create a Decisions document at this step. It gives you, as well as anybody who comes after you, the understanding of what you want configured and the “why” behind it.

If you do this documentation up front, it allows for the components to be configured in an expedited fashion. 

Going off the Decisions document, you can now start configuring your environment. This must include all your Meeting Policies and Calling Policies, as an example.

If you use a migration tool, there’s no need to create/configure Auto Attendants or Call Queues as the tool will do that for you. 

If you’re not using an automated migration tool, this is where you need to create/configure all of your Auto Attendants and Call Queues.

4. Plan your number porting

If you are moving from a traditional carrier to Microsoft Calling Plans (or to an Operator Connect provider), you will need to plan out your phone number ports. These should align to the migration phases (below).

The first step is to request a Customer Service Record (CSR) from your existing carrier.

This will give you all of your phone numbers and the Billing Telephone Number (BTN) that each is associated with.

You will also need to ensure you know who will need to sign the Letter of Authorization (LOA). This will be the person who is approved on the account with the incumbent carrier.

Utilizing the CSR and your data from your existing system, you will need to map each phone number to a migration phase.

It’s important to note that you can only have one port request per BTN at a time. That means if you have multiple numbers associated with a BTN, you either need to move them together, or you will have to wait until the first port is done to submit a second port request for the same BTN. 

Note: This can cause your migration to take longer than anticipated. Also, the BTN should be the last number ported (by being in the last port request). 

Creating a spreadsheet with all of your phone numbers that shows what user and BTN the number is associated with can help you plan your phases.

In most cases, phone number ports can be completed within 14 to 30 days. In some countries, it can be in as little as 5 days.

Once you have your ports planned, you can start filling out LOA’s to submit as part of the migration phase.

5. Migrate a small number of users (test and validation)

This is where it starts to get real. 

In this step, we are migrating our initial batch of users. These are usually IT or IT friendly users who are “bleeding edge” types. We are focused in this step on just ensuring that everything is working correctly and as expected.

This is not a “Pilot”. The pilot group comes after this.

6. Set up meeting rooms and common area phones

Getting your meeting rooms deployed prior to getting users migrated helps prepare users for the change by getting them using Microsoft Teams on a daily basis. 

The first step here is making sure that you have a templated model for each room type in your organization. 

This can be as simple as:

  • Small/Huddle (2-4 people): BYOD or Kit room
  • Medium (4-10 people): Kit room based on a Bar system (i.e. Neat)
  • Large (8-16): Kit room (i.e. Shure Intellimix)
  • Extra Large/Complex: Custom (i.e. Shure or QSC)

Getting your common area phones placed and enabled is straight forward. This allows for devices to be seen in the environment and to start getting usage while having low impact to users.

Deploying common area phones, while not complex, can be time consuming so it’s good to place them before migrations start or in between the migration phases.

7. Run a Pilot

The point of a pilot is different from a proof of concept. 

With a proof of concept, you’ve already made sure the system works and your key business requirements will function. The pilot is where you test your migration and training with a smaller group of users across the business (not just IT). 

The feedback you get from the pilot is intended to help the main migrations go faster and smoother. 

Every organization is different and needs the messaging material adjusted to ensure complete and clear communication.

8. Migrate from Cisco to Teams Phone in phases

At this point, you’ve validated the solution, tested to ensure everything functions, and done a pilot to gather feedback on your process. 

With all of that done, migrations can now start taking place and should continue at a rapid clip until complete.

In this phase, you want to move quickly so that you are not having to maintain two systems and minimize the potential for confusion of call routing. 

The more users you can move in each migration, the better.

9. Test, train, and support new Teams Phone users

As you are migrating users, you need to make sure you are providing them the proper support for the transition.

You don’t need to explain to them what putting a call on hold is, but you do need to explain where the hold button moved to in comparison to their old device/system.

This might be as simple as providing a one-pager or an email communication. It also might mean holding office hours or drop-in support during the migration.

10. Decommission old Cisco kit

Once everyone has migrated to Microsoft Teams, it is now time to retire your Cisco kit. 

For most, the amount of integration into their environment is minimal, so going through the shutdown, removal process can be quite quick. 

Make sure to check for things like voicemail and video integrations that may have been done. 

Leaving artifacts in Active Directory can lead to issues in the future.

Do you need help planning your Cisco to Teams Phone migration?

At Cloud Revolution, this is our most completed job with our customers. We’ve been around the block a few times when it comes to migrating Cisco to Teams Phone.

That said, every business is unique. There will always be something new and we thrive with new challenges.

Cloud Revolution helps organizations unlock the full potential of Microsoft Teams and Copilot—guiding you from planning through adoption with seamless, outcome-driven solutions. 

As Microsoft Partner of the Year 2023 and a finalist in 2022 and 2024, we’re trusted worldwide to simplify collaboration and maximize ROI.

Book your free consultation here.