Introduction
Helix Logistics is a regional freight operator with three depots — one in Atlanta, one in Charlotte, one outside Dallas — and an inbound dispatch team that handles roughly 1,400 calls a day. Their incumbent system was a 14-year-old on-prem PBX with five years of accumulated dial-plan complexity, two retired engineers' worth of tribal knowledge, and a maintenance window that had become impossible to find.
The constraint was the freight calendar. Helix runs a "Tuesday picks, Thursday loads" rhythm with their largest enterprise customer, which represents 38% of their revenue. Any cut-over that touched dispatch had to start after the Thursday load window closed and finish before the Tuesday morning picks opened. We had 64 hours, and most of them were on a single weekend.
When the project kicked off in late February, the customer's Director of Operations told us: "If you take this down past Tuesday at 6am, you will have cost us about $1.6M in delayed loads. Don't do that." We did not do that.
Pre-flight: six weeks of mapping the existing dial plan
No cut-over runs in 64 hours unless the six weeks before it run perfectly. We spent the first four sessions reverse-engineering Helix's dial plan from PBX configuration exports and call-detail records. The on-prem system had 412 active routing rules. About 80 of them were live. The other 330 were various ghosts — old contractors, retired routes, holiday hours from 2019 that had never been removed.
The breakthrough came from a quiet observation: in the last 30 days of CDRs, only 47 distinct routing outcomes had been hit. We could replicate the meaningful behaviour of the system with 47 rules, not 412. Walking the customer through that simplification — and getting them to sign off on retiring the 330 unused rules before the cut-over, not during it — turned out to be the highest-leverage hour of the entire project.
The dial plan we built in Ajoxi had 53 rules at cut-over. The extra six were defensive: catch-alls for the unusual cases that the CDR analysis had not seen but the customer's ops team knew about. Each one had a named owner on the Helix side who would be paged if it fired in production.
The rehearsal that found the missing rule
Two weeks out we ran a full rehearsal: a Saturday morning where the customer routed 5% of their live traffic to the new system in parallel with the old. Both systems answered, both systems recorded, and the team compared outcomes call by call.
The rehearsal worked, mostly. It also surfaced one rule the dial-plan reverse-engineering had missed entirely: the after-hours dispatch line for the Dallas depot was routing through a Charlotte queue between 11pm and 4am, because of a temporary cover arrangement that had been put in place in 2021 and never undone. Nobody at Helix could initially explain why a Dallas call was ringing in Charlotte. The CDRs showed it as expected behaviour, so the analysis had reproduced it without flagging it.
We added that rule explicitly to the new dial plan and got formal sign-off. If we had missed it, the cut-over would have left the Dallas night dispatcher unreachable for the first eight hours of the new system. That is exactly the kind of mistake that ends careers.
The cut-over weekend
The window started at 6pm Friday. The order of operations was published a week in advance and printed on a single laminated card that lived on the bridge call. Every operator on the call had a copy in front of them.
Friday 6pm — number port window opens
The first action of the weekend was committing the LNP requests we had submitted ten business days earlier. Once the ports completed, inbound calls would start arriving at Ajoxi. We had pre-staged the routing so that any call arriving during the port window would be answered by an interim message — "thank you for calling Helix, we are momentarily unavailable, please leave a message" — and the voicemails would be transcribed and pushed to dispatch first thing Monday.
Saturday 9am — old PBX disabled
With ports completed at 2am, the old PBX was deliberately taken offline at 9am Saturday — not for the cut-over, but for archival. The customer had asked us to preserve a full read-only snapshot of the old configuration in case audit came calling. We exported and verified the snapshot before we touched anything live.
Saturday 11am to Sunday 8pm — live dial-plan deployment
The dial plan went live in stages. Atlanta first, then Charlotte, then Dallas — staggered by four hours each. The staggering was deliberate: it meant that if Atlanta blew up, we could roll Atlanta back without affecting the other two depots. A simultaneous cut-over would have made rollback a different question.
Atlanta took 90 minutes. Charlotte took 70 minutes — the team had momentum. Dallas took six hours. The hold-up in Dallas was the missing rule from the rehearsal, except a sibling of it: there was another historical cover arrangement we had not found, which routed certain customer-specific direct lines through a queue that no longer existed. We had to build the queue, route the direct lines, get the customer's ops manager to test, and then sign off.
What happened Monday morning
Tuesday picks opened at 6am Eastern. Dispatch answered the first call of the new system at 6:04am. The TAM team — three of us, on a bridge call from three different time zones — listened to the first hour of inbound traffic, watching the call-detail records populate in something close to real time. Every call routed correctly. Every voicemail from the port window had been transcribed and assigned to the right dispatcher.
At 7:15am Eastern, the customer's VP of Ops sent a single message to the war-room channel: "Looks normal." That is the highest praise this kind of project ever gets. Nobody writes a thank-you note for a phone system that works.
The first real exception came at 11am Monday: an outbound call from the Charlotte depot to a customer in Mexico failed to complete. It turned out we had not enabled international outbound on the Charlotte trunk — a configuration setting that was on by default on the old PBX but off by default on the new one. We turned it on. Three minutes of impact. The dispatcher had moved to a mobile phone and made the call. Nobody had been waiting.
What we learned and what we will do differently
Three things we will carry into the next migration of this size.
- Reverse-engineer from CDRs, not from configuration. The PBX exports had hundreds of dead rules. The CDRs showed what was actually live. We will start every migration with a CDR-led inventory and only consult the config for the cases the CDR data does not explain.
- Stagger by site, not by service. We rolled Atlanta-then-Charlotte-then-Dallas, which gave us per-site rollback. The original plan was to cut over by service (inbound first, then outbound, then SMS). Per-site staggering is harder to schedule but safer to recover.
- Have one named owner per dial-plan rule. The catch-all defensive rules each had a person on the Helix side who would be paged if the rule fired. We had two of those rules fire during the first 10 days. In both cases the right person was on the call within four minutes. That kind of speed is bought during pre-flight, not during the incident.
The customer's take, six weeks later
We talked to Helix's Director of Operations six weeks after cut-over to debrief. The headline was that the freight calendar had not noticed the migration. The number that mattered to them — picks-confirmed-on-time — was within 0.4% of the pre-migration baseline. The dispatcher team was using six fewer logins to do the same job, and a dispatcher who had been at Helix for nine years sent us a Slack message that said, in its entirety: "the new system is the first thing in a long time that has not made my job worse."
That is, all told, the best feedback you can get from a freight company.