Go-Live Day and the First Week

The MSP's Guide to VoIP: Part 10 of 20

Everything has been configured, tested, and documented. The trunk is connected, the routing is in place, the phones are provisioned. Now comes the part that separates a smooth deployment from one that becomes a story your technicians tell at happy hour for years: go-live day. And the first week after it, which is where the real test happens.

Go-live day is a project management exercise as much as a technical one. The technical work is mostly done. What matters now is sequencing, communication, timing, and having a plan for when things don't go exactly as expected. Because they won't. They never do.

Picking the right day and time

Friday afternoon is not the right time to cut over a phone system. Monday morning is not ideal either. The best go-live window is Tuesday or Wednesday morning, early. This gives you the full day to work through issues, a day or two of normal business operation to shake things out, and the weekend as a buffer before the next full business week.

If the client insists on a Monday go-live, push for early morning, before the office opens. If they insist on Friday, make sure you and your team are available through the weekend for emergency support. It happens. Just price it accordingly.

Avoid month-end, quarter-end, or any period when the client's call volume is unusually high. Don't go live the week of the client's biggest annual event. Ask the client when their busiest call periods are and avoid those windows. The worst time to discover a routing issue is when the sales team is handling peak inbound volume.

Number porting coordination

If you're porting numbers from an existing carrier to the new trunk provider, the port date is your go-live date. Number porting is covered in detail in the porting numbers post, but the key points for go-live planning are:

Ports are scheduled in advance but the exact completion time is unpredictable. The old carrier releases the numbers on the scheduled date, but it might happen at 8 AM or it might happen at 2 PM. Your trunk provider will notify you (or you can watch their portal) when the port completes. Until the port completes, inbound calls still go to the old system.

This means you need an overlap period. The old phone system should remain operational until the port is confirmed complete. Don't decommission the old system the night before the port date. Leave it running. Once the port completes, test inbound calls to every ported number on the new system. Only after confirming that all numbers are working on the new system should you consider shutting down the old one.

Keep the old system available (not necessarily active, but available) for at least a week after the port. If something goes wrong and a number needs to be ported back, having the old system intact makes that process much less painful. Think of it as a rollback option.

The rollback plan

Speaking of rollback: have one. Before go-live, document exactly what you would do if the new system has a critical failure that can't be resolved within a reasonable time frame. "Reasonable" depends on the client. For a medical office, an hour of no inbound calls is a crisis. For a consulting firm, half a day is uncomfortable but survivable.

The rollback plan typically involves forwarding numbers from the new system back to the old system (if the old system is still active), or forwarding to mobile phones as an emergency measure. The specifics depend on the deployment, but the important thing is that the plan exists, is documented, and everyone involved knows what triggers it.

Define the trigger criteria with the client before go-live. "If inbound calls are not working within two hours of the scheduled port completion, we will forward the main number to [mobile number] while we troubleshoot." Having this agreed upon in advance avoids a panicked negotiation in the middle of a problem.

Go-live day: the testing sequence

When go-live morning arrives, you need a systematic testing sequence. Don't just turn everything on and hope for the best. Test in layers, from infrastructure up to user-facing functionality.

Layer 1: Internet connectivity

Verify the internet connection is up and performing normally. Run a speed test and a VoIP quality test to confirm that latency, jitter, and packet loss are within acceptable ranges. Check latency to the trunk provider's SIP server (a simple ping, though ICMP isn't always the best proxy for SIP performance). If the connection is degraded on go-live morning, you want to know before you start routing calls over it, not after.

If there's a backup internet connection, verify it's also operational. If QoS is configured on the router, verify the rules are active (not just configured but actually applied to the correct interface and functioning).

Layer 2: Network core

Verify the switches are up, VLANs are configured correctly, and the phones can reach the PBX (or hosted platform). Pick up a desk phone and check that it's registered and showing the correct extension. If the phones booted overnight and auto-provisioned, they should be ready. If any phones show errors or aren't registered, troubleshoot those individually before proceeding.

Check the PBX's trunk status. Is the SIP trunk registered (or, for IP auth, is it showing as connected)? If the trunk isn't up, nothing else matters. Fix the trunk first.

Layer 3: Phone deployment in stages

Don't test all 50 phones at once. Start with a small group, ideally the IT contact's phone and two or three others in different parts of the office. Make test calls: outbound to a mobile, inbound from a mobile. Verify two-way audio, call quality, caller ID display, and voicemail. If this small group works, expand to the next group. If it doesn't, you've isolated the problem to a manageable scope.

