Cloud migration from your existing system

#Why step by step

A contact centre cannot move like an office that closes on Friday and reopens somewhere else on Monday. Customers call at weekends, callbacks have been promised, carrier contracts keep running. A migration has to succeed while operations continue.

The safest route is gradual: channel by channel, team by team. Each step is small enough to reverse if something goes wrong, and large enough to learn from for the next one. This guide describes a sequence that holds up in practice.

#Project organisation

A migration touches customer service, IT, telephony, privacy, procurement and often the works council. Without clear organisation, decisions end up with whoever asks loudest. So decide at the outset who decides what.

• Steering group: decides on sequence, budget and switch-off dates.
• Project lead: keeps plan, risks and dependencies together.
• Customer service owner: responsible for routing, voice menus and acceptance.
• IT and telephony: responsible for network, carriers, integrations and security.
• Privacy and works council: review contracts, the impact assessment and agreements.

Plan in waves, not a single date. Each wave has its own date, its own teams and its own acceptance criteria. How long it takes depends on your estate; a reliable plan only exists once the inventory is done.

#Inventory: what actually runs today

Most migration surprises come from the inventory, or rather from what it misses. A forgotten number printed on a leaflet, a holiday announcement, an interface that syncs data overnight. Give this phase more time than feels comfortable.

For every item, ask: do we still need this? A migration is the best chance you will get to leave behind seven-level voice menus and reports nobody reads.

#Target state and sequence

The target state describes how contacts flow after the migration, not how to rebuild the old system. Modern platforms distribute voice, chat and email in one shared call distribution. That changes how queues and skills are cut.

There are two proven patterns for sequencing. Either start with a digital channel that has little volume today, such as web messaging. Or start with a small team that moves all of its channels at once.

Keep the customer’s view in mind as well. If a number, an announcement or the website chat changes, customers should not experience it as a break.

Familiar numbers stay, new routes are announced, and nobody lands in an announcement that refers to yesterday’s menu.

Both routes get you there. What matters is that the first step is small enough to reverse without risk to overall operations. The post A pilot with one team and one channel explains what such a pilot should prove.

Add-ons

Semantic²Univerx Channel

Platform

Contact CenterAIWorkforceJourneysOutboundMarketplace & DeveloperServices

Univerx Cloud

Europe layer

GDPREU data residencyEU AI ActBSI C5eIDASNIS2DORABFSG / EAA

#Connecting telephony

Telephony is the part of a migration with the most dependencies. Your numbers belong to you, but they sit with a carrier. Existing phone systems often serve the rest of the company. There is no single route, but three options you can combine.

With Univerx you take numbers from the platform, connect your own carrier, or replace existing systems step by step via SIP. The pages on voice services & telephony and telephony integration have the details.

#Moving numbers

When numbers change carrier, that is a port. It needs lead time, paperwork and a fixed date. Plan the port so that a way back remains, for example by forwarding from the old system until the new route runs reliably.

#Rethinking routing and voice menus

It is tempting to carry queues and voice menus over one to one. But then you also migrate every workaround that has built up over the years. Use the migration to simplify the structure.

Start from requests, not menus. Why do people call today, and which skill does each reason need? Queues and rules follow from that. Voice menus get shorter when simple requests are resolved directly through IVR & self-service.

A quick win is the callback. Instead of keeping customers on hold, the system offers to call back as soon as someone is free. The post Callback instead of hold shows why this small switch makes a big difference.

#Moving digital channels

Digital channels have a feature telephony lacks: open conversations. An email from yesterday, a paused chat, a message in a messaging app waiting for a reply. At cutover, none of these may be lost or handled twice.

A clean cut has proven itself: from the switch date, new contacts run through the new platform, while open items are finished in the old system. For email, that means redirecting the mailbox and working the backlog down deliberately.

For website chat, the embed script is swapped. Check accessibility, the privacy notice and AI disclosure if an AI agent handles the first contact. Messaging app and social media accounts are reconnected; the access rights for those often sit with marketing, not IT.

#Integrations and data

