Switch Migration Without Downtime: A Phased Playbook for Independent Telcos

A phased switch migration playbook for independent telcos moving off legacy class-5 and DMS-style platforms — without a cutover weekend, a truck convoy, or a single dropped subscriber.

Most independent ILECs and regional CLECs know they need to modernize their voice switch. The old class-5 is still doing its job, but parts are harder to source, vendors are sunsetting support, and every year the staff who know the switch intimately get closer to retirement. The question isn’t usually “should we migrate?” It’s “how do we do it without blowing up the business?”

The fear of a bad cutover runs deep, and it’s earned. Every operator has heard a story about a weekend cutover that went sideways — 911 mis-routing, CNAM flapping, a whole wire center down for 6 hours. The good news: in 2026 you don’t have to do it that way. Phased migration is the approach we’ve run for independent telcos across the U.S., and it’s how you move from legacy to modern voice with no perceptible subscriber downtime and your regulatory posture intact.

The core idea. You don’t replace the switch on a cutover weekend. You bring a modern softswitch / SBC fabric online in parallel, move feature groups and number ranges across in controlled waves, verify each wave in production, and only retire the legacy switch when every last subscriber, trunk group, special-service circuit, and regulatory flow has been cleanly transitioned — which is typically 6–18 months later.

Why phased beats big-bang every time

The big-bang cutover appeals to executives because it has a defined end date. It fails in practice because the legacy switch carries an enormous amount of invisible configuration — special service circuits, custom dialing plans, alarm-line translations, 911 trunk group oddities, operator services, inside wire plans — that isn’t documented anywhere except in the switch itself. A big-bang tries to move all of it in one go, discovers the undocumented pieces at 3:00 AM on cutover morning, and ends with a panicked rollback.

Phased migration assumes you’ll discover things you didn’t know. It gives you time and structure to learn the switch as you move off it. Here’s the high-level shape of a typical phased engagement:

The critical insight is that Phase 2 through Phase 5 can run in production on the new platform while the old switch keeps running for everything that hasn’t moved yet. There’s no “both platforms can’t be up” hard dependency. That’s what buys you the gradual cutover.

Phase 0: Discovery — the two weeks that saves the project

Every bad migration we’ve seen started with an inadequate discovery. Every successful migration we’ve done started with a team spending two weeks understanding the switch before anyone touched a config file.

The minimum discovery output is a written inventory covering:

• Every trunk group on the switch — SS7, ISUP, PRI, SIP, interconnect, operator, 911. Each with the traffic volume, the far-end carrier, the route, and the tariff/contract reference.
• Every subscriber line — customer, class of service, features, special service codes, billing treatment, CNAM, LIDB settings.
• Special services — alarm trunks, elevator lines, hospital hot-lines, analog leased lines, hot-cuts, centrex, custom dial plans.
• Regulatory traffic — access minutes going to NECA cost pools, carrier-to-carrier traffic, state 911 surcharges. This is where you flag anything that could move the regulated cost recovery picture, and you bring in your NECA tariff advisor before any of it gets reconfigured.
• Number inventory — every NPA-NXX and thousand-block you hold, plus utilization data and LERG ownership.
• Operator/admin conventions — translation patterns, toll-free routing, intercept messages, feature group codes. These are the things that are only in the heads of the two people who’ve run your switch for 25 years.

The “retiring engineer” risk. If the person who knows the switch best is within 3 years of retirement, move the discovery phase forward and capture everything on video, in documentation, and in a knowledge-transfer session before that person leaves. The worst migrations we’ve seen came from operators trying to migrate off a switch they didn’t fully understand anymore.

Phase 1: Build the replacement in parallel

The goal of Phase 1 is to have a fully interconnected, regulatory-compliant voice platform that is ready to take traffic but isn’t carrying subscriber traffic yet. The platform typically includes:

• A class-4/5 softswitch or cloud voice core
• Session border controllers at the edges
• SIP trunk groups to your upstream carriers and peers
• E911 trunks tested end-to-end with the local PSAP
• NPAC connectivity and LSR/LSO workflow
• STIR/SHAKEN signing infrastructure
• LIDB/CNAM feed
• Monitoring, billing integration, trouble ticketing

By the end of Phase 1, you can place a test call end-to-end, see the call authenticate with STIR/SHAKEN, route through the new platform, reach its destination, and show up with the right CNAM. You haven’t moved any real subscribers yet.

Phase 2: Pilot wave — you go first

Rule number one of pilot waves: you eat your own dog food first. Migrate your own office lines, your own fax, and your own on-call engineer’s business number before you touch a single paying subscriber. Every unexpected behavior you’re going to find will show up during the week you’re on the new platform yourself, and you’ll fix it without anyone else noticing.

