
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 Category | Cisco UCM (Call Manager) | Microsoft Teams Phone | Parity/Notes |
Basic Calling | Yes (IP phones, softphones, legacy SCCP/SIP support) | Yes (Teams clients, SIP gateway for supported devices) | Parity |
Video Calling | Yes (native support) | Yes (native support, but limited in interoperability mode) | Parity, except Direct Routing (audio only) |
Call Transfer | Yes (attended, blind, early attended) | Yes (attended, blind) | Parity |
Call Forwarding | Yes (Unconditional, Busy, No Answer) | Yes (Unconditional, Busy, No Answer) | Parity |
Call Hold/Resume | Yes (with Music on Hold) | Yes (with Music on Hold) | Parity |
Three-way Conferencing | Yes | Yes | Parity |
Voicemail | Yes (Unity Connection, MWI) | Yes (Exchange/Teams Voicemail) | Parity; centralized voicemail possible |
Call Park | Yes | Yes | Parity |
Single Number Reach | Yes (ring desk phone & mobile/Teams) | Yes (simultaneous ring, call forwarding) | Parity |
Auto Attendant | Yes | Yes | Parity |
Hunt Groups | Yes | Yes | Parity; some advanced features may need review |
Call Queues | Yes | Yes | Parity |
Extension Mobility | Yes (login to any phone) | Yes (hot desking, Teams devices) | Parity |
Device Support | Broad (IP phones, video endpoints, analog devices) | Teams-certified devices, SIP Gateway for some Cisco phones | Parity for most common use cases |
Contact Center Integration | Yes (native & third-party) | Yes (via certified solutions) | Parity |
Unified Messaging | Yes | Yes | Parity |
Meetings | Yes (Webex, video conferencing) | Yes (Teams Meetings) | Parity |
File Sharing/Collab | Limited (Webex integration) | Yes (deep M365 integration) | Teams stronger in collaboration |
Security/Encryption | Yes | Yes | Parity |
Direct Routing | Yes (via CUBE, PSTN, SIP trunks) | Yes (Direct Routing, Operator Connect) | Parity; video not supported in CUBE interop |
Shared Line Appearance | Yes (shared lines across devices) | Limited/Not supported in interop mode | Cisco stronger |
Callback/Call Completion | Yes | Limited/Not supported in interop mode | Cisco 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.