For larger deployments (more than 20 phones), consider going live in phases: one department or one floor at a time. If the sales team goes live first and there's an issue, the rest of the company is still on the old system. This reduces blast radius and lets you fix problems while only a subset of users is affected.

Layer 4: Critical workflows

Once basic calling works, test the specific workflows the client cares about most:

The main number. Call the main number from an external phone. Does the auto attendant answer? Do all the menu options work? Does the timeout route correctly? If a receptionist handles calls, does the call land on their phone as expected?

Ring groups. Call each ring group. Verify the ring pattern (simultaneous, sequential, whatever was configured). Let it ring past the timeout. Does it fail over correctly?

Call queues. If the client uses queues, put a test call into the queue. Verify hold music plays, the call routes to an available agent, and the queue statistics display correctly in whatever interface the supervisors use.

Voicemail. Leave a message. Check that the message notification works (visual voicemail indicator on the phone, email notification if voicemail-to-email is configured). Have the user retrieve the message and confirm it plays correctly.

Transfer. Have someone answer a call and transfer it (blind transfer and attended transfer). This is the operation that trips up the most users, and if the transfer function doesn't work correctly, you'll hear about it within the first hour.

Conference calling. If the system supports ad-hoc conferencing, test it. Initiate a three-way call and verify everyone can hear each other.

Layer 5: Remote access

If any users are working remotely with softphones or remote desk phones, verify their connectivity. Have them make and receive test calls. Remote users are often the last to be tested and the first to have problems because their network conditions are less controlled.

Training on go-live day

Even if you provided training before go-live, plan for a brief refresher on go-live morning. With the actual working system in front of them, users will pay more attention and ask better questions than they did during pre-deployment training with theoretical scenarios.

Keep go-live day training short and focused on daily operations: answering calls, transferring calls, accessing voicemail, and putting calls on hold. This is not the day for advanced features. People are already dealing with the stress of change. Give them the basics, make sure they're comfortable, and save the advanced training for week two.

Print a one-page quick reference card with the most common operations. Place one at every desk. Yes, it's on the phone's screen too. Yes, it's in the documentation you emailed. Put a physical card at the desk anyway. When someone is on a call with a client and can't figure out how to transfer, they're not going to search their email for documentation. They're going to look at the card on their desk.

The first week: brace for it

Go-live day went well. Everything tested fine. Users made it through the day. You drive home feeling good about the deployment. And then the calls start coming in on day two.

The first week after a VoIP deployment is when users discover all the things they forgot to mention during the planning phase, all the workflows they didn't think to describe, and all the habits from the old system that don't translate to the new one. This is normal. It's not a failure of your planning. It's just what happens when a group of people starts using a new system under real conditions.

The hold button crisis

Someone will not be able to find the hold button. Or they'll press hold and not know how to retrieve the call. Or they'll press transfer when they meant to press hold, and lose the call. This happens on every deployment with every phone system. The phone's interface is different from what they're used to, and muscle memory from the old system doesn't help with the new one.

Be patient. Walk them through it. Update the quick reference card if the hold/transfer process isn't clear. This is a training issue, not a system issue, but it feels like a system issue to the user who just accidentally hung up on a client.

Voicemail PIN chaos

Half the users didn't set up their voicemail PIN during training, or they set it up and immediately forgot it. Now they have messages they can't access. Have a process for resetting voicemail PINs quickly. On most platforms, the admin can reset a PIN in the management portal in about thirty seconds. Make this easy for whoever is handling first-week support.

Ring groups don't match reality

During planning, the client said the support team has four people and they all answer calls equally. In reality, two of them are part-time and only available in the mornings, one is in a different office, and the fourth handles overflow from the sales team before answering support calls. The ring group you configured doesn't match how the team actually works.

This is the most common post-go-live adjustment. Ring group membership, ring patterns, and failover behaviors almost always need tweaking once the team starts using the system in their actual workflow. Budget time for ring group adjustments in the first week. Make changes during low-volume periods and test each change after making it.

The conference room phone nobody tested

Every deployment has a phone or a room or a device that somehow got skipped during testing. The conference room speakerphone that was in a box on go-live day. The phone at the reception desk that was unplugged because the receptionist was on vacation. The fax machine that connects through an ATA that nobody configured.

