Switching wholesale VoIP carriers is one of those operations that sounds like a weekend project until you're actually in the middle of it with live traffic on the line. Flip the wrong switch and you're staring at dropped calls, a week of two carriers both billing for the same minutes, and a support queue full of resellers asking what happened. Done properly, the same migration is invisible — nobody downstream ever notices it happened at all. The difference isn't luck; it's whether you treated it as a staged process or a single flip of a switch.
Why People Actually Want to Switch
Carrier migrations don't happen on a whim — there's usually a specific trigger. A quality problem on a destination that never got fixed despite repeated tickets. A rate increase nobody agreed to. A compliance gap that's become a liability. Or, less dramatically, a better-engineered partner showed up with a rate sheet and route quality that made staying put the more expensive option. Whatever the reason, the operational challenge is identical every time: move live SIP trunks, DID ranges, and real call volume from one network to another without a gap where calls fail or get billed twice.
The One Mistake That Causes Almost Every Failed Migration
Nearly every migration that goes wrong shares the same root cause: someone treated it as an event — flip the routing table, cancel the old contract, done — instead of a phased process with checkpoints. A hard cutover means every call in flight at the exact moment of the switch, and every call placed in the window before the change fully propagates, gets thrown at the new carrier's completely untested routes with zero fallback if something's wrong.
The specific failures that show up are predictable once you've seen a few: a destination that looked fine in a sandbox test but falls apart once real production volume hits the new carrier's routing tables. SIP trunk re-pointing that quietly breaks authentication or codec negotiation mid-switch. And a billing overlap where both carriers end up invoicing for the same week of traffic because nobody set a hard decommission date on the outgoing contract. Every one of these is avoidable — none of them are avoidable if you're doing a single-flip migration.
Do the Boring Inventory Work Before You Touch Anything Technical
Before any routing change happens, build a complete list of everything tied to the outgoing carrier: every SIP trunk, every DID range, every destination-specific route, every custom least-cost-routing rule. Pull out your current contract and actually read the notice period and minimum-volume commitment clauses — many wholesale agreements carry a 30 to 90 day cancellation window, and starting that clock at the wrong time is one of the most common budgeting mistakes in a carrier switch.
While you're at it, map your traffic by destination and volume so you know exactly which routes carry the most risk if something breaks — a low-volume niche destination can absorb a rougher transition than the corridor generating most of your revenue. And document your current ASR, PDD, and MOS baselines per major destination on the carrier you're leaving. Without that baseline, you have no objective standard to hold the new carrier to — you're just trusting their word.
Give this a real timeline, not a weekend. A migration touching meaningful volume needs roughly one to two weeks of testing, two to four weeks of parallel running with gradual traffic shift, and a decommissioning phase that only starts once the new carrier has held quality benchmarks through a full billing cycle.
Run Both Carriers at Once — This Is the Whole Trick
The single technique that separates a clean migration from a risky one is running the old and new carrier live simultaneously, with the outgoing route still handling full production traffic while the new one comes online alongside it. Configure your softswitch or SBC with both as active routes, using LCR priority or percentage-based traffic splitting to control exactly how much volume goes where.
Start the new carrier small — 5 to 10% of traffic is a reasonable opening number — pointed at a handful of lower-risk destinations first. This limits how much damage a misconfiguration can do while still generating real production call data you can actually validate. And critically: keep the old carrier's trunk fully provisioned and untouched during this phase. It's your instant fallback, not something you've already started winding down.
Never Trust a Rate Sheet's Quality Claims — Test Against Your Own Traffic
Sales-provided quality numbers are a starting point, not a conclusion. Run structured test calls across every destination you're migrating, checking answer behavior, audio quality, DTMF passthrough, and fax or SMS compatibility if those ride the same trunk. Compare every result directly against the baselines you documented during planning — not against the new carrier's marketing claims.
Synthetic tests only tell you so much, though. Let the small slice of live traffic from your parallel-run phase accumulate for several days per destination before drawing any conclusions — a route that looks flawless across fifty test calls can behave completely differently once real subscriber traffic, with its natural mix of mobile, landline and VoIP-to-VoIP destinations, actually hits it at scale. Set explicit go/no-go thresholds before you start — ASR staying within 5 percentage points of baseline, PDD under 6 seconds for three consecutive days, for example — so the decision to expand traffic isn't made under deadline pressure on gut feel.
Shifting Traffic: Small Steps, Not One Big Jump
Once the new carrier has proven itself on a limited slice, increase its share in stages rather than jumping straight to full volume. A workable cadence is 10%, then 25%, then 50%, then 100%, with a 24 to 48 hour observation window between each step. This gives you multiple checkpoints to catch degradation before it touches your whole customer base, and every step is trivially reversible — you're just adjusting a routing weight, not undoing a decision.
When you actually re-point SIP trunks, get authentication credentials, IP whitelisting, and codec preferences updated on the new carrier's side before shifting any traffic weight, not at the same moment. If your setup relies on hostname-based routing, drop your DNS TTLs low in the days leading up to cutover, and temporarily lower SIP registration timers so devices re-register faster against new trunk settings if you need to roll back quickly.
Double Billing Is Avoidable — Set a Date and Hold It
Overlapping invoices are one of the most common, and most preventable, costs of a rushed migration. It happens when a contract auto-renews or a minimum-commit period resets while you're still routing real volume to that carrier, or when nobody formally terminates the outgoing contract until well after traffic has already moved. The fix is simple in concept: set a specific decommissioning date for the old carrier as soon as the parallel-run phase begins, tied to your actual notice-period obligations, and don't let that date slip.
On the other end of the migration, resist the urge to kill the old carrier's trunk the same day you hit 100% traffic on the new one. Keep the old route live but at zero traffic weight — fully provisioned, ready to reactivate in minutes — for a full billing cycle. That window is your safety net if a rare destination or edge case only surfaces once the new carrier is carrying everything. Only decommission once that observation period closes without incident.
The Sequence, As a Checklist
- Inventory every trunk, DID range and destination-specific route tied to the outgoing carrier; document ASR, PDD and MOS baselines per destination.
- Confirm notice periods and minimum-volume commitments on both carriers before setting any timeline.
- Fully provision the new carrier's trunk — credentials, IP whitelisting, codecs — without touching live routing yet.
- Run structured synthetic tests against your documented baselines across every destination.
- Enable parallel routing at 5-10% on lower-risk destinations, keeping the old carrier fully live as fallback.
- Monitor real production CDRs for several days per destination against pre-set go/no-go thresholds.
- Increase traffic share in stages — 10% → 25% → 50% → 100% — with a 24-48 hour observation window at each step.
- Hold the old carrier at zero traffic weight for a full billing cycle after reaching 100% on the new one.
- Formally decommission the outgoing contract only after that observation window closes cleanly.
Treated this way, a migration becomes a series of small, reversible steps instead of one irreversible flip — which is exactly what makes it low-risk instead of a gamble.
Where This Fits at Laykatel
We think about carrier onboarding the same way — new customers get test credentials to validate ASR and quality on their real top destinations before ever committing production volume, rather than being asked to trust a rate sheet on faith. If you're migrating traffic onto our A-Z termination, that same parallel-run discipline applies: keep your existing carrier live, shift volume gradually, and let real CDRs — not sales claims — decide when you're ready to go further.
Frequently Asked Questions
How long should a carrier migration actually take? For meaningful volume, plan on four to eight weeks end to end — one to two weeks of testing, two to four weeks of parallel running with gradual shift, and a full billing cycle of observation before decommissioning. Compressing this timeline is the most common cause of migration incidents.
What is parallel routing, exactly? Running both the outgoing and incoming carrier live and provisioned at the same time, using traffic-splitting or LCR priority to control the split. It prevents downtime because the old carrier stays available as an instant fallback the entire time, instead of being switched off the moment the new one goes live.
How do I actually avoid double billing? Set a specific decommissioning date as soon as the migration starts, based on your contract's notice period, and hold to it. Time the switch around contract renewal dates where possible, and don't leave the old route carrying real traffic weight after the new one has effectively taken over.
Is testing on real traffic actually necessary, or do synthetic tests cover it? Both are necessary. Synthetic test calls catch obvious problems — broken authentication, bad audio, DTMF failures — but only real production traffic, even a small 5-10% slice, reveals how a route performs under the actual mix of mobile, landline and VoIP-to-VoIP destinations your subscribers generate.