What Actually Happens During a Business Phone System Cutover

I've been doing phone system cutovers since 2006. Hundreds of them — five-seat law firms, 200-seat contact centers, medical practices with six locations, plumbing companies with trucks in three counties. And here's what I can tell you with certainty: the technology is rarely the problem. The migration is.

Every vendor on the planet will show you a feature list. HD voice. Mobile app. CRM integration. Auto-attendant. It all sounds great in a demo. But the question nobody asks during the sales process is the one that matters most: what happens on cutover day?

Because that's where things go sideways. Not because the technology fails, but because nobody planned for the 40 things that have nothing to do with technology.

This post is the honest version of what a business phone system migration looks like — the stuff that doesn't make it into marketing brochures.

Phase 1: The Discovery Call That Shouldn't Be Rushed

Before we touch a single piece of equipment, we need to understand how your business actually uses its phones. Not how you think you use them — how you actually use them.

This means sitting down (usually for 60-90 minutes) and walking through questions most vendors skip:

How many inbound calls do you get per day? How many go to voicemail?
Who answers the phone first? What happens when they're busy?
Do you have employees who work from home, from job sites, or from their cars?
What happens after hours? Weekends? Holidays?
Are there any phone numbers that are absolutely sacred — numbers you've had for 20 years that customers know by heart?
What's your current call flow? (Most people can't answer this accurately, which is exactly why we ask.)
Do you have a fax line? (Yes, in 2026, this still matters.)

We're not asking these questions to fill out a form. We're building a map of your communication infrastructure — one that accounts for the weird edge cases that break generic setups. Every business has at least three things about their phone usage that are unique to them, and if you don't discover those things before you start building, you'll discover them on go-live day when a customer can't reach you.

Phase 2: The Number Audit (This Is Where It Gets Real)

Phone number porting is the single most underestimated part of any migration. It sounds simple: move your numbers from one carrier to another. In practice, it's a bureaucratic maze involving your current carrier, the new carrier, the FCC's Local Number Portability rules, and sometimes a third-party records administrator nobody's heard of.

Here's what we do before we even submit a port request:

Pull a Customer Service Record (CSR) from your current provider. This document tells us exactly which numbers are on your account, what type they are (local, toll-free, fax), and whether any have features tied to them (like hunting groups or remote call forwarding) that could complicate the port.
Verify number ownership. You'd be surprised how often a business doesn't actually "own" its phone numbers — they're under a former employee's name, an old vendor's account, or a carrier reseller who went out of business.
Identify toll-free numbers separately. Toll-free ports go through a completely different process (the RespOrg system) and take a different timeline. Mixing them up with local number ports is a classic mistake.
Check for contract obligations. Some carriers will hit you with early termination fees. Some won't release your numbers until the final bill is paid. We flag all of this upfront so there are no surprises.

A clean port typically takes 7-10 business days for local numbers and 3-5 for toll-free. But I've seen ports take six weeks when there's a dispute, a records mismatch, or a carrier that drags its feet. We've learned to start this process early and run it in parallel with everything else.

Phase 3: Designing the Call Flow

This is the part most people think of as "setting up the phone system," but it's really more like architecture than installation.

A call flow is the logic that determines what happens when someone dials your number. It sounds simple, but even a 10-person company usually needs something like this:

Caller dials main number.
Auto-attendant answers: "Thanks for calling [Company]. Press 1 for Sales, 2 for Support, 3 for Billing."
Caller presses 1. Call rings the sales team simultaneously (all three desks ring at once).
Nobody picks up within 20 seconds. Call forwards to the sales manager's cell phone.
Sales manager doesn't pick up. Call goes to a shared voicemail box that emails the recording to three people.
After hours? Skip the auto-attendant entirely — play a different greeting, go straight to voicemail, and send an urgent email to the on-call person.

Now multiply that by departments, locations, holidays, lunch hours, and the owner who wants their personal cell to ring for VIP customers but not for anyone else. That's a real call flow.

We diagram every one of these before we build anything. The client signs off on the diagram. Then we build it, test it internally, and test it again with the client before go-live. No exceptions.

Phase 4: Hardware and Network Prep

If you're keeping desk phones (many businesses still prefer them — and that's fine), we pre-provision every handset before it arrives at your office. That means each phone is already configured with the correct extension, name label, speed dials, and line appearances. When your receptionist plugs it in, it just works. No on-site programming, no waiting for IT.