Then move a friendly commercial pilot group — 5 to 15 customers, ideally with a range of feature use (a small law firm with multiple lines and a PBX, a veterinary clinic with a single multi-line, a restaurant with a hunt group). Stay on the phone with each pilot customer for the first week post-cutover. Fix anything you find before you expand the wave.

Phase 3: Commercial waves — the main event

Commercial waves are where the bulk of your business voice migrates. Three rules make this phase go smoothly:

1. Group waves by something meaningful. By wire center (if you’re doing a fiber overbuild concurrently), by class of service (centrex customers in one wave, trunk customers in another), or by account size (top-100 by revenue get named-account-manager cutovers). Don’t migrate in alphabetical-by-customer order — it buries the risk in the middle of the migration.
2. Write a subscriber-specific cutover runbook for every wave that includes the customer name, the numbers, the features being migrated, the expected behavior on the new platform, and the rollback steps if anything breaks.
3. Monitor every wave in production for at least 72 hours. Call quality metrics, failed-call rates, 911 test calls, CNAM sampling, customer-reported issues. A wave isn’t “done” until 72 hours of clean production have passed.

Phase 4–5: Residential and special services

Residential POTS migration is typically slower and often coincides with a fiber overbuild (USDA Reconnect, BEAD, or state broadband funding). If you’re not overbuilding, you may choose to leave residential on the legacy switch indefinitely — depending on your voice vendor’s support roadmap and your NECA position.

Special services — alarm trunks, elevator lines, E911 access lines, operator services, inside-wire plans — get their own phase because each one has a counterparty (the alarm central station, the elevator vendor, the 911 authority) that has to coordinate their end. Build the coordination calendar in Phase 0 so you know who you’re calling in month 10.

Phase 6: Legacy sunset

Only after every subscriber, trunk group, and special service has been cleanly on the new platform in production for at least 30 days do you shut down the old switch. The final steps are mechanical: LERG cleanup for migrated NPA-NXXs, NPAC ownership confirmation, final 499 reporting reconciliation, switch decommission, and removal of old interconnect agreements. Keep the old switch powered (but without live subscribers) for 30–60 days after the last migration as a rollback safety net.

Cost and timeline, honestly

Every migration is sized by subscriber count, feature complexity, and how much documentation already exists. A typical independent ILEC with 3,000–15,000 access lines runs a phased migration in 6–18 months at a total program cost that varies widely. The two biggest drivers of cost are:

• Discovery depth. If the switch is well-documented, discovery is 2 weeks. If it’s not, discovery can run 6–8 weeks and is worth every hour.
• Special service volume. A telco with lots of alarm trunks, operator services, and centrex customers migrates slower than one with mostly POTS and SIP trunk customers.

What’s remarkable about phased migration is that the subscriber experience doesn’t get more expensive with complexity — complexity shows up in your project ledger, not in dropped calls for your customers. That’s the whole point of going slow.

Frequently asked questions

Do we have to retire the legacy switch at the end?

Not necessarily. Many operators keep the class-5 running for residential POTS and regulated traffic while the cloud platform carries commercial and UC. The “hybrid” end-state is legitimate and often preferred, especially if your current switch is still within its support window and your NECA position is calibrated to it. Retirement becomes the right answer when support runs out or when you’ve substantially modernized your wire centers.

What happens to our NECA / settlement flows during the migration?

It depends on which traffic moves and how your traffic is reported. These rules are state-specific and still evolving as carriers modernize, so we don’t predict settlement outcomes for any specific operator. Bring your NECA advisor into Phase 0 — they need to see the planned traffic topology before it’s built. Our companion post on NECA, LATA, and FCC filings during switch modernization covers the framing we use.

What about 911 during cutover?

911 trunks are migrated individually with end-to-end PSAP testing before any subscriber traffic moves to the new trunk group. In practice, we often bring the new 911 trunks up in parallel with the old ones and only cut subscriber waves onto the new trunks after the PSAP has independently confirmed test delivery on the new path.

Can our existing staff run the new platform?

Usually yes, with training. A modern softswitch / SBC fabric is more approachable than a class-5 for someone who grew up on the class-5 — the web UIs, the APIs, and the log formats are what most engineers under 40 already know. The legacy switch knowledge is where the real transfer work happens, which is why Phase 0 focuses on capturing it.

What’s the first step if we want to explore a phased migration?

A two-week paid discovery. Our team spends that time on-site (or remote) documenting the switch and producing a written migration plan. If the numbers don’t work for you after the discovery, you keep the documentation. Call (844) 450-3527 or visit our Carriers page.

Related: our business voice retention playbook for defending the commercial book during modernization; our 2026 compliance checklist for the regulatory ground you need to hold; and the ILEC vs CLEC primer for non-technical stakeholders.