Selection: stop using feature checklists
A feature checklist cannot discriminate between the major platforms, because every vendor ticks every box truthfully. "Skills-based routing: yes." "Omnichannel: yes." "AI: yes." The checklist produces a tie, and the tie gets broken by whoever demoed best.
What discriminates is depth, flexibility, and cost at your scale. Our full evaluation framework — eleven dimensions, including the one everybody skips — is on the platform evaluations page. The short version:
- Routing flexibility when your rules don't match the vendor's assumed model.
- Reporting granularity at the interval you actually need.
- Real-time API rate limits at your concurrency, not at demo concurrency.
- Integration depth versus what you will build and then maintain.
- Commercial structure — concurrent versus named seats, telephony charges, AI metering.
- Exit cost. What it takes to leave, in three years, when your renewal is being negotiated.
The inventory that determines your timeline
Migration effort is driven almost entirely by integrations and by accumulated routing logic. Both are systematically underestimated because neither is documented.
| Inventory | What to capture | Common surprise |
|---|---|---|
| Routing logic | Every queue, skill, schedule, overflow rule, and priority weighting actually in use. | A large share of configured queues receive no traffic. Migrating them is wasted effort — but somebody has to determine which. |
| Integrations | CRM, WFM, ticketing, payment, dialer, recording, analytics, screen pop, agent desktop. | Undocumented point-to-point integrations built years ago by someone who has left. |
| Reporting | Every scheduled report and dashboard, plus who genuinely uses each. | Reports that nobody reads, and one report that a regulator requires. |
| Telephony | Trunks, DID ranges, toll-free numbers, RespOrg, carrier contracts. | The trunk migration is its own project. See TDM to IP. |
| Recordings | Volume, retention obligation, and format. | Retention periods measured in years, and no export path from the old platform. |
| Agent estate | Headsets, desktops, network, and how many agents are remote. | Remote agents on domestic broadband become your dominant voice-quality risk. |
Historical data: decide early, because it constrains everything
Historical interaction data and recordings rarely migrate cleanly. Schemas differ, metrics are defined differently, and recordings are often in proprietary formats. The three viable strategies:
- Run the old platform read-only for the retention period. Simplest and most reliable; you pay for a system nobody uses, which is usually cheaper than the alternative.
- Export to a data warehouse. Reporting continuity in one place, at the cost of building and validating the export.
- Migrate into the new platform. Attractive in principle, expensive in practice, and the metric definitions usually will not reconcile anyway.
The telephony workstream nobody scopes
A CCaaS migration is usually funded as a contact center project, and the trunk migration underneath it gets treated as a footnote. It is not. Number porting, SIP architecture, SBC configuration, feature parity, and 911 registration are a substantial project with their own dependencies and their own regulatory obligations.
Two decisions to make deliberately and early:
- Bring your own carrier, or use the vendor's telephony? Vendor telephony is simpler and usually more expensive at volume; BYOC gives control and commercial leverage but you own the SBC and the carrier relationship.
- Where does media terminate? This drives recording, quality measurement, and PCI masking architecture. See SIP trunking & SBCs.
Cutover: phase it
| Approach | Good for | Watch |
|---|---|---|
| Queue by queue | Most operations. Start with low-volume, low-complexity queues. | Needs a working split state — calls that must transfer between old and new platforms during the overlap. |
| Site by site | Multi-site estates with distinct teams. | Inter-site transfer and shared queues during the split. |
| Channel by channel | Moving digital channels first to de-risk voice. | Loses unified reporting during the transition. |
| Agent cohorts | Building internal expertise early. | Two systems to support simultaneously; supervisors need both. |
Whatever the sequence, the split-state design is the thing to get right. During the overlap you have two platforms, and calls will need to move between them. That transfer path — and what happens to context and reporting when it is used — should be designed and tested before the first queue moves, not improvised in week two.
Agent transition: the risk that isn't technical
The most common cause of a migration being judged a failure is not the platform. It is agents who cannot work efficiently on day one, so handle time rises, service level drops, and the project is blamed.
- Train on the configured system, not a generic vendor course.
- Plan for reduced productivity in the first weeks and staff for it explicitly. Pretending it will not happen does not prevent it — it just means you are understaffed when it does.
- Build a floor-walking support model for the first fortnight.
- Give supervisors more preparation than agents. They absorb the disruption on behalf of everyone else.
- Collect agent feedback formally in week one and act on it visibly.
Acceptance criteria
- Routing behavior verified against the documented rules, including overflow and out-of-hours.
- Reporting reconciled against the legacy platform for a parallel period, with the definitional differences documented.
- Voice quality measured against an agreed target on real agent connections, including remote workers. See voice quality.
- 911 tested from every endpoint class, including remote agents. See E911.
- PCI controls verified as technical rather than procedural. See PCI DSS.
- Every integration tested with production-like data volumes.
- Recording retention verified end to end, including retrieval — not just capture.
- Rollback path documented, with trigger conditions and a named owner.
Related reading
- Platform evaluations — the eleven-dimension framework and per-vendor notes.
- TDM to IP migration — the telephony workstream.
- AI agent evaluation — before layering AI on top.
Sources
We build the scorecard and the proof-of-concept scenarios — and we aren't paid by whoever wins.
Book a call