Modernisation
The migration quote was refused for good reasons: a two-year programme, a hard cutover, and a risk profile nobody wants to own during a peak season. The alternative is not to keep waiting — it is to add the missing layer in front of what you have and replace components on your schedule.
The system works, in the sense that calls connect. It was implemented by people who have left, configured in a way that is documented nowhere, and it is now either end-of-life, on a version that cannot be upgraded, or owned by a vendor that has been acquired twice since you signed.
Every proposal to replace it has come back as a multi-year programme with a cutover weekend, and every time the business has looked at the risk of that cutover against the risk of staying, staying has won. Which is a rational decision made repeatedly, and it accumulates into a position nobody chose.
Meanwhile the things you actually need — better routing, real quality coverage, assistance for agents, evidence for compliance — are all blocked behind a migration that is never going to be approved in one piece.
Modernisation keeps being scoped as replacement, so the decision is always between a large irreversible programme and doing nothing — and doing nothing keeps winning.
The premise underneath every migration quote is that the new capability lives inside the new platform, so you must have the platform to get any of it. That premise is what makes the decision binary, and it is not architecturally necessary.
Routing intelligence, agent assistance, quality coverage, workflow initiation, governance and evidence can sit in front of the telephony you already run. The legacy platform keeps doing the thing it still does adequately — connecting calls — while the layer that was missing gets added without a cutover.
That also changes the replacement decision itself. Once the capability is no longer trapped inside the incumbent, replacing it becomes a component swap you can schedule, rather than a programme you have to justify all at once. The platform stops being load-bearing for anything except the part it is genuinely good at.
How many improvements are blocked behind a migration — measured by count of deferred items that become independently shippable.
How much the incumbent is load-bearing for — measured by list of capabilities that would be lost if it were switched off, before and after.
Quality evaluation coverage — measured by share of interactions evaluated versus the sample rate you run today.
Whether a replacement can be scheduled rather than negotiated — measured by existence of a component-level cutover plan with no single irreversible weekend.
Evidence available for a compliance request — measured by time to produce interaction evidence for a named case, tried before and after.
that the legacy platform becomes unnecessary. Telephony that connects calls reliably is doing a real job. The claim is that it stops being the reason everything else is blocked.
The interesting integration question is never the modern system. It is the one running an unsupported version behind a firewall with an interface documented in a PDF from a vendor that no longer exists.
We will tell you during assessment which of your components can be worked with, which need an intermediary, and which genuinely cannot — rather than discovering the third category during implementation, which is the usual sequence.
Identity comes from your identity provider. Evidence can stream to your SIEM. Records stay where your people already look.
The reasonable objection to this page is that you would be adding another dependency to escape one. So the exit terms matter more here than almost anywhere: governed state, workflows, history, evidence and receipts are designed to export, with reconstitution testing rather than export alone.
And the layer is deliberately not a place your configuration disappears into. The point of the architecture is that components stay replaceable — which has to include ours.
The security review for a layer in front of existing infrastructure is materially narrower than for a platform replacement, because the systems of record and the communications path do not change.
The reviews that do apply are the ones about recorded conversations, employee monitoring and payment paths — and those apply whether or not you modernise, so bringing them forward is not additional cost.
One capability that has been blocked behind the migration — quality coverage, assistance on one queue, or evidence for one compliance obligation — delivered without touching the incumbent.
Pick the thing that has been on the deferred list the longest. Delivering it without a migration is the argument, and it is more persuasive than any assessment document because it demonstrates the premise directly.
Do it on one queue, alongside the existing tooling, with the baseline taken first. The incumbent keeps running throughout and can keep running afterwards.
Only then discuss sequencing for replacing components — and by that point it is a scheduling conversation rather than a business case, because the capability no longer depends on it.
A fair objection and the right one to lead with. The difference has to be structural rather than promised: ask for the export and reconstitution procedure before signing, and check whether history and evidence survive replacement of the systems they describe. If we cannot answer those specifically, apply the objection.
They would, and from inside their architecture it is even true. The premise is that the capability lives in the platform. It does not have to — routing intelligence, assistance, quality and evidence can sit in front of the connection layer. The test is cheap: pick one deferred capability and see whether it can be delivered without touching the incumbent.
Possible, and we will say so during assessment rather than discovering it in implementation. Some components can be worked with directly, some need an intermediary, and some genuinely cannot. Knowing which of the three each of yours is has value even if you do nothing further, because it changes what the migration quote should actually contain.
Adding a layer in front is usually compatible with an existing contract in a way that replacement is not, but check your terms — some agreements restrict what may sit in the call path. That restriction is worth knowing now regardless, because it also shapes what leverage you have at renewal.