Cutting Over a Contact Centre Without Downtime
Last updated: 4 July 2026
The floor manager checked her watch at 22:47 IST and asked me the question every buyer asks on cutover night. “Are we live yet.”
Half the seats on the Mumbai collections floor were empty. The 22:00 shift had logged out. The 06:00 shift was still four hours away. That was the whole point of picking a Saturday night. But one of the two SIP trunk carriers had not confirmed the port. The confirmation was overdue by twenty-two minutes and every minute after that felt heavier than the last.
This post is what actually happens on the night you cut over from an on-prem Avaya Aura estate to a cloud contact centre. The plan on paper is boring. The night itself is not. If you are about to run this project, or you are a CFO signing off on the vendor quote, this is the ops-floor view your integrator will not put on the slide.
What the plan said, and what it left out
The client is an 800-seat collections BPO with two Mumbai floors and a smaller Nagpur site. They were on Avaya Aura CS 1000 with two SIP carriers upstream and roughly 50 concurrent calls at peak. The board had signed a three-year ₹4.2 crore programme with an INR OpEx of about ₹1.4 crore in year one. The words on the slide were the ones every board reads. Zero downtime. Phased. TRAI compliant. Recordings inside India.
Six months of discovery. A written parallel-run plan. An SBC design that was reviewed twice. Dial-plan documentation that took four weeks to build. The plan called for a Saturday-night cutover of the smallest queue first, a seven-day parallel run, then the next queue, and so on across six queues over six weekends.
What the plan left out was the shape of a Saturday night in Mumbai when one carrier goes quiet.
21:00 IST, dial-plan freeze and shadow trunks up
Cutover starts quietly. The dial-plan freeze goes out on email at 20:00. No new extensions. No reroutes. No IVR edits from anyone. The shadow trunk on the new stack is already up, taking synthetic test calls from a Sirius test SIM in Malad. The recording server has been running in parallel for six days, and I have already hashed last night’s WAV files against storage on the old Aura estate.
The first thing you look at on cutover night is not the new stack. It is the old one. If Aura is misbehaving before you cut, the noise from the migration will hide the pre-existing problem. So we sat and watched the CS 1000 counters for an hour. Nothing looked off. That is the first small mercy.
22:30 IST, the port window and the first crack
Number porting in India is not a click. It is a scheduled request with the losing and gaining carriers, aligned to a TRAI-approved window. Both carriers had agreed on 22:30 to 23:30 IST. Carrier A confirmed at 22:31. Carrier B went quiet.
The fallback rule was written on the whiteboard in the war room. If any carrier misses the confirmation by more than thirty minutes, hold that queue on legacy PBX and roll the other queue forward. Do not force the port. Do not chase confirmation on the same call the port is riding on. Sit on your hands and route.
At 22:52 we activated the temporary fallback route on the SBC. Inbound calls to Carrier B’s DIDs kept landing on the CS 1000 for the collections East queue. Everything else moved to the cloud stack. No customer noticed. No agent noticed. The floor manager noticed only because I told her.
Carrier B’s confirmation came at 23:41, sixty-nine minutes late. Their reason, delivered by email the next morning, was a scheduling conflict on their side that a five-business-day SLA on whitelisting had failed to catch. We had the paperwork in from week one, so this was their delay, not ours. The queue moved to the cloud stack at 00:15 with a shorter parallel run than the others.
See how we scope Avaya migrations for Indian estates →
00:15 IST, the recording alignment scare
Between 00:15 and 01:30 the floor should have been quiet. Skeleton shift on a Saturday. It was quiet on the phones. It was not quiet in the NOC. A supervisor dashboard on the new stack was showing recording playback errors on every attempt. The recordings were fine. The dashboard was hitting the recording node directly instead of the reverse proxy, an old Apache habit from the pilot environment that had followed the config into production.
The fix took thirty minutes. An X-Forwarded-For aware rule on the new web server, a config reload, a supervisor login test on three sample calls. Finding it took two hours of looking in the wrong place. If you are running this project, put a supervisor in your dry-run script and have them play back at least ten calls before the cutover night.
04:00 IST, shift-change on the new stack
The 06:00 shift arrived early. Eighty agents. The soft phone had been on their desks for four weeks in shadow mode. That did not stop three of them from calling the floor manager to ask where the hold button had gone. It was in the same place. They had not looked.
Two IVR paths had not been tested end to end during dry-run. Both were after-hours branches that only exist between 02:00 and 06:00 for a specific product line. Both routed correctly. We only discovered they existed because I had scripted a set of synthetic after-hours calls to run at 04:15. If you skip the synthetic call set, you will discover after-hours defects from a customer complaint on Monday.
What we kept from the old Avaya
The board thought we were retiring the whole Avaya estate that night. We were not. Aura stayed live for seven days as the fallback path for the East queue. The DIDs for the Nagpur site stayed on their existing carrier for two more weekends because the local exchange had a longer window. Some vector routing logic that had grown over eight years was ported line for line into the new IVR because rewriting it during a cutover was a bad idea.
Parallel run, seven days not seven hours
The single most useful thing on the plan is the seven-day parallel run. Seven days of the old PBX handling a defined slice while the new stack handles the rest. It is the parallel run that catches routing drift a lab test cannot see. It is also the parallel run that lets your CFO sleep on Monday night because the rollback path is a config change, not a rebuild.
| Phase | Duration | What runs where | Rollback if broken |
|---|---|---|---|
| Shadow trunk | 6 to 10 days pre-cut | Test calls only on new stack | No customer impact |
| Cutover night | 4 to 8 hours | Queue by queue on new stack, rest on legacy | Reroute at SBC |
| Parallel run | 7 days per queue | New stack live, legacy still routing DIDs | Fail back in minutes |
| Legacy retirement | Day 8 to 14 per queue | Legacy DIDs released, carrier cutover final | Not applicable |
The BPO segment reads a lot about voice AI these days. The May 2026 Outsource Accelerator report on generative voice AI hollowing out Indian BPO seats made every board meeting louder. Avaya Infinity and the Cisco Webex Contact Center AI Agent Studio announcements added to the noise. None of it changes the shape of cutover night. If your telephony is unstable, no AI agent on top of it will look good.
Frequently asked questions
How long does a contact centre cutover actually take? The cutover night for a single queue on a well-scoped estate is four to eight hours. The full programme for a 500 to 1,000 seat multi-site estate is eight to sixteen weeks. Discovery is the phase that expands. If your integrator quotes six weeks door to door for that size, ask what discovery they are skipping.
What if a carrier misses the port window? You hold that queue on legacy PBX, activate a temporary fallback route at the SBC, and move the other queues forward on the planned schedule. Do not force the port.
Do call recordings have to stay inside India? For collections, BFSI, insurance, healthcare, and any workload handling sensitive personal data, yes. The DPDP framework and sectoral rules from RBI and IRDAI define the boundary. Decide residency before the SBC design is signed.
Can we cutover during the working week? A weeknight window is possible if the estate is small and the carrier is co-operative. On anything above 300 seats or two carriers, weekends give you the buffer you actually need for a bad port window.
Key takeaways
Cutting over a contact centre without downtime is not a heroic Saturday night. It is a boring plan executed on schedule. Discovery is where the time goes. Carrier paperwork starts in week one. The parallel run is seven days. The supervisor dashboard gets tested against real recordings before the night, not during it. And the sentence a good integrator leaves out of the sales slide is the one about the port that missed by an hour and the queue that stayed on the old PBX for a week longer than planned. That is the sentence the CFO actually needs to hear.
Talk to us
If you are scoping an Avaya cutover, or you have already picked the target platform and you want a sanity check on the parallel-run plan, we spend a fair amount of our week on floors like the one described here. A free half-day discovery gives you a written phased schedule, a carrier-paperwork checklist, and an SBC design review. No card, no contract, no sales call.
Related reading on Sirius Star: the Pune BPO licence audit that found 300 idle seats, our take on when to migrate off old Avaya Aura, the Avaya versus Cisco decision for Indian contact centres, and our note on what SASE means for an Indian business buyer. For the full brand hub, see Avaya India solutions.
Reach us on WhatsApp at +91 91375 93228 during 10 to 7 IST, or use the button above. We answer.
P.S. Karthik here. The Mumbai floor manager sent a message on the following Wednesday to say the East queue had been retired on legacy PBX for two days and the phones were behaving. That is the whole point. A boring Wednesday afternoon on the new stack is the win. If your integrator promised you a dramatic Saturday night, ask why.
