The vendor’s migration plan fits on a single slide. It shows legacy PRI circuits disappearing on Friday night, replaced by SIP trunks terminating in redundant session border controllers. The timeline allocates four hours for the cutover and Sunday for testing.

For a 1,500-agent contact center, this plan is incomplete. The vendor is optimizing for a completed cutover. The business needs answered calls, captured recordings, delivered screen pops, and flowing workforce management data. The gap between those two outcomes is the actual project.

You are not migrating a phone system. You are migrating the recording platform, the workforce management feed, the CTI middleware, the IVR media server, and the fax server. A PRI delivers rigid, predictable ISDN D-channel data. SIP headers are extensible and vary by carrier. When the metadata shifts, downstream applications fail. On Monday morning, audio might be clear, but the CRM screen pops stop working because the old PRI delivered caller ID as a ten-digit string and the new SIP provider formats it in E.164 with a leading plus sign. The CRM lookup logic fails, and handle times double.

SIP does not fail loudly. A dead PRI circuit is binary and visible. A SIP failure is three percent one-way audio, or a session that establishes perfectly while the firewall drops the RTP media stream. These failure modes do not appear during Sunday testing with fifty internal calls. They appear at 08:02 on Monday when 1,200 agents log in. The session border controller’s digital signal processing resources max out because nobody sized the system for G.729 to G.711 transcoding on the interactive voice response leg under peak concurrency.

The project plan covers the sales representatives. It ignores the forty analog lines hanging off the legacy PBX for warehouse paging, security gates, and compliance faxing. The migration halts because nobody procured analog gateways for endpoints that were not in the PBX configuration export.

The number port is the only part of the migration that happens on someone else’s schedule. Carriers port numbers when their batch processes run. You cannot synchronize a massive technical cutover with a bulk number port. The migration architecture must decouple the inbound routing from the physical circuit swap.

The technology is settled. The decision is how to stage the move.

Big-bang cutover

Move all agents and numbers in a single weekend window.

  • Fits: A single carrier, no complex recording, no workforce management, no fax, a session border controller sized for peak transcoding, and a carrier that agrees to a weekend port.
  • Why it works: It is fast and requires less ongoing management of parallel environments.
  • Why it fails elsewhere: Every integration point becomes a simultaneous failure mode. If the CTI middleware breaks, the entire floor is broken.

Staged migration

Install the SIP trunks and session border controllers early. Route the new SIP trunks into the legacy PBX, converting SIP to PRI internally. Port the numbers weeks before the agents migrate to the new platform routing.

  • Fits: Multiple carriers, active call recording, complex CTI and workforce management integrations, and multi-site operations.
  • Why it works: The physical circuit swap is separated from the application routing change. Failures are contained to specific queues or sites, and comparisons between the old and new metadata are possible.
  • Why it fails: It requires managing a hybrid environment where media might trombone through the legacy PBX, increasing internal bandwidth and latency.

Parallel run

SIP and PRI both active, routing by group, queue, or time of day.

  • Fits: Strict regulatory recording requirements, high downtime intolerance, and a need for side-by-side quality comparison.
  • Why it works: Production traffic acts as the test, and fallback is immediate.
  • Why it fails: It is expensive to run both circuits, requires complex dial plan management, and forces agents to navigate two different routing behaviors.

What to verify before signing the plan

  • Session border controller capacity. Size for transcoding sessions, not just total sessions. If agents use one codec and the carrier uses another, the controller transcodes every call, cutting capacity significantly. Add call recording to the mix and the load increases further. Get the vendor to commit to a capacity number in writing with your specific codec mix and recording enabled.
  • Failover under load. Do not test failover by pulling a cable during a maintenance window. Force a failover during a simulated load test while calls are active. Verify where the call lands, what number the agent sees, and whether it records. Failover is a configuration, not a feature.
  • Metadata mapping. Check the exact SIP headers the new carrier provides against the parsing logic of the CTI, workforce management, and CRM integrations. Pay specific attention to caller ID formats, user-to-user information, and transfer states.
  • The inventory. Reconcile PBX configuration exports against recent carrier bills and live call detail records. An unowned number is still a production dependency.

A rollback plan assumes the thing you are rolling back to still exists. Before a number ports, traffic can often be redirected through the old carrier path. After it ports, or if the legacy PRI is being decommissioned, the rollback is a second SIP carrier you have not tested. Check the carrier’s decommissioning schedule before signing the migration plan.

The vendor’s cutover ends on Sunday night, but the business evaluates the new architecture starting at 08:00 on Monday.