CCaaS Migration Has a Two-Platform Problem

Picture the first Monday of a phased contact center migration. The new cloud queue is open. Billing still runs on the old platform. A customer phones about a refund, gets transferred, and discovers that yesterday’s chat might as well have happened to somebody else. Both platforms are working. The service is coming apart at the seam.

Cloud contact center as a service, or CCaaS, promises a simpler future. Getting there can require a complicated present: two routing engines, two reporting systems, and people expected to make the combination look effortless. Coexistence is the period when legacy and cloud serve customers in parallel. It deserves its own operating plan.

The useful question comes before the next queue moves: what must remain continuous when the platform changes? Start with the customer record. Then work outward to transfers, agent availability, measurement, and an exit date. Otherwise, the temporary arrangement develops a remarkable talent for becoming permanent.

01Split the queue. Keep the customer.

Choose a migration boundary people can explain: a service line, region, or agent group. A percentage split can test capacity, but sending each contact to a random platform may scatter repeat contacts. Prefer a stable rule where practical, and write down which platform owns each entry point. AWS’s deployment guidance describes phased approaches by business line and agent location, with hybrid arrangements where transfers must carry context.

Give both platforms the same CRM customer and case identifiers. Decide which system may update each field, how duplicates are resolved, and what happens when a write fails. Retry safely; repeated delivery must not create repeated cases. A shared customer record is useful only if yesterday’s promise survives today’s routing decision.

UJET’s CRM architecture puts customer data in the CRM or a private data repository and supports automatic record updates. For coexistence, that suggests a practical advantage: the new platform can use an established customer record. The legacy side still needs a working integration. A CRM-first destination cannot repair an abandoned connector by association.

02A transfer needs more than a telephone number

Now send the refund caller across the boundary. Can the receiving agent see the case, the reason for contact, the steps already attempted, and the outcome of authentication? Agree how authentication evidence is represented and whether the destination accepts it. Don’t make customers pass a second test because two teams failed to agree on the first.

Test both transfer directions, including a busy destination and a failed lookup. A voice connection can succeed while the case reference disappears. Establish a fallback: a warm introduction, a case link, and a named owner who retains responsibility until the handoff completes.

The same discipline applies when chat becomes voice. UJET’s omnichannel offering describes CRM context presented at connection and messaging content saved to the CRM. During migration, verify what actually crosses into the old environment. Feature lists tell you what a platform can do; a rehearsal tells you what your combination does.

“A shared customer record is useful only if yesterday’s promise survives today’s routing decision.

03Two dashboards can both be right—and still mislead

At Friday’s review, the cloud dashboard reports shorter handle time. Celebration is premature if the pilot took simple enquiries while complex disputes stayed on legacy. Compare like-for-like work: channel, queue, intent, and time period. Keep the platform label visible so a changing workload mix cannot masquerade as improved performance.

Build a shared metric dictionary before combining exports. Define when queue wait starts, what counts as abandonment, and whether hold and after-call work belong in handle time. Normalize time zones and map agent identities. Calculate blended averages from total durations and matching contact counts; averaging two averages gives a small queue the same influence as a large one.

Preserve the relationship between a customer journey and its platform-specific contact legs. One transferred customer can generate two records without making two independent enquiries. Keep those legs for operational analysis; define the deduplication rule for journey reporting. Historical recordings can remain in an accessible archive, linked through the case where possible. Moving live traffic need not mean rewriting every old report.

04One sign-in is only the beginning

An agent should not need a second set of credentials to cover the migration boundary. Federate both platforms through the organization’s identity provider where supported, align permissions, and test session expiry. UJET announced integrations with Okta, OneLogin, and Microsoft ADFS in 2020; confirm the configuration available for the deployment in front of you.

Single sign-on solves authentication. It does not coordinate availability. If two routing engines both see an agent as ready, both may offer work. Assign agents to one platform per shift or migration wave unless a tested integration coordinates presence and channel capacity across both. A second browser tab is a poor workforce manager.

Keep the CRM as the everyday workspace where integrations allow. Rehearse the full shift: opening a case, accepting work, transferring it, recording the outcome, and signing out. Train supervisors on the boundary too. Someone must know which queue owns a stranded contact and which system can release it.

A second browser tab is a poor workforce manager.

05Give the middle an expiry date

How long should parallel operation last? For a bounded pilot, plan in weeks and review weekly. A programme spanning countries, carriers, or many business units may need months, with a separate closure date for each wave. These are planning recommendations, not a published industry benchmark. The right duration follows dependencies and evidence, rather than a universal countdown.

AWS’s migration guidance warns that longer dual operation increases cost, operator burden, and opportunities for mistakes. Track duplicate licenses, infrastructure, integrations, and support hours together. Every extension should name its blocker, owner, remedy, and next decision date. Two quiet platforms still send two invoices.

Set exit gates before launch: agreed service levels met through representative demand; transfers and record updates verified; reporting reconciled; supervisors ready; and rollback rehearsed. Specify the observation window and acceptable error rates locally. Freeze unnecessary legacy changes. If the same blocker survives successive reviews while no queue retires, coexistence is becoming an operating model. Escalate the decision.

06Retire the workload before retiring the evidence

UJET’s 2026 Switching Report presents CRM integration as a recurring reason customers change platforms. It is vendor-reported evidence about buying decisions, rather than a study of coexistence duration. Its relevance to the messy middle is the architecture: keeping customer context anchored while the machinery around it changes.

When a wave passes its gates, stop new traffic to legacy, drain open work, and reconcile outstanding updates. Keep recordings and history accessible under the applicable retention policy. Release numbers, licenses, and infrastructure only after their remaining dependencies are resolved. Separate a short rollback window from an ongoing production commitment.

Return to that Monday caller. The refund case opens with the previous conversation intact. The transfer arrives with a reason, an owner, and enough context to continue. Later, the legacy queue closes. The customer notices none of it. That is the migration worth applauding: a temporary complication that knows how to end.