A contact centre migration checklist for Genesys Cloud

Most migrations are shaped by dates set outside the contact centre. For Genesys customers the vendor sets some of them: support for all PureConnect platforms ended on 31 July 2025, and Genesys has announced end of maintenance and support for Genesys Engage on-premises and subscription products on 31 December 2028, with full-year renewals ending a year earlier. For everyone else, maintenance renewals, carrier contracts, hardware refreshes and licence terms set the boundaries. Gathering those dates in one place first stops two common problems: paying for two platforms for longer than necessary, and being left without support on the old one when a wave slips.

The second job is governance. A migration touches telephony, networks, identity, CRM, workforce management, compliance and front-line operations at once, so it needs one programme with a single plan, a RAID log, change control and a named decision-maker for each area. QVCCS sets this up before discovery begins, because the decisions that follow depend on knowing who can make them.

1. List every legacy maintenance, licence, carrier and hosting contract with its renewal and notice dates.
2. Confirm your Genesys Cloud CX subscription route and who will provide first-line support after go-live.
3. Name an accountable sponsor and a decision-maker for telephony, integrations, compliance and operations.
4. Open a RAID log and a change-control process covering both the old and new platforms.
5. Agree a rule for changes to the legacy platform during the programme: freeze, or mirror in the new design.
6. Mark trading peaks, seasonal campaigns and blackout periods on the plan before any wave is scheduled.

Discovery is where a migration is won or lost. Established platforms hold years of operational knowledge in routing scripts, vectors, handlers or strategies, and much of it is written down nowhere: a holiday rule in an IVR, a database lookup in a routing step, a report a regional manager reads every Monday. We audit the configuration, hold workshops with the people who run the contact centre day to day, and run a site, network and telephony readiness survey alongside. Every finding goes into a migration inventory with an owner, a priority and a target approach, and is carried into the Requirements Traceability Matrix.

With the inventory in place, each journey needs a decision. Parity reproduces existing behaviour faithfully and keeps retraining and risk low. Transformation redesigns a journey to use capabilities such as digital channels, predictive routing, virtual agents or agent assist. Most programmes blend the two. A useful test is whether a journey works well for customers today: if it does, move it faithfully; if it does not, the migration is the natural moment to change it. There is no automatic conversion from any source platform that we would trust on its own; each behaviour is mapped, rebuilt and tested deliberately.

• Export or document every call flow, IVR application, queue, skill, schedule, announcement and prompt.
• Capture routing logic hidden in scripts, data lookups, variables and time-of-day or holiday rules.
• List every report and data feed, who uses it and what decision it supports.
• Record agent states, wrap-up or disposition codes and their downstream uses.
• Survey sites, home workers, networks, browsers and headsets for readiness.
• Give every inventory item an owner, a priority and a target approach in the traceability matrix.
• Record a parity, simplify or redesign decision for each journey, with its reasoning and impact on agents.
• Reconcile definitions of service level, abandonment and handle time so leaders know which figures will move.

Voice connectivity is chosen early because so much depends on it. Genesys Cloud offers three connection options: Genesys Cloud Voice, where Genesys acts as the carrier and existing numbers can be ported in from current carriers; BYOC Cloud, which brings your own carrier's SIP trunks into Genesys Cloud over the internet; and BYOC Premises, which keeps media on Edge devices in your own sites. Our IT Systems, Telecoms & SIP Engineers assess carriers, session border controllers, dial plans and networks before recommending one. During the migration, SIP trunks between the old platform and Genesys Cloud let calls transfer in both directions, so teams can move in waves while customers keep dialling the same numbers.

Numbers move last and most carefully. Each port is scheduled against a cut-over wave and tested straight after it moves, with interim redirects ready if a port is delayed. A complete number register matters more than it sounds: forgotten numbers on printed letters, websites and partner systems are a common cause of calls going astray after cut-over, so we trace every number to its purpose before any port is requested.

1. Build a complete number register: every DDI, non-geographic and toll-free number, its carrier and its purpose.
2. Choose Genesys Cloud Voice, BYOC Cloud or BYOC Premises, and record why.
3. Design coexistence trunks and transfers between the legacy platform and Genesys Cloud.
4. Agree emergency calling arrangements, including caller location for home workers, with your carrier.
5. Confirm network, firewall and quality-of-service changes for the WebRTC phone or chosen handsets.
6. Schedule each porting window against a wave and away from trading peaks.
7. Prepare a test-call list for every number, and an interim redirect for any port that slips.

