A typical Genesys Cloud implementation timeline

Genesys publishes an average for the platform as a whole: its home page states 54 days to customer go-live on average, as of its third quarter of fiscal year 2026. That figure is useful evidence that Genesys Cloud CX itself can be provisioned and configured quickly. It is an average across every kind of customer, though, from a single team on one channel to a multi-site enterprise with dozens of integrations, so it tells you little about your own programme.

What decides your date is the critical path: the longest chain of dependent tasks between signature and stable service. On most implementations that chain runs through things QVCCS does not fully control and Genesys does not configure. Carriers have to accept porting requests. Identity and network teams have to approve single sign-on and firewall changes. Back-end system owners have to build or open the interfaces that integrations call. Business users have to be released from the floor for workshops, acceptance testing and training. Configuration effort matters, but it is rarely the constraint.

That is why we do not quote a duration before we understand the estate. Discovery gives us the facts, and at the end of it we agree a dated, phased plan with you that shows each dependency, who owns it and what it unlocks. The plan is then governed through the RAID log, change control and weekly status reporting, so any slip is visible early and its knock-on effect is understood.

Our lifecycle has seven stages, each closed by a quality gate. The stages overlap where dependencies allow: carrier and porting work, for example, begins during discovery, and training material is written while the build is under way. The gates do not overlap. Design authority must approve a design before it is built, and a go / no-go decision is never taken without test evidence. The table summarises each stage; the sections that follow explain what tends to lengthen or shorten it.

Discovery is where the timeline is really set. Alongside workshops with operations, IT and compliance, we audit the current platform or Genesys Cloud CX org, analyse contact volumes and handle times, and survey sites, networks, home-worker connectivity and telephony. The readiness assessment lists every dependency we can see, with an owner and a lead time where one is known. The discovery report and that readiness assessment are what make an honest, dated plan possible; skipping or compressing discovery usually means the dependencies surface later, when they cost more time.

Define turns findings into a baselined set of requirements. Facilitated workshops produce a Business Requirements Document, a Functional and Non-Functional Requirements Specification and a Requirements Traceability Matrix. MoSCoW prioritisation matters here for timeline reasons: it lets you decide what must be in the first release and what can follow, which is the most effective way to protect a date without cutting quality.

Design produces the High-Level Design, the Low-Level Design build book and an interface control document for each integration. Two design decisions have a large effect on the plan. The first is the telephony connection option: Genesys documents Genesys Cloud Voice, BYOC Cloud with your own carrier, and BYOC Premises, and each brings different ordering, contract and testing work. The second is the integration pattern for each back-end system, because a native integration, a data action and bespoke development have very different build and test paths.

Build is usually the most predictable stage, because it follows an approved build book. Our developers configure the organisation, divisions, roles, queues, routing and Architect flows to the LLD, with four-eyes peer review and a configuration audit before the build complete gate. Where licensing allows separate development, test and production orgs, holding configuration as code with CX as Code and Archy makes promotion between them repeatable, which shortens rework when a test finds a defect.

Prove is where unplanned time most often appears, and it is almost always caused by dependencies rather than by the platform. Systems integration testing needs test instances of your CRM and other back-end systems, with representative data. Telephony testing needs carrier routes live. User acceptance testing needs your agents and supervisors released from the floor. Genesys's own readiness guidance covers user acceptance testing, load testing through its Automated Testing Support programme, and network readiness, so performance tests are planned and requested in advance rather than run on impulse.

Transition brings its own fixed points. Genesys asks the implementation's project manager to submit a Go Live readiness form, reviewed by Genesys Product Support, before an org goes live in production, so that date sits in our plan. Porting windows, training sessions and the go-live date itself are scheduled against your trading calendar and any change freezes. On the day we run a remote go-live command centre with virtual floor-walking, on site only where mutually agreed, followed by hypercare until operational acceptance.

Most of the factors below are known, or knowable, by the end of discovery. Each one is entered in the RAID log with an owner and placed on the plan, and the ones with external lead times are started as early as the design allows. Where a factor cannot be resolved in time, the usual answer is to phase the scope rather than squeeze the testing.

• Telephony and number porting: carrier orders, SIP trunk provisioning and port requests run to carriers' and Genesys's processes. For Genesys Cloud Voice in EMEA, Genesys states porting depends on carrier agreements and the Letter of Authorization must match carrier records exactly.
• Integrations: each back-end system needs its owner's time to agree an interface contract, open access and provide a test environment.
• Data and recordings: user, skill and queue data needs gathering and cleansing, and historical recordings need an agreed retention, migration or archive decision.
• Security reviews: single sign-on, firewall and network changes, data-protection impact assessments and PCI DSS scope all need approval from your security teams.
• Licensing and contracts: subscription start dates, licence types, carrier contracts and the notice period on the old platform's maintenance all constrain dates.
• Training: role-based sessions for agents, team leaders and administrators must fit around rotas and service levels.
• Change freezes: peak trading periods, financial year-end and wider IT freezes close windows for porting and go-live.
• Waves for multi-site estates: each site, team or channel that moves separately adds a cut-over, test calls and hypercare period, but lowers risk.
• Availability of your own people: subject matter experts, approvers, testers and super users are on the critical path of nearly every stage.

Genesys Cloud CX changes continuously. Genesys publishes release notes weekly and deploys features to its regions on a staggered schedule, so a plan that stops at go-live leaves no room for what arrives next. Our Run & evolve stage includes release readiness reviews, health checks and optimisation reviews against your KPIs, and a continuous-improvement roadmap for the capabilities deliberately left out of the first release.

Support and maintenance are aligned to your Genesys Cloud CX consumption and support model. Where Genesys, a systems integrator or a managed service provider delivers incident management and first-line support, we work inside your provider's service delivery model as the specialist change and escalation layer. Where you contract support with us directly, we provide SLA-based support, up to 24x7x365, with monitoring, alarms and automated engineer callout. Either way, the handover pack, as-built documentation and runbooks from Transition are what make that support effective from the first day.