But before any of that matters, we need to verify your network can handle voice traffic. VoIP is sensitive to three things:

Latency. If packets take too long to arrive, you hear delays and talking over each other. We want under 150ms round-trip.
Jitter. If packets arrive at irregular intervals, audio sounds choppy or robotic. We want under 30ms of jitter.
Packet loss. If packets disappear entirely, you get gaps in audio or dropped calls. We want 0% — and anything above 1% is a dealbreaker.

We run a network assessment before every deployment. It takes about a week of passive monitoring on your network, and it tells us whether your internet connection and internal network can support the call volume you need. If the numbers don't look right, we fix it first. We don't just cross our fingers and hope. That's how you end up with a system that works great in the demo and terribly in production.

Common fixes include enabling QoS (Quality of Service) rules on your router to prioritize voice traffic, upgrading from a consumer-grade router to a business-grade one, separating voice and data onto different VLANs, or sometimes just upgrading the internet plan because the business outgrew its 50 Mbps connection two years ago and nobody noticed.

Phase 5: Go-Live Day

This is the day everyone's nervous about. It doesn't have to be.

We schedule cutovers for early morning — typically 7:00 AM before the business opens. For most deployments, the actual switch takes about 30 minutes. The old system stops receiving calls, the port completes, and the new system goes live. We're on-site (or on a live screen share for remote deployments) for the entire process.

Here's what the first two hours look like:

7:00 AM: Port completion confirmed. Inbound calls begin hitting the new system.
7:05 AM: We make test calls to every direct line, ring group, and auto-attendant path. We call from outside the building — not from the office — because internal calls route differently.
7:30 AM: Walk the floor. Check every desk phone for dial tone, correct caller ID, and proper extension assignment. Test a transfer. Test a park. Test voicemail.
8:00 AM: Employees arrive. We do a 15-minute walkthrough: how to transfer calls, how to check voicemail, how to use the mobile app, how to do a three-way call. Keep it short. Nobody remembers a 45-minute training session.
8:15 AM: Business opens. We stay on-site for the full morning, monitoring call quality in real-time and handling any "how do I..." questions as they come up.

By noon, things are usually running smoothly. We check in again at end-of-day, then daily for the first week, then weekly for a month. That's the support cadence that prevents small issues from becoming big complaints.

The Things That Go Wrong (And How to Prevent Them)

I'm not going to pretend every cutover is flawless. Here are the most common issues we've seen over 20 years, and how we mitigate them:

Delayed ports. The old carrier rejects the port request due to a name mismatch or unpaid balance. Prevention: We pull the CSR and resolve discrepancies before submitting the port. We also maintain direct relationships with carrier porting departments — not just the general support line.

Network issues that didn't show up in testing. The assessment looked clean, but on go-live day, the office runs a massive cloud backup every morning at 8 AM that saturates the connection. Prevention: Our network assessment runs for a full business week specifically to catch these patterns.

The one phone number nobody told us about. There's a fax line in the back office that the owner set up in 2009 and forgot about. It's on a completely separate account with a different carrier. Prevention: We cross-reference the CSR against the client's phone bill and ask specifically about analog lines, fax machines, elevator phones, fire alarm lines, and security system dialers. These are the lines that get forgotten.

Employee resistance. Someone who's used the same Polycom desk phone for 12 years doesn't want to learn a new system. Prevention: We identify key users early, get them involved in the call flow design, and make sure they feel heard. A five-minute one-on-one with a frustrated employee on day one prevents a week of complaints.

Why This Process Matters More Than Features

I talk to business owners every week who got burned by their last phone vendor. The story is always the same: the demo looked great, the price was right, and then the migration was a nightmare. Nobody tested the call flow. The port took three weeks. The desk phones arrived unconfigured. The "24/7 support" was a ticket queue in another time zone.

The difference between a phone system that works and one that doesn't isn't the feature list. It's whether someone actually planned the migration, tested the network, ported the numbers correctly, built the call flows to match how your business really operates, and showed up on go-live day to make sure it all worked.

That's not a technology problem. That's an execution problem. And it's the reason we do cutovers the way we do — methodical, documented, and with someone from our team on-site or on-call until you're fully operational.

Thinking about switching your phone system? We'd rather spend an hour understanding your business than give you a 10-minute demo. Reach out to our team and we'll walk you through what a cutover would look like for your specific setup — no pressure, no generic slide deck.