KuberEva Book a call

Home/Documentation/TDM to IP migration

TDM to IP migration

A PRI does not map cleanly onto a SIP trunk. Capacity, signaling semantics, caller identity, fax, and emergency calling all change shape — and teams that treat it as a like-for-like swap find out during cutover.

Phase 1 — Inventory what you actually have

Start here, always, and budget more time than seems reasonable. The two questions are what is provisioned and what is in use, and they have different answers.

Phase 2 — Size the replacement properly

You are not buying 23 channels because you had 23 channels. You are buying enough concurrent sessions to meet a grade of service you have chosen deliberately.

The standard method is a two-step calculation. First determine the required trunk capacity for incoming calls using Erlang B against a stated grade of service — the probability that a caller gets a busy signal. Then calculate the bandwidth needed to carry that number of concurrent sessions.

InputWhere it comes fromCommon error
Busy hour traffic (Erlangs)Call detail records — busy hour call attempts × average handle time ÷ 3600Using a daily or monthly average instead of the actual busy hour
Grade of serviceA business decision. P.01 (1% blocking) is a common contact center targetNever stating it, so nobody can check the result
Seasonal peakTwelve months of history, not oneSizing to a quiet month and discovering it in December
Growth headroomExplicit planning assumptionBeing conflated with the grade of service, so both get fudged
The advantage you gain, if you use it TDM capacity is a physical fact — 23 channels are 23 channels. SIP capacity is a policy you configure, and it can be changed in minutes. That flexibility is genuinely valuable, but only if you enforce a limit through call admission control on the SBC. Without one, there is no ceiling at all until the invoice arrives.

Bandwidth

Concurrent sessions × per-session bandwidth, and per-session bandwidth depends on the codec plus the overhead of IP, UDP and RTP headers. G.711 gives you toll-quality audio at a bit rate comparable to a DS0; G.729 is far more efficient but costs quality, and that cost compounds if the call is transcoded more than once. Decide the codec policy deliberately and write down the resulting bandwidth requirement — including for the WAN links the media will actually traverse.

Phase 3 — Build the feature parity matrix

This is the single most valuable artifact in the project, and the one most often skipped.

List every signaling behavior genuinely in use today. For each: the SIP equivalent, the test that proves it works, and the result. Behaviors that cannot be reproduced get an explicit accepted-gap sign-off from the business owner — in writing, before cutover.

The detailed mapping is in ISDN PRI & BRI. The items that most often produce surprises:

Phase 4 — Numbers, 911, and the things with regulators attached

Number portability

Porting is a project in itself. Ranges port as ranges, and losing carriers are not motivated to hurry. Build the port sequence early, keep the losing carrier's records exactly matching the port request (a single address discrepancy causes a rejection), and plan for at least one rejection cycle.

911 continuity

This is the one that must not slip. Every number that can dial 911 needs a validated registered location that arrives at the PSAP, and the obligation differs depending on whether the endpoint is on-premises and fixed, on-premises and nomadic, or off-premises. Getting this right is covered in E911 & MLTS compliance — treat it as a parallel workstream with its own owner, not a cutover task.

Caller ID authentication

If your organization originates calls in a way that makes it a voice service provider, STIR/SHAKEN and Robocall Mitigation Database obligations attach. Most enterprises reach these through their carrier, but the attestation level your calls receive affects whether they are answered. See STIR/SHAKEN.

Phase 5 — Sequence the cutover

Options, in ascending order of risk:

Fig. 1 — parallel run versus flash cut where rollback is real
Parallel run — old path stays live PRI SIP first traffic PRI released ← rollback = a routing change, any time in here → Flash cut — everything at once numbers ported — rollback now takes days, not minutes
"We'll roll back if it goes wrong" is only true in the top diagram. Once numbers have ported, rollback is a porting project, not a decision — so the trigger conditions and the person authorized to call it have to exist before cutover night.
ApproachHow it worksTrade-off
Parallel run New SIP trunks installed alongside the PRIs. Route a small share of traffic across, then increase. Safest by a wide margin. Costs double connectivity for the overlap period — and it is worth it.
Number-range phased Port DID ranges in tranches, lowest-risk first — test lines, then internal, then customer-facing. Good balance. Requires the dial plan to tolerate a split state, which needs designing up front.
Site by site Whole sites move on their own dates. Natural for multi-site estates. Inter-site calling during the split period needs explicit design.
Flash cut Everything moves at once. Only defensible for very small estates. Rollback is theoretical rather than real once numbers have ported.
Define rollback before you need it "We'll roll back if it goes wrong" is not a plan once numbers have ported — porting back takes days. Real rollback means the old path is still live and a routing change returns traffic to it. Decide the trigger conditions in advance, in writing, and name the person who is allowed to call it. At 3am, nobody should be deciding whether this counts as bad enough.

Phase 6 — Set a measurable quality target

On TDM, the circuit works or it does not. On IP, everything can be nominally up while customers say calls sound terrible. That shift is the biggest single change in operating model, and it needs a number attached before go-live rather than after the complaints.

Agree a target MOS, and a latency, jitter and packet loss budget, as acceptance criteria. Measure them from the paths real calls take, not from a lab. See voice quality.

The acceptance checklist

  1. Feature parity matrix complete, tested, with gaps signed off.
  2. Concurrent session limit enforced by call admission control, at a number derived from a traffic study.
  3. Voice quality measured against an agreed target on real paths.
  4. 911 tested from every endpoint class, with the location that arrives at the PSAP verified.
  5. Fax tested end to end with multi-page documents, if fax is in scope.
  6. Failover tested by actually failing something, not by reading the design.
  7. Rollback trigger conditions documented and an owner named.
  8. Runbook handed to the team who will operate it.

Related reading

Cutovers go quietly when the parity matrix and the rollback trigger exist beforehand.

Book a call