Cloud Calling Migration

Moving a phone system off premises is not a product decision. It is a sequencing problem with a vendor-set deadline attached, and the organizations that handle it well are the ones that scoped the awkward parts before they committed to a cutover date.

This page sets out the order that work runs in, and links to the detail behind each step: the migration tooling, the endpoint eligibility rules, the PSTN options, the analog and life-safety devices nobody counts, and the licensing decisions that are hard to reverse once signed.

Why this is on your desk now

Most migrations start with a lifecycle date rather than a strategy. The appliance families that mid-market sites tend to run have published end-of-life milestones, and the date that constrains planning is usually not the one people quote. The last day a support contract can be renewed falls well before the last date of support. Once renewal closes, the platform keeps running and the risk position has changed.

The second driver is carrier-side. Copper facilities are being retired, and the analog lines that quietly support elevator phones, alarm dialers and fax machines are getting more expensive and harder to order every year.

A lifecycle date tells you when the work has to be finished. It does not tell you when to start. That comes from counting backwards through the sequence below, and the step that decides the length of the count is number porting.

The order the work runs in

The steps overlap in practice, but the dependencies between them are fixed, and the two that no amount of effort compresses sit near the front.

1. Discovery. An endpoint export including hardware versions, an analog circuit inventory, an integration inventory, and a number inventory broken out by carrier account. Everything after this is priced from it.
2. Carrier records pulled. Request the customer service records from every account in the first week. They are frequently wrong, and correcting a service address or a listed name takes calendar time that cannot be bought back later.
3. Design and licensing. Seat mix, PSTN approach, location model, emergency calling design, and the plan for every analog circuit. This is the last point at which changing your mind is inexpensive.
4. Porting submitted. As early as the design allows, running in parallel with everything below it.
5. Prerequisites. Firmware levels, directory synchronization, and network readiness for real-time media. On a distributed estate the firmware work alone runs for weeks, because a phone has to be on the network to receive it.
6. Pilot. One site or one department, chosen to include at least one awkward case: an analog circuit, a recorded line, an integration.
7. Waves. Batched, with the old platform still in service behind them.
8. Decommission. Only once the last analog device and the last integration have been confirmed working, which is later than the date the last user moved.

How long the sequence takes depends on the size of the estate and on how much analog and integration debt is sitting under it. Nobody can put a duration on it before discovery has finished, and that includes us. The implementation and migration work itself is the predictable part.

Why porting sets the calendar

Number porting is the only task on that list with somebody else's queue in front of it. The losing carrier controls the pace. The records have to match what that carrier holds on file, down to the service address, and one mismatch sends a request back to the beginning. An organization that has acquired anything usually holds its numbers across more accounts than anyone remembers, and every account is a separate request on its own schedule.

Every other step can be compressed by adding people or narrowing scope. Porting cannot. Treat the port dates as the fixed points, build the cutover windows around them, and work backwards from there to a start date. If that arithmetic does not reach the lifecycle deadline that started the project, the answer is a support extension or an interim step, and design is the cheapest time to find that out. The options themselves are compared in the PSTN piece.

What to count before you ask anyone for a quote

The first conversation about moving calling to the cloud usually happens before anyone has counted anything. Six things decide what the project looks like and what it costs. All six can be gathered inside your own organization, and gathering them first is what makes the quotes you get afterward comparable to each other. Every item changes the price, two of them change the design, and none of them needs a vendor in the room.

• Sites. How many buildings, and which of them have to keep dial tone when the circuit into the building fails. A site with that requirement needs hardware designed in on site, and it is cheaper to say so at the start.
• Users, split by type. A headcount does not answer this. Count how many people need a desk phone, how many need only a software client, how many need both, and how many extensions belong to a room instead of a person. Licensing is priced against that split.
• Analog devices. Elevator phones, fire and burglar alarm dialers, fax machines, gate and door intercoms, overhead paging. They appear in no user count, most of them are owned by facilities rather than IT, and none of them migrates. This is the item that moves budgets, and it has an article of its own.
• Call flows. Every published number and whatever answers it: auto attendants, hunt groups, after-hours routing, the number printed on the back of a badge. Each one needs a named owner who can confirm it is still correct.
• Carrier contract end dates. Per account, not per company. An organization that has acquired anything usually holds numbers across more accounts than anyone remembers, and the term commitment on each account decides whether those numbers can move on your schedule.
• What you are running today. The call control platform, the version it is on, and the support dates attached to it. That last date is usually the reason somebody asked for this in the first place.

Anyone who prices this work before those six answers exist is estimating from assumptions, and that includes us. We will give you a budgetary number if the funding cycle demands one, and it will move once discovery is done. The item that moves it is almost always the analog list.

Where to start

If you are early, read the migration overview first, then the analog inventory piece — in that order, because the second is what changes your budget. If you already have a platform decision and need to solve numbers, start with the PSTN comparison.

Related: Collaboration & Unified Communications · Managed Services & Support · Networking & Connectivity

Articles in this topic

• CUCM to Webex Calling Migration
  A CUCM to Webex Calling migration is three projects, not one. The tooling, which phones convert, PSTN options, licensing traps and what never moves.
• Analog Endpoints and Cloud Calling
  Fax, elevator and emergency phones do not migrate to cloud calling. How to inventory analog endpoints and choose between ATAs, gateways and POTS lines.
• Navigating PSTN Migration with Webex Calling
  Three ways to reach the PSTN from a cloud calling platform, and what each changes about support, number ownership, contracts and the porting schedule.
• Cisco BE6000 and BE7000 End of Support Dates
  Cisco BE6000 and BE7000 end of support dates by generation, why the embedded virtualization licenses ended 31 March 2025, and what the move to cloud costs.
• What Moving to UCaaS Actually Involves
  What a UCaaS migration involves in order: the inventory taken first, what the decision turns on, why porting sets the schedule, and the first month after cutover.