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.

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.
• Webex Calling: Upgrade your Business Edition to the cloud
  What you stop running when a small on-premises calling appliance moves to the cloud, what you give up, and why a support date usually forces the decision.
• 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.
• Connect with cloud calling
  What to have counted before you ask anyone to price a cloud calling move: sites, users by type, analog devices, call flows, contracts and call control.