Walk the office on day two or three and check every phone, every conference room, every shared device. Don't assume that if nobody reported a problem, everything is working. Some people will just quietly work around a broken phone for days before mentioning it.

Remote worker issues surface gradually

Remote workers who tested fine on go-live day might have intermittent issues that only appear under certain conditions. Their home WiFi gets congested when the kids come home from school. Their ISP has packet loss during peak hours. The VPN connection drops their softphone registration periodically. These issues take time to surface because they're intermittent and depend on conditions at the remote worker's location.

Have remote workers report any call quality issues during the first week, even intermittent ones. If a pattern emerges, troubleshoot the remote worker's network environment. The office move telecom checklist has relevant guidance on testing network conditions that applies to remote setups too.

Being responsive without setting a precedent

Here's the management challenge of the first week: you need to be highly responsive to build confidence in the new system and your support, but you also need to avoid establishing an expectation that every phone question gets an immediate, personal response from the MSP forever.

During the first week, respond quickly to every issue. Fix what's broken, answer questions, adjust configurations. This is what builds the client's confidence that the deployment was done well and that you'll take care of them.

But also start channeling requests through the proper support process. If the client's users are texting your personal phone with questions, gently redirect them to the ticketing system or the designated support contact at the client's office. "Happy to help with this. For the fastest response going forward, email support@ or call the help desk."

Designate a point person at the client's office: someone who can handle the basic questions (how do I transfer a call, what's my voicemail PIN) without calling you. Train this person thoroughly. Give them admin access to the phone system portal if appropriate, so they can reset voicemail PINs and check extension status without opening a ticket. This person is your first line of defense against a flood of minor requests that don't need MSP-level attention.

Collecting feedback systematically

Don't rely on people coming to you with problems. Proactively collect feedback during the first week. A simple email to all users on day three asking "How is the new phone system working for you? Any issues or questions?" will surface problems that users assumed were just how the new system works and weren't worth reporting.

A brief survey at the end of the first week (five questions maximum, keep it short) gives you structured feedback. Ask about call quality, ease of use, any features they're missing from the old system, and anything that's frustrating about the new system. The answers will tell you what needs adjustment and what needs additional training.

The one-week check-in

Schedule a formal check-in meeting with the client's decision maker at the end of the first week. Review the issues that came up, the changes that were made, and the outstanding items. This is your opportunity to demonstrate that the deployment is on track and that you're managing the transition professionally.

Bring a list of every issue reported and its resolution status. Include the changes you made proactively (ring group adjustments, voicemail PIN resets, etc.) and any items that are still pending. This kind of structured follow-up builds trust and shows the client they made the right choice.

Use this meeting to also set expectations for the next few weeks. "We expect a few more adjustments as everyone settles in. Here's how to report issues. We'll do another formal check-in at the one-month mark."

The one-month check-in

By one month in, the system should be stable and users should be comfortable with daily operations. The one-month check-in is about confirming that everything is working well and transitioning from deployment mode to ongoing support mode.

Review call quality data if the system provides analytics. Check for patterns: are there times of day when call quality dips? Are certain extensions having more issues than others? If monitoring is in place, review the monitoring data and address any trends before they become problems.

Discuss any features or changes the client wants now that they've had a month of experience with the system. The things they thought they needed during planning may not be the things they actually need now that they're using it. Advanced features they dismissed during deployment ("we don't need call recording") might be things they're now interested in.

Close out the deployment project formally. Deliver the final documentation package: network diagrams, extension list, trunk configuration details, admin credentials, support contact information. Define what constitutes ongoing support versus deployment-related work. Move from project mode to support mode.

The deployment isn't done when the phones work

A successful VoIP deployment isn't measured on go-live day. It's measured at the one-month mark when the client says "the phones are working great and the team is happy." Getting to that point requires more than good technical work. It requires managing the transition, being available during the critical first week, collecting and acting on feedback, and following through with structured check-ins.

The clients who become long-term, high-value MSP relationships are the ones where the deployment went smoothly and the follow-up was thorough. The actual technical configuration is maybe 60% of what makes a deployment successful. The other 40% is communication, project management, and being there when things don't work as expected. Which they won't. They never do. But that's what you're there for.

Before proceeding further in your voice deployment, make sure you understand the regulatory obligations that come with offering voice services. Parts 17 through 20 of this series cover FCC registration, STIR/SHAKEN, and the Robocall Mitigation Database. These are not optional and the consequences of non-compliance are severe.

Next up: Monitoring VoIP Quality Proactively