Two documents that disagree
The runbook for a legacy contact centre platform said the estate had forty-one queues. The configuration export from the same platform, taken the same week, listed just over four hundred entries carrying routing logic — vector steps, vector directory numbers, hunt groups, announcement branches, holiday tables and the after-hours conditionals nested inside them.
Neither document was wrong. The runbook described the estate as designed. The export described the estate as it had been patched, by five different administrators, over roughly a decade of Monday-morning fixes that nobody went back to document. Every serious problem in a legacy migration lives in the gap between those two documents, and the size of that gap is the single number that determines whether the project runs to plan.
This is not a lift-and-shift problem or a training problem, though it shows up as both. It is a discovery problem with a price attached, and the price can be calculated before the programme starts.
What is actually inside a legacy estate
A legacy private branch exchange or on-premise contact centre platform accumulates configuration the way a building accumulates wiring. Some of it carries live traffic today. Some of it was built for a product that was discontinued, a campaign that ended, or an office that closed, and it survives because deleting configuration on a production switch is a risk nobody volunteers for.
That distinction is the whole discovery problem, so it needs a definition tight enough to argue with. A live routing behaviour is one that at least one real interaction reached in a defined recent window — ninety days is a reasonable default, and thirteen months if the business has genuine seasonal peaks or statutory-deadline traffic. Everything else is dormant. Dormant configuration still has to be inventoried, because you cannot prove something is dormant without looking at it, but it does not have to be replicated, tested or accepted on the new platform.
In the estates we have taken apart, the live share of route points typically lands somewhere between a quarter and a half. Call it a third as a planning assumption and then measure it, because the assumption is doing a lot of work: it sets the size of the target you are aiming at.
Two things follow immediately, and both cut against the way migration scopes are usually written. Counting every configuration item is not the goal — replicating every configuration item certainly is not, and a scope that promises functional parity across the whole estate has promised to rebuild the dead parts. But you cannot know which parts are dead without spending money to look, and that spend is not free either.
Why the documentation you already have is not the answer
The artefact that would resolve this is a current business process narrative — a written description of each contact flow and its handoffs between teams, sitting alongside the diagram. Regulated organisations are expected to maintain exactly that. The FFIEC’s IT Examination Handbook notes that business process diagrams “often depict the handoff between departments that have a role in carrying out different parts of the business activity,” and that narratives “describe the entity’s business processes and related control points, often to support control reporting” (FFIEC IT Examination Handbook, Architecture, Infrastructure, and Operations III.C.3).
The expectation is reasonable. What we find on site is that the narrative was accurate on the day it was signed and has not been touched since, while the switch has been edited two hundred times. Documentation ages against a system that does not stop changing, which is why discovery has to sample the live system rather than read the file.
What audit coverage costs, and what missing a rule costs
Here is the trade, priced. The model below is illustrative, built on planning ranges rather than a single client’s figures, and the point of publishing it is that you can substitute your own four inputs and get a defensible number rather than a vendor’s confidence.
The estate has 400 configuration items carrying routing logic. Thirty-five per cent are live, so 140 live routing behaviours exist. Audit coverage, written as c, is the share of configuration items a human actually opens, traces and records. Each item examined costs 1.25 hours at the start, and marginal cost rises as coverage climbs, because the easy items are the ones with obvious names and recent edits — the last ten per cent are the undocumented overflow branches that require call-detail archaeology to interpret. Modelled as a linear rise, the average cost per item at coverage c is 1.25 × (1 + c) hours. Every live routing behaviour costs 2 hours to reproduce and accept on the new platform whether or not the audit found it, because that work is unavoidable. And every live routing behaviour first discovered in production — after cutover, by a customer hitting it — costs an additional 8 hours: triage, a change request, an out-of-hours fix, a regression test, and a conversation with whoever the misroute affected. Blended migration engineering at EUR 82 per hour.
Total cost is audit hours, plus production-discovery penalty hours, plus unavoidable build hours. It has a minimum, and the minimum is not at full coverage:
Coverage 0%: audit 0 h, production penalty 1,120 h, build 280 h. Total 1,400 h, EUR 114,800.
Coverage 30%: audit 195 h, production penalty 784 h, build 280 h. Total 1,259 h, EUR 103,238.
Coverage 50%: audit 375 h, production penalty 560 h, build 280 h. Total 1,215 h, EUR 99,630.
Coverage 62%: audit 502.2 h, production penalty 425.6 h, build 280 h. Total 1,207.8 h, EUR 99,039.60 — the optimum.
Coverage 80%: audit 720 h, production penalty 224 h, build 280 h. Total 1,224 h, EUR 100,368.
Coverage 90%: audit 855 h, production penalty 112 h, build 280 h. Total 1,247 h, EUR 102,254.
Coverage 100%: audit 1,000 h, production penalty 0 h, build 280 h. Total 1,280 h, EUR 104,960.
Read the last three rows before the others. Moving from 62% coverage to 90% removes 313.6 hours of production firefighting and adds 352.8 hours of audit to do it — a net loss of EUR 3,214.40 for a programme that looks, on every status report, more thorough. Exhaustive audit costs EUR 5,920.40 more than the optimum, a 5.98% overspend, and it buys a zero in a column that was never going to be zero anyway. Meanwhile 24% coverage costs exactly what 100% coverage costs, EUR 104,960, from the other side of the curve. Two programmes with wildly different discovery discipline, identical invoices.
At the optimum, 53.2 of the 140 live routing behaviours are not found before cutover. That is the number to put on the slide. It is not a failure condition, it is the plan — and a plan that says “we will find about 87 of 140 live behaviours in audit and absorb the rest in the first three weeks live” is a plan you can staff, whereas “full functional parity at go-live” is a plan you can only miss.
Note also where the money sits at the optimum: 41.58% audit, 35.24% production discovery, 23.18% unavoidable build. Less than a quarter of the spend is the work everyone thinks they are buying.
The three thresholds that move the answer
The optimum moves, and it moves on inputs you can measure rather than negotiate.
1
Live share 46.875%.
If more than 46.875% of your configuration items carry live traffic — 187.5 items out of 400 — exhaustive audit becomes the cheapest option outright. A dense, actively used estate should be audited end to end. A sprawling estate with a decade of abandoned branches should not.
2
Production penalty 10.71 hours.
If a live rule discovered in production genuinely costs you more than 10.71 hours all-in, audit everything. Regulated environments with change-freeze windows and mandatory post-implementation review clear that bar easily; a small internal helpdesk does not.
3
Production penalty 3.57 hours.
Below that, audit stops paying for itself entirely and the honest answer is to migrate fast, staff the first month heavily and fix things live. That is a legitimate strategy for a low-stakes estate, and pretending otherwise to justify a discovery engagement is how consultancies lose reference calls.
One arithmetic point worth stating plainly, because it is where most quoted numbers go wrong: at the optimum, audit is costing 5.79 hours for every live rule it finds, against 8 hours to find that rule in production. The margin is thin. Anyone quoting a discovery phase that pays for itself several times over is not modelling the convexity — they are pricing the last configuration item at the same rate as the first.
The rows you audit regardless of what the model says
The model above optimises cost. Four categories of configuration are not cost decisions, and they get audited at 100% coverage whatever the arithmetic says, because the downside is a regulator rather than a rework ticket.
Recordings that may contain payment card data
If agents ever take a card number by phone, the recording path is not negotiable. PCI DSS Requirement 3.3.1 prohibits storage of sensitive authentication data after authorisation even when encrypted, and the Council is explicit about audio: storage of card validation codes or values “in any form of digital audio recording—for example, .wav or .mp3 files—after authorization is therefore a violation of this requirement” (PCI SSC FAQ 1210, June 2025).
The same FAQ sets the order of preference, and it is stricter than most migration scopes assume. Where technology exists to suppress or redact audio during data entry, “it should be enabled.” Where it is not possible to prevent recording, the data “should be securely deleted immediately upon authorization.” Only where secure deletion is impossible for legitimate technical or business reasons do compensating controls apply, and those controls carry their own workload: annual risk assessments and reassessment on significant change, controls preventing access to and querying of the recordings, and documented justification and evidence validated at annual assessment.
A platform migration is a significant change to the environment by any reading. So the audit question is not “does pause-and-resume exist on the new platform” but “for every route that can reach a payment step, which of those three positions are we in, and who has written it down.” Whether your specific configuration satisfies Requirement 3.3.1 is a determination for your qualified security assessor, not for a migration partner — but the inventory of routes that touch a payment step is a migration deliverable, and it is cheap to produce during discovery and expensive to reconstruct afterwards.
Emergency calling and location
Direct 911 dialling and dispatchable location are the requirements most often discovered late, because on a legacy system they were configured once, years ago, and have never been tested. In the United States, the FCC’s rules implementing Kari’s Law and Section 506 of RAY BAUM’S Act require that a multi-line telephone system be configured so a user can dial 911 without any prefix, that a 911 call trigger contemporaneous notification to a central on-site or off-site location including the fact of the call, a callback number and the location information conveyed to the answering point, and that dispatchable location be delivered with the call (FCC, Multi-line Telephone Systems — Kari’s Law and RAY BAUM’S Act requirements).
The detail that matters for migration planning is the exemption. The FCC states that the rules “are forward-looking and do not apply with respect to any MLTS that is manufactured, imported, offered for first sale or lease, first sold or leased, or installed on or before February 16, 2020.” A legacy estate installed before that date may sit legitimately outside the direct-dialling and notification obligations. The replacement platform does not. Migration is therefore the moment the exemption ends, and dispatchable location for on-premises fixed devices, on-premises non-fixed devices and off-premises devices carries distinct obligations with distinct compliance dates. Treat it as a design requirement in discovery, not a defect found in user acceptance testing.
Change evidence and the end-of-support clock
The reason these programmes start is usually that a vendor has moved a release toward the end of its support life, and the reason they are painful is that the estate was never tracked against that clock. The FFIEC’s guidance on the point is worth reading before writing the business case, because it frames end-of-life as an inventory discipline rather than an event: management “should implement policies, standards, and procedures to identify assets and their EOL time frames, to track assets’ EOLs, and to replace, or upgrade, the asset,” and failure to do so “could have operational or security implications (e.g., unavailable or unapplied security updates [patches] that make technology vulnerable to disruption).” It also directs that end-of-life be addressed “in contract provisions with its third-party service providers” (FFIEC IT Examination Handbook, AIO III.B.2 IT Asset End-of-Life).
The practical consequence for migration is the shape of your evidence pack. The same handbook sets out what a change should carry: a documented request with “impact analysis to identify risks and affected systems, change time frame, and back-out plan,” approval mechanisms “commensurate with the scope, cost, urgency, and overall risk,” documented testing that “the change performs as intended,” and after deployment a post-implementation review “to verify that the change was implemented successfully and achieved performance objectives” (FFIEC IT Examination Handbook, AIO III.D.1 Change Management).
Read that list against a cutover plan and one item usually missing jumps out: the back-out plan. Not a slide saying rollback is possible — a tested procedure, with a stated decision point and a named person who can invoke it.
Consultation where the work changes shape
Migration changes how agents work: screen layout, wrap-up steps, where the knowledge article lives, whether the summary is typed or reviewed. In the EU, that can trigger a legal duty rather than a change-management courtesy. Directive 2002/14/EC requires information and consultation on “decisions likely to lead to substantial changes in work organisation or in contractual relations,” and specifies that information be given “at such time, in such fashion and with such content as are appropriate to enable, in particular, employees’ representatives to conduct an adequate study and, where necessary, prepare for consultation” (Directive 2002/14/EC, Article 4).
Practical arrangements are set by national law and vary considerably across member states, and the thresholds matter — the Directive applies, at member states’ choice, to undertakings with at least 50 employees or establishments with at least 20. Whether your specific programme triggers a consultation duty is a question for employment counsel in each jurisdiction you operate in. What belongs in the migration plan is the lead time: consultation that has to enable “an adequate study” cannot start the week before cutover, so it sits in the discovery phase alongside the routing audit, not in the deployment phase alongside the training.
What you deliberately leave uncounted, and how you say so
Every model above assumes the audit that gets bought is a real audit. The failure mode we see most often is the one that looks like success.
Discovery runs. It produces a spreadsheet with four hundred rows. Each row has the configuration item’s name, its type, and a status column reading “active” or “unknown”. No row has a monthly volume. No row names the business process it serves or the team that owns the outcome. Nobody can say which of the four hundred are the 140 that matter, so the migration scope is written against everything, the build estimate triples, and the parts that get cut under time pressure are cut by whoever is closest to the deadline rather than by whoever understands the traffic.
That register is not discovery. It is a list of things that exist, which the configuration export already provided for free.
The test is one column. Does every row carry an interaction volume for the defined window, from call-detail data rather than from someone’s recollection? If not, the audit has counted objects rather than behaviour, and the coverage figure in your plan is measuring nothing. The second test is a sample: take the twenty highest-volume rows and ask, for each, which business outcome breaks if it misroutes. If the answers come back in platform language — “it overflows to the secondary skill” — rather than business language — “the customer waiting on a delivery exception gets a general queue and calls back twice” — the register has not been read by anyone who owns the outcome.
And then say what you are not counting, in writing, before cutover. The register should end with a stated exclusion list: these route points were inventoried and judged dormant on this date, on this evidence, and will not be replicated. If one of them turns out to be live, it becomes a change request with a known price rather than an argument about scope. That is the sentence that converts 53.2 unfound behaviours from a hidden risk into a budgeted one.
Metrics that should get worse, and by how much
The standard migration scorecard is built entirely from numbers that are supposed to improve, which makes it useless for detecting the failure everyone is actually worried about. Handling time falls, abandonment falls, occupancy rises, and none of that tells you whether calls are landing in the right place.
So pair each headline with the number you expect to deteriorate, and state the tolerance band in advance. Declared before cutover, a band is a control. Declared afterwards, it is an excuse.
- Handling time will fall as the new desktop removes toggling. Pair it with transfer rate between queues, which should rise by something in the range of two to five percentage points in the first three weeks as agents rediscover routing that the audit missed, then return to baseline by week six. If transfer rate does not move at all, the audit either found everything — unlikely at 62% coverage — or nobody is logging transfers properly on the new platform.
- Abandonment will fall with better queue treatments. Pair it with repeat contact within seven days on the same issue, which should rise slightly and then fall below baseline. A flat repeat-contact line during a routing change means the field is not populated or the matching logic is broken.
- First-contact resolution will look strong immediately, because the new reporting counts differently. Pair it with the share of interactions whose disposition code was changed after the fact, which should spike while agents learn the new code set. No spike means agents are picking the first available code, and your resolution number is measuring habit.
A migration dashboard where every line moves the flattering way in week one is not evidence that discovery was thorough. It is evidence that the instrumentation was rebuilt to match the story.
Put the exit terms in before you sign the entry terms
Most procurement attention on a migration goes to what the partner will deliver. The clause that protects you is the one describing how they leave — and it matters more here than on almost any other engagement, because the asset you are buying is knowledge of an estate that only exists inside people’s heads while the work is happening.
Five things belong in the transition-out schedule, agreed at signature rather than negotiated during handover:
- The discovery register, as a deliverable you own outright, in a machine-readable format, including the exclusion list and the evidence behind every dormant judgement. Not a report about the register. The register.
- A named coverage figure and the method behind it. If the partner audited 62% of configuration items, the schedule says 62%, says how items were counted, and says which 38% were not opened. A partner who will not state a coverage figure is telling you they did not measure one.
- The back-out procedure, tested and evidenced, with the decision point, the maximum time to invoke, and the person authorised to call it. The FFIEC’s change list treats the back-out plan as part of the original request, not a contingency invented at cutover.
- A knowledge-transfer artefact for day-to-day operations, distinct from training material. The same handbook makes the point that knowledge gained through change management “should be effectively transferred in a useful format to personnel responsible for operating the systems and processes.” In practice that is the runbook for the twenty highest-volume flows, written for the person who will be on call at 2 a.m. in month four.
- A stated price and lead time for post-exit assistance, so that the first production discovery after handover does not become a commercial negotiation conducted during an incident.
The reason to write these at the start is unglamorous. Transition-out terms are cheap to agree when both parties expect a successful engagement and expensive to agree when one party is already unhappy.
The Path Forward
The sequence that works is short. Export the configuration and count the items, so you know the denominator. Pull ninety days — or thirteen months, if your traffic is seasonal — of interaction data against those items and calculate your live share, so you know the numerator. Put your own four inputs into the model above and read off a coverage target instead of accepting one. Audit to that target, in volume order, and write the exclusion list. Then handle the four compliance categories at full coverage regardless of what the model said, and declare your tolerance bands before you cut over.
That is a plan whose failure modes are all visible in advance, which is a different kind of project from one whose scope says functional parity.
If you want a second read on a specific estate, our contact centre migration work [link “contact centre migration work” → /cxone-certified-implementation-partner/] usually starts with exactly the count described above, and the patterns are consistent enough across estates that the first week tends to be predictive.
Before you commit to a coverage figure, do one thing this week. Pull your configuration export, take the twenty route points with the highest interaction volume, and for each one write down the business outcome that breaks if it misroutes. Set your own pass mark before you start — we would call fewer than fifteen clear business answers out of twenty a failing result, because it means the estate is understood at platform level and not at process level. Whatever threshold you pick, pick it before you look. The number you get is the honest input to every other number in your migration plan.
Frequently Asked Questions
How long should discovery take on a legacy contact centre estate?
Long enough to open the share of configuration items your own arithmetic justifies, which for a 400-item estate at a one-third live share works out to roughly 250 items and about 500 engineering hours. Compressing that below the point where interaction volumes can be attached to each item does not save time — it moves the same work to the three weeks after cutover, where it costs more per item and happens in front of customers. The useful planning question is not the duration but the coverage figure and the evidence standard behind it.
Can a migration guarantee zero downtime?
No responsible partner should offer that as a guarantee, and a scope that contains the phrase is worth reading twice. What can be engineered is a tested rollback with a stated decision point, a phased cutover by queue or by site so that a fault affects a bounded share of traffic, and a monitored first three weeks with named on-call ownership. That is a materially different promise from zero downtime, and it is the one that survives an incident review.
We only take card payments occasionally. Do the recording rules still apply?
Frequency is not the test — reachability is. If any route can reach a step where a card number is spoken, that route is in scope for the recording question, and PCI DSS Requirement 3.3.1 prohibits storing card validation codes after authorisation in any form of digital audio recording. The Council’s stated order of preference is suppression or redaction during data entry first, immediate secure deletion after authorisation second, and documented compensating controls only where neither is technically possible. Whether your configuration satisfies the requirement is a determination for your qualified security assessor; producing the list of routes that can reach a payment step is migration work, and it is far cheaper during discovery than after.
Our legacy phone system predates the FCC's 911 rules. Does replacing it change that?
Almost certainly, yes. The FCC’s rules are forward-looking and do not apply to a multi-line telephone system installed on or before 16 February 2020, so a genuinely old estate may sit outside the direct-dialling and notification obligations. A replacement platform installed now does not benefit from that exemption. Direct 911 dialling without a prefix, contemporaneous notification to a central location, and dispatchable location for fixed, non-fixed and off-premises devices should therefore be treated as design requirements from the first week of the programme, not as compliance items tidied up before go-live.
Do we have to consult employee representatives before changing the agent desktop?
Possibly, and the answer is jurisdictional. EU Directive 2002/14/EC requires information and consultation on decisions likely to lead to substantial changes in work organisation, with information provided in time for representatives to conduct an adequate study — but practical arrangements are set by national law, and the Directive applies, at each member state’s option, to undertakings with at least 50 employees or establishments with at least 20. Take the specific position from employment counsel in each country you operate in. What belongs in the plan regardless is the lead time, because consultation that has to precede a decision cannot sit in the deployment phase.
References
PCI Security Standards Council, FAQ 1210, “Are audio/voice recordings permitted to contain sensitive authentication data?”, June 2025 — cited for the prohibition on storing card validation codes in digital audio recordings after authorisation under PCI DSS Requirement 3.3.1, the stated order of preference (suppression or redaction during entry, then immediate secure deletion, then compensating controls), and the four minimum elements of the compensating-control process including annual and on-significant-change risk assessments. Read in full at source; the FAQ is dated June 2025 and carries article number 1210. It refers onward to the Council’s “Protecting Telephone-Based Payment Card Data” information supplement, which is published only as a PDF and was not used here.
FFIEC IT Examination Handbook, Architecture, Infrastructure, and Operations, III.B.2 IT Asset End-of-Life — cited for the requirement to identify and track assets’ end-of-life time frames and plan replacement, for the stated operational and security consequence of failing to do so, and for the direction to address end-of-life in contract provisions with third-party service providers. Read at source.
FFIEC IT Examination Handbook, Architecture, Infrastructure, and Operations, III.D.1 Change Management — cited for the composition of a documented change request including impact analysis and back-out plan, for approval mechanisms commensurate with scope and risk, for documented testing, and for the post-implementation review. Read at source. The adjacent section III.D.2 supplied the point about transferring operational knowledge in a useful format to the people who will run the system.
FFIEC IT Examination Handbook, Architecture, Infrastructure, and Operations, III.C.3 Business Process Diagrams and Narratives — cited for the description of business process diagrams as depicting departmental handoffs, and of narratives as describing processes and control points to support control reporting. Read at source.
Federal Communications Commission, “Multi-line Telephone Systems – Kari’s Law and RAY BAUM’S Act 911 Direct Dialing, Notification, and Dispatchable Location Requirements” — cited for the direct-dialling requirement, the three minimum contents of the 911 notification, the exemption for systems installed on or before 16 February 2020, and the separate dispatchable-location obligations for on-premises fixed, on-premises non-fixed and off-premises devices. Read at source, including the cited rule references at 47 CFR §§ 9.3, 9.16 and 9.17(b). The underlying regulation text at eCFR could not be retrieved in this session, so only the Commission’s own summary page is relied on here.
Directive 2002/14/EC of the European Parliament and of the Council of 11 March 2002, Article 4 — cited for the duty of information and consultation on decisions likely to lead to substantial changes in work organisation or contractual relations, for the requirement that information be given in time to enable an adequate study, and for the Article 3 scope thresholds of 50 employees per undertaking or 20 per establishment at member states’ choice. Full consolidated text read at source on EUR-Lex.
