Replacing a Failing Contact Centre Without a Big-Bang Cutover

Why does a big-bang contact centre replacement fail under audit pressure?

A big-bang cutover asks one weekend to prove everything at once: telephony, routing, recording, agent desktop, integrations, reporting and training. When the operation is already failing, every defect found after go live lands on customers who are already unhappy and on agents who are already stretched, and there is no way back without a second cutover. It also leaves you with nothing to show an auditor except a promise.

The regulator question is rarely "which platform do you run". It is closer to "how do you know customers are being treated fairly, and what are you doing about the failures you already know about". A documented stabilisation plan, an incident log showing the problems are being contained, and a controlled migration with evidence at each step answer that question far better than a new system switched on the month before the visit. This page is general guidance, not legal advice; confirm what your own regulator expects.

What does the stabilisation track need to achieve?

Stabilisation here has a narrow goal: stop harm to customers and create evidence. It is not a project to make the old platform good. Anything that does not reduce harm or produce evidence waits. The service desk triage order itself, from a single intake route to an honest backlog number, is set out in our guide to stabilising customer service on a platform you cannot replace; for a contact centre, add the items below.

• An incident log that records every outage, dropped call or chat, routing failure and recording gap, with time, scope, customer impact and the containment applied. This becomes the core of the audit pack.
• Documented workarounds for each known failure, such as a fallback number, a manual callback list or an alternate queue, with a named owner per shift.
• Daily recording checks: sample calls from each queue and confirm the recording exists, plays and is retrievable, because a missing recording is often discovered only when a complaint needs it.
• A vulnerable customer and complaint path that does not depend on the failing component, so the customers most likely to be harmed are not the ones stuck in a broken IVR.
• A change freeze on the old platform except for fixes that reduce harm, so the new track is not chasing a moving target.
• A weekly one page status for leadership and compliance: incidents, containment, open risks, and progress on the proof of value.

What should the proof of value on the target platform prove?

A proof of value is not a demo. It runs one real or realistic queue on the target platform, in your own tenant, with your telephony provider connected, your routing rules and your data, and it is judged against criteria written down and signed off before it starts. Criteria agreed afterwards tend to measure whatever went well.

On Dynamics 365 Customer Service the voice channel can run on Microsoft telephony through Azure Communication Services, including bringing an existing carrier through direct routing, or an existing contact centre telephony provider can be kept and integrated through the Channel Integration Framework. Which of those fits is part of what the proof of value decides. How voice, chat, email and messaging share one routing model is covered in our unified omnichannel architecture guide; if your team is still choosing between Dynamics 365 and a standalone help desk, start with the Dynamics 365 Customer Service versus Zendesk comparison.

Which pass criteria should be agreed before the proof of value starts?

Write each criterion as a test with a method and a threshold that your operations lead and compliance lead both accept. The thresholds are yours, set from your service commitments and your peak volumes, not from a vendor sheet. A criterion without a measurement method is an opinion.

What is the cutover gate, and why cut over queue by queue?

The cutover gate is a short written checklist that must be true before any queue moves. It stops the date from deciding the go live. Cutting over by queue means the telephony and digital entry points for one queue are pointed at the new platform while the others stay on the old one, so a problem affects one group of customers and can be reversed by pointing that queue back.

• All pass criteria met in the proof of value and re-run on the production configuration.
• Agents for the queue trained on the production environment, not a sandbox, with a floor walker for the first days.
• A tested rollback: the steps and the owner to route the queue back to the old platform, and how long it takes.
• Recording, retention and access controls verified on production with compliance sign-off.
• Reporting for the queue reconciled for at least one full business cycle before the next queue moves.
• The incident log continued on the new platform, so the audit trail does not break at cutover.
• Start with a queue that has moderate volume and simple routing, not the highest-risk queue, and move complaints and vulnerable customer queues once the pattern is proven.

When is stabilising the right answer and replacement is not?

Replacement is expensive and risky, and sometimes the product is not what is broken. Before committing, check whether the failures trace to the platform or to how it was set up and run. If they trace to configuration, a rescue of the current build is faster, cheaper and less disruptive; our project rescue and takeover service covers how that assessment runs when the current platform is Dynamics 365.

• Failures cluster around specific routing rules, scripts, integrations or customisations rather than the product core.
• The same product runs acceptably for other organisations of similar size and channel mix.
• The vendor or carrier supports the version you run, and fixes are available.
• Recording and retention can be verified and corrected without replacing the platform.
• The contract, integrations or telephony estate make replacement within the regulator window unrealistic anyway.

What does a realistic phased timeline look like with no internal developers?

Without internal developers, the timeline is set by how fast decisions are made and by who will own the platform afterwards, not by build speed. Plan in phases with a gate at the end of each, and budget for ownership from day one: a partner who builds and then leaves hands you the same problem in a new product. Durations depend on channel count, telephony, integrations and data, so treat the order below as fixed and the lengths as something to estimate once discovery is done.

What goes into the audit evidence pack?

Build the pack as you go rather than assembling it the week before the visit. Each item below is produced by the work itself if you plan for it. Keep it factual: what failed, what you did, what you measured and what is still open.

• The incident log and containment actions from the stabilisation track, with dates.
• The decision record for replace versus rescue, including the options considered.
• The signed pass criteria, test scripts and results from the proof of value.
• Recording and retention verification results, on the old platform and on the new one.
• The cutover gate checklist signed for each queue, and the rollback test results.
• Reconciled reporting for each queue after cutover, and customer outcome measures such as complaints and CSAT tracked against the changes.

Should the target be Dynamics 365 or something else?

The phased method works whatever the target is, and the choice deserves its own honest look rather than defaulting to the incumbent vendor or the loudest one. We recommend the right solution - whether that's Microsoft Dynamics 365, Power Platform, or a custom-built CRM. Some businesses need the Microsoft ecosystem. Others need full control without licensing. We deliver both.

Dynamics 365 Customer Service fits when agents need the full customer record shared with sales and field operations, when you run Microsoft 365 and Teams, and when routing and entitlements are complex; the Dynamics 365 Customer Service implementation page sets out the scope. Where per-user licensing does not match how many people touch a contact, or hosting requirements rule the Microsoft cloud out, a custom-built CRM integrated with your chosen telephony provider is the alternative.

How does Solzet run a phased contact centre replacement?

We run the two tracks together. On the stabilisation track we work alongside your operations and compliance leads on containment, the incident log and the audit pack. On the target track we design and build the Dynamics 365 side, from unified routing, queues and the agent workspace to recording access, reporting and integrations, and we connect voice either through Azure Communication Services, with your carrier brought in through direct routing where needed, or by integrating your existing contact centre telephony provider through the Channel Integration Framework. We do not operate telephony carriers or number ranges; the carrier or contact centre telephony vendor remains your contract, and we work with them on the integration and the tests.

Solzet delivers remotely from Yerevan, Armenia, with senior consultants and full-stack developers and 8+ years of Dynamics 365 Customer Engagement and Power Platform work, directly or white-label for Microsoft partners. We do not work on Dynamics 365 Finance, Business Central or other ERP systems.