An anonymized account. Client and identifying details are withheld; the pattern is real and repeatable.
A large telecom operator was migrating its contact centers to Genesys Cloud in waves, region by region. The platform migration itself was well planned. The reporting was the part nobody owned: legacy feeds, supervisor habits and WFM integrations were all tied to the previous platform, and they would go dark the moment each region cut over.
For a business that manages service level at the interval — with regulators and wholesale partners watching — a multi-week reporting blackout per region was not acceptable.
The risk: a blind period at the worst possible time
Migrations are exactly when you most need to see the floor. Volumes are volatile, agents are on a new tool, and every wobble in a KPI triggers a question from someone senior. Yet the standard migration plan often leaves reporting to be "rebuilt afterwards" — creating a window where the operation flies blind.
The specific exposures were:
- Legacy KPI feeds to command centers stopping at cutover.
- WFM intraday integration breaking, so planners lost actuals mid-wave.
- Supervisor wallboards changing shape, eroding trust in the numbers.
- Inconsistent definitions between the old and new platforms, making side-by-side comparison impossible.
The approach: stand the new pipeline up before the wave, not after
Rather than treating reporting as post-migration cleanup, the integration ran in parallel with the migration waves:
- Inventory. Catalogue the KPIs and feeds that would be lost at each cutover.
- Map. Map Genesys Cloud topics to replacement reactive-processing modules, computing each KPI once.
- Deploy in parallel. Stand up the event-driven pipeline alongside the waves — not after them — in the client's own cloud.
- Connect. Power BI for interim visibility, HTTP feeds for WFM parity, scoped APIs for command centers.
- Reconcile. Run old and new numbers side by side until the business signed off the definitions.
This is the post-migration visibility use case in practice, applied to a telco contact-center estate with complex routing and multi-region operations.
What changed
| Before | After |
|---|---|
| Reporting rebuilt after each cutover | Pipeline live before each wave |
| Blind period per region | Continuous interval-level visibility |
| Old/new numbers not comparable | Side-by-side reconciliation until sign-off |
| Feeds tied to legacy platform | Definitions owned by the client, in their cloud |
The headline outcome wasn't a flashy dashboard — it was the absence of a blackout. Each region cut over with command centers and WFM still sighted, and with a documented definition for every disputed number.
The transferable lessons
- Treat reporting as a migration workstream, not an afterthought.
- Compute KPIs once so old and new can be reconciled against a single definition.
- Run in parallel. The cost of standing the pipeline up early is trivial next to the cost of flying blind during a wave.
- Own the definitions and the data. When a regulator or partner asks, "is this number right?", you want a written definition and stored history — not an argument.
FAQ
Does this delay the migration? No — it runs in parallel. The integration consumes Genesys Cloud events as each region comes online, so it tracks the migration rather than gating it.
What if old and new definitions differ? That's expected. Running both side by side until the business signs off is the point; it turns a definitional dispute into a documented decision.
Is this only for telco? No. The same parallel-pipeline pattern applies to any multi-site operation migrating to Genesys Cloud — BPOs, financial services and utilities especially.
Planning a Genesys Cloud migration and worried about a reporting blackout? Request a migration KPI assessment and we'll inventory what you stand to lose before the first wave.