A contact centre without customer context is a phone book. The most important integrations therefore belong in the first move: recognising customers on incoming contacts, showing history and writing the outcome back to the business system.

Ready-made connectors for common CRM and ticketing systems are in the Marketplace. Everything else is connected through open APIs and webhooks. For each integration, check whether it must run in real time or as a nightly sync.

#Historical data and recordings

Old recordings and reports do not move automatically. Decide per data type: migrate, archive in the old system until retention ends, or delete. Retention periods from your retention and deletion policy still apply to recordings when the system changes.

For reporting across the cutover date, a shared data model in your own data warehouse helps. The platform can stream analytics data there through BI export.

#Network and workstations

In the cloud, voice travels over your data network. Call quality therefore depends on bandwidth, latency and how voice traffic is prioritised. Have the network measured before the first wave, at every site and on typical home set-ups.

The workstations themselves belong on the list too: approved browsers, headsets tested with the platform and firewall rules for the required connections. A test call from every room and every home-office profile is cheaper than a week of poor voice quality.

#Privacy, security and the works council

A new platform changes how personal data is processed. A new data processing agreement is needed, the impact assessment needs updating and the record of processing activities gets new entries.

Settle early which regions hold data and media. Univerx processes data in EU regions of your choice; hosting in Germany is planned. The sub-processor list is available on request.

Existing works agreements often refer to a specific system. Check whether they need adjusting, and involve the works council before the first teams move. The guide Running a contact centre in Europe sets out the rules in detail.

#Training teams

In many migrations, training comes too late and too broad: one big session two weeks before go-live, the same for everyone. Training by role works better, shortly before your own team moves and with real cases.

Before the move, give every team access to a practice environment with realistic sample cases. A single page with the ten most common desktop actions helps more in the first days than any manual.

Key users in every team have proven their worth. They are trained earlier, help with testing and are the first port of call in the days after cutover. Training paths and certification are available through Academy & support.

#Planning the cutover

Every cutover follows a fixed sequence. It is written in advance, walked through with everyone involved and rehearsed in the first wave. The steps below are a frame for you to fill in with your teams.

1. Configuration sign-off. Routing, voice menus, integrations and roles are tested and accepted.
2. Change freeze. From a fixed date, no flows are changed in the old system.
3. Dress rehearsal. Test calls, chats and emails along every route, on real workstations.
4. Switch over. At a quiet time, with key users on site and an open line to the project team.
5. Fallback route. Clear criteria for switching back, and who makes that call.
6. Supported start. Short daily check-ins until things are stable.

Keep each team’s cutover as small as possible. Two quiet cutovers beat one that has too much riding on it.

#Metrics before and after cutover

After every cutover comes the question: is it better? You can only answer it if metrics are defined the same way before and after. With a change of system, that is rarely the case.

Take the service level. Do calls abandoned in the first few seconds count or not? Does waiting time start with the call or after the voice menu? Two systems often answer differently, and suddenly the new platform looks better or worse than it is.

So write a short metrics sheet before the first wave: definition, source, calculation. Collect the figures in the old system for four weeks before cutover, then compare only what is defined the same way. Seasonal effects belong in the assessment.

#Risks and countermeasures

Most migration risks are well known. Naming them is the easiest way to shrink them. The table shows the most common ones and what helps.

#After cutover

A migration is only finished when the old system is switched off. Until then it costs money, adds security risk and causes confusion. Set the switch-off date as soon as the last wave runs reliably.

After each wave, note what went well and what did not. Those notes are worth more for the next wave than any project plan, because they come from your own operation.

Then the phase begins that makes the migration worthwhile. New channels, AI agents, workforce management and continuous updates without upgrade projects now arrive without new infrastructure. Plan the next steps deliberately rather than switching everything on at once.

#Checklist

#Support from Univerx Services

You do not have to do this alone. Univerx Services supports the cloud migration from the first workshop to day-to-day operations: inventory, target state, build, cutover and training.

The approach follows the pattern this guide describes: workshop, pilot with one team, then rollout. Existing systems are connected, not replaced in one go. The use case contact centre modernisation gives an overview. For a first conversation about your system, talk to us.