Three weeks before a contact center cutover, someone remembers the fax queue. Or the VIP routing rule. Or the nightly export that feeds a finance report no one on the migration team has ever seen. The technology may be ready. The organization is not. That is how an apparently tidy platform replacement becomes a rescue operation: not through a spectacular software failure, but through one ordinary dependency that never made it onto the plan.
The lesson for 2026 is blunt. A contact center migration is not primarily a transfer of seats from one vendor to another. It is an operating-model change involving carriers, customer records, workforce schedules, authentication, reporting, training and the small accommodations accumulated over years. The old platform is not simply a product. It is an archaeological site.
Modern platforms make the surface look unified. UJET, for example, describes an intelligent omnichannel environment spanning voice, chat, SMS, social and email, with CRM context and web and mobile software development kits. Its current package comparison also separates capabilities such as standard and advanced reporting, APIs and data exporting, digital channels, workforce management and outbound dialing. That breadth is useful. It is also a map of the questions a migration team must answer before anyone circles a launch date.
“The old platform is not a product. It is an archaeological site.”
Begin with what people do
Most inventories begin with configuration: enabled connectors, defined queues, licensed channels. That produces a neat spreadsheet and a dangerous illusion. Configured does not mean used; unconfigured does not mean unimportant. A browser bookmark, desktop shortcut or manually emailed file may carry more operational weight than a connector switched on five years ago.
Build a usage ledger instead. Review authentication and API logs. Observe agents across shifts. Interview supervisors, quality teams, workforce planners, fraud specialists and the people who prepare executive reports. Run the exercise during an ordinary week, then ask what changes on payday, during an outage or at seasonal peak. Every dependency should have evidence of use, a business owner, a replacement decision and a test case.
Give history a permanent address
A migration does not require every byte of history to move into the live system. It does require a deliberate answer for every class of record. Recordings may serve quality reviews or legal holds. Transcripts may feed coaching. Disposition codes may power forecasting. A dashboard can be retired while its monthly totals remain necessary for board reporting.
Decide what moves, what remains in a searchable read-only archive and what can be deleted under policy. Then test the exit mechanics with representative data, including attachments, timestamps, agent identifiers and conversation threads. The crucial reporting question is not, “Does the new platform have dashboards?” It is, “Will Monday’s metric still mean the same thing on Tuesday?” Reconcile definitions for contacts, offered interactions, abandons, transfers and service level before leaders compare the two systems.
destinations for old data: migrate it, archive it with access, or delete it under policy. “We’ll figure it out later” is not a destination.
Put a name beside every route
Routing diagrams rarely capture the whole truth. Hours, holidays, skills, language, customer tier, authentication state, queue depth and last-minute overflow decisions all shape where a conversation lands. The most fragile rules are often exceptions: the route that activates during a product recall, sends a premium customer to a specialist or plays a regulatory message in one jurisdiction.
Document the intent as well as the mechanism. Then put a person’s name beside it. Technical teams can rebuild a flow, but only a business owner can say whether its behavior is still wanted. Where there is no owner, the team has found an unresolved decision—not permission to copy the rule blindly.
Test channels as journeys
Feature parity is too small a test. A voice call can connect while arriving without customer context. A chat can transfer while dropping its transcript. An SMS can send while consent or opt-out behavior fails. UJET’s omnichannel material emphasizes consistent experiences across channels and real-time CRM context; those promises show why tests must follow the customer’s journey, not merely confirm that each channel turns on.
For every major intent, test entry, authentication, routing, media sharing, transfer, escalation, disposition and reporting. Include a channel switch. Include a network interruption. Include the moment an agent asks for a screenshot or a supervisor takes over. The end-to-end result is the product customers experience.
Train for the ugly minute
A generic tour of a new desktop is not a readiness program. Segment training by role and workflow. Let agents practice with realistic cases in a safe environment. Give supervisors separate instruction on live monitoring, queue intervention, emergency messaging and incident escalation. Give support teams a searchable guide for the first week.
Most important, rehearse exceptions: missing CRM context, failed authentication, a transfer to the wrong skill, an unavailable disposition, a delayed message and a customer who changes channels mid-conversation. Those are the moments that turn uncertainty into longer handle times and stressed customers. Measure proficiency before cutover and schedule floor support by shift, location and language afterward.
“If nobody owns a routing rule, the routing rule owns the migration.”
Run numbers as their own program
Phone-number porting deserves a workstream, not a line item. Confirm ownership records, authorization names, service addresses and carrier requirements early. Inventory toll-free, local, international, fax, emergency and outbound caller-ID numbers. Map dependencies such as forwarding, call recording announcements and location services.
Sequence ports to contain risk. Pilot lower-volume numbers, preserve controlled forwarding where possible and specify what happens if one carrier completes while another does not. Avoid stacking every irreversible change into the same hour. A successful technical cutover with unreachable public numbers is still a failed launch.
Make rollback a verb
“We can go back” is not a plan. Define thresholds for customer connection failures, routing accuracy, audio quality, agent access, data capture and reporting lag. Name the person authorized to stop or reverse the launch. Record the point after which data or carrier changes make reversal materially harder.
Then rehearse it on a clock. Restore traffic, preserve interactions created in the new system, communicate to agents and customers, and confirm that the former environment still has the capacity and credentials required. A rollback plan that has never been timed is optimistic prose.
- Usage — Which integrations and workarounds appear in real shifts?
- History — Where will recordings, transcripts and reports live?
- Routing — Who approves every rule and exception?
- Journeys — Does context survive transfers and channel changes?
- People — Can agents and supervisors handle failure states?
- Numbers — Is each port owned, sequenced and reversible?
- Rollback — Are triggers, authority and elapsed time known?
- Exit — Can the organization retrieve and delete its data?
Read the contract backward
Before signing the next agreement, imagine leaving it. Confirm export formats, API availability, volume limits, assistance fees, retention windows and deletion procedures. Ask who owns phone numbers and how quickly they can be released. Spell out the treatment of recordings, transcripts, attachments, configuration, quality evaluations and derived analytics. UJET’s package page, for example, explicitly lists APIs and a Data Exporter in several packages—exactly the kind of capability teams should verify against their chosen tier and expected exit needs.
The best migration checklist does not make a project risk-free. It makes risk visible soon enough to choose. That is the difference between discovering a load-bearing dependency three weeks before cutover and resolving it three months before. Software can be provisioned quickly. Operational truth takes longer to excavate. Start there.
Primary references: UJET Intelligent Omnichannel and UJET Packages and Pricing.