Integrations are often the longest-running workstream. CTI connectors, CRM screen pops, payment solutions, workforce management feeds and reporting extracts may all rely on interfaces specific to the current platform. Each one needs a target pattern on Genesys Cloud CX, whether a native integration, an AppFoundry partner app, data actions or bespoke development, and an interface contract that the downstream system owner can review before anything is built. User, skill and queue data should be cleansed and loaded repeatably; configuration as code with CX as Code and Archy helps keep test and production consistent.

Historical recordings need an early, explicit decision with your compliance team. Do not assume they can simply be loaded into Genesys Cloud. Usually they stay in the legacy recorder or a searchable archive until their retention period ends, with metadata preserved so quality and dispute teams can still find them. New recordings follow Genesys Cloud recording policies, which decide what is recorded and how long it is kept.

• Catalogue every integration with its owner, direction, data and failure behaviour.
• Write an interface contract for each one, including timeouts and what happens when data is missing.
• Agree single sign-on and user provisioning with your identity team.
• Decide where each historical recording set lives until retention expires, and how people will search it.
• Map recording, retention and deletion rules to Genesys Cloud policies, and have compliance sign them off.
• Check payment handling, data residency and data protection impact assessments against the new design.
• Plan which historical reporting data is kept, exported or archived before the legacy platform goes.

Agent readiness is easy to underestimate. People who have used the same desktop for years need to learn a new workspace, new presence statuses and new ways of transferring and wrapping up, and supervisors need to read queues and agents through new views before the first customer waits on them. We prepare role-based training for agents, supervisors and administrators, often with train-the-trainer sessions so your own team carries the knowledge forward, and we time it close to each wave so it is fresh on go-live day.

Change is about more than training. Team leaders need to know what will look different in reports, why some figures will move, and who to call during the first shifts. Clear, early communication avoids a new platform being blamed for differences that are really changes in measurement.

• Produce a training plan per role, timed to each wave.
• Check every agent's browser, headset, network and login before their wave.
• Brief team leaders on changed measures, presence statuses and wrap-up codes.
• Rehearse supervisor views and common tasks before go-live.
• Publish who to contact during the first shifts and how issues are logged.

Every migrated behaviour should be tested against the one it replaces. Systems integration testing traced to the Requirements Traceability Matrix proves flows, routing and integrations, including failure paths such as timeouts and missing data. User acceptance testing with real agents and supervisors proves the operation works as the business expects. Telephony testing covers carriers, numbers and failover, and performance testing covers busy periods.

Cut-over then happens in waves by site, team, channel or number range, never as a single weekend gamble. Each wave has a rehearsed runbook, entry and exit criteria, test calls straight after the change, a go / no-go decision and a rollback plan that can point numbers and routing back to the old platform. Our remote go-live command centre and virtual floor-walking support people through their first shifts.

1. Trace every system integration test to an inventory item and the behaviour it replaces.
2. Include negative tests: timeouts, missing data, unavailable integrations and closed-hours routing.
3. Run UAT with real agents and supervisors using business scenario scripts.
4. Test carriers, every number and failover routes before and after each port.
5. Rehearse each wave's runbook, including the rollback, before the live date.
6. Agree entry and exit criteria and who makes the go / no-go decision.
7. Keep a defect log with clear severity rules for what blocks a wave.

Hypercare continues after each wave until the operation is stable and the exit criteria are met. Only then should legacy components be switched off, and in a planned order: numbers and routing first confirmed on Genesys Cloud, integrations repointed, recordings and reporting data secured in their agreed homes, and contracts given notice in line with their terms. Support then follows your Genesys Cloud CX consumption and support model. We work inside your provider's service delivery model as the specialist change and escalation layer, or provide SLA-based support, up to 24x7x365 where you contract it with us directly.

• Close hypercare against agreed stability criteria, not a date alone.
• Hand over as-built documentation, runbooks and the support model.
• Confirm no live traffic, integration or report still depends on the legacy platform.
• Secure historical recordings and reporting data in their agreed archives before shutdown.
• Serve notice on legacy maintenance, carrier and licence contracts in line with their terms.
• Baseline performance on Genesys Cloud and list the deferred transformation journeys as a roadmap.