- 01
Consent and suppression state is the artefact most often lost in outbound migrations
- 02
Validate adapter behaviour on abandoned and transferred contacts before cutover
- 03
Port number blocks in waves, each with its own tested rollback
Estate discovery and campaign inventory
Beyond DIDs and queues, inventory every outbound campaign, dialer mode, list source, consent flag and suppression rule. Outbound estates carry more regulatory surface than inbound ones, and consent state is the artefact most often lost in migration.
IVA and inbound flow design
Design the Five9 IVA around observed intents with a hard escalation path per branch. Set a containment target and an escalation-quality target per intent before build, so tuning after go-live has a reference point rather than an opinion.
CRM integration and agent desktop
Salesforce, ServiceNow or Dynamics adapter configuration, screen pop, click-to-dial, disposition write-back and activity logging. Confirm what the adapter writes on abandoned and transferred contacts — those two paths generate most of the reporting discrepancies discovered after cutover.
Telephony cutover and compliance validation
Port number blocks in waves with rollback per wave. For outbound, validate time-of-day windows, frequency caps, consent and suppression enforcement in a controlled pilot before scaling — regulatory defects found in production are expensive in a way inbound defects are not.
Agent enablement and hypercare
Sandbox access, shadow shifts, a one-page disposition map and daily AHT tracking by cohort for the first fortnight. Two weeks of hypercare with a defect board, then a formal run-state handover.
Post-migration AI rollout
After the estate is stable, layer voice AI on the highest-volume bounded intents, agent assist on the queues with the widest AHT variance, and automated QA across all interactions. Sequencing AI after cutover keeps the migration risk and the automation risk separable.
Confirm the fit before committing
Five9 is a strong fit for operations with significant outbound and blended requirements, distributed or remote agent populations, and a preference for a packaged platform over a build-it-yourself cloud. It is a weaker fit where the enterprise needs deep custom orchestration owned in its own codebase, or where the contact center must be assembled from best-of-breed layers. Test the fit against your ten hardest real scenarios — blended pacing rules, complex routing, integration write-backs, compliance constraints — rather than against a feature list, and document the gaps you are accepting before signature.
Outbound compliance is a design input
Outbound and blended operations carry regulatory obligations around consent, calling windows, do-not-call handling, abandonment rates, disclosure and recording. These are configuration and process decisions, not legal footnotes: dialer pacing, list management, suppression handling, timezone logic and agent scripting all encode them. Involve compliance in the design phase, test the controls explicitly, and keep evidence of the configuration in force — this is the workstream most likely to become a finding if it is left to implementation defaults.
Integration and data continuity
Plan CRM integration, screen pop, disposition write-back and reporting continuity as a distinct workstream. Decide early what happens to historical recordings, quality evaluations and reporting history: migrate, archive with retrieval, or retain in the legacy platform under support. Reconcile metric definitions between platforms and publish a bridging report so trend analysis survives the cutover — losing comparability is the quiet way a successful migration gets judged a failure.
Agent experience and training
Distributed agent populations make training and support harder, not easier. Prototype the desktop with real agents, minimise clicks on the highest-volume interaction types, and plan for connectivity and audio quality variance in home environments including headset standards and network guidance. Train supervisors on remote floor management tooling separately, and staff a hypercare bridge for the first two weeks where issues can be raised and resolved same-day.
Migration sequence and AI layering
Move queue by queue with parallel running, starting with a low-risk inbound queue to validate telephony, integration and reporting, then blended and outbound campaigns once pacing and compliance controls are proven. Once stable, layer AI capability — self-service on top intents, agent assist, automated quality — using the platform's APIs and events, keeping intent and orchestration behind interfaces you control so model choices remain independent of the platform decision.
Discovery for blended and outbound operations
Blended operations need discovery that classic inbound migrations skip: campaign structures and pacing rules, list sources and refresh cadence, suppression and consent data flows, agent scripting and disclosure requirements, callback handling, and the reporting managers use to run campaigns daily. Document these with the people who operate them rather than from configuration exports — the operating practice around a dialer is usually richer, and more load-bearing, than its configuration suggests.
Integration patterns and CRM alignment
Decide whether the CRM or the platform is the agent's primary workspace, then design integration accordingly: screen pop with the correct record, click-to-dial from records and lists, activity and disposition write-back, and consistent identity between systems. Test failure behaviour explicitly — what the agent sees when the CRM is slow or unavailable is a design decision, and an unhandled one produces workarounds that corrupt data quality permanently.
Quality, workforce management and reporting setup
Configure quality forms around the behaviours you intend to coach rather than porting the legacy form unchanged, validate forecasting against historical demand before relying on it, and reconcile every core metric definition with the legacy platform before cutover. Build the standard operational reporting pack in advance and have supervisors confirm it answers their daily questions — reporting gaps discovered after go-live consume disproportionate attention during the period when attention is scarcest.
Training and supporting a distributed workforce
Remote and distributed agents need more structured enablement: recorded and live training on the real desktop, written quick-reference material, a clear support path for connectivity and audio issues, headset and network standards, and supervisors trained separately on remote floor management. Plan a staggered training schedule close to each queue's cutover date so knowledge is fresh, and keep a hypercare channel staffed with people who can resolve rather than log.
Post-migration optimisation and AI layering
Once queues are stable, optimise: refine pacing against contact and abandonment data, tune routing with real traffic, retire transitional workarounds, and review licence and capacity allocation. Then layer capability in order of risk — automated quality first, agent assist next, self-service on the highest-volume intents last — keeping intent classification and orchestration behind interfaces you control so platform and model decisions remain independent.
Migration timeline and readiness gates
Weeks one to four, discovery: document inbound routing, campaign structures and pacing rules, list sources and refresh cadence, suppression and consent flows, agent scripting and disclosure requirements, callback handling, CRM integration points and the reports managers use daily. Involve compliance now rather than at testing. Weeks five to ten, build and configure: routing and campaigns, CRM integration with screen pop, click-to-dial and disposition write-back including behaviour when the CRM is slow, quality forms rebuilt around coachable behaviours, forecasting validated against historical demand, and the operational reporting pack constructed and confirmed with supervisors. Weeks eleven to fourteen, test: routing and campaign scenarios, dialer pacing and abandonment controls, suppression and calling-window logic exercised against edge cases, telephony and carrier paths, integration failure modes, reporting reconciliation with legacy definitions, and load at peak concurrency. Weeks fifteen to eighteen, pilot: migrate one low-risk inbound queue, port its numbers, train its agents on the real desktop, and run a full reporting cycle against baseline. Weeks nineteen onward, progressive migration: remaining inbound queues in batches, then blended and outbound campaigns once pacing and compliance controls are proven in production, each batch reversible within a shift and supported by staffed hypercare. Retire legacy only after a full seasonal cycle. Then optimise — pacing against real contact and abandonment data, routing tuning, workaround retirement, licence and capacity review — before layering AI capability in risk order: automated quality first, agent assist next, self-service on the highest-volume intents last, with intent classification and orchestration kept behind interfaces you control.
Compliance controls that must survive the migration
Outbound operations carry obligations that do not transfer automatically with configuration. Re-verify each one in the new platform before live traffic: calling window enforcement by recipient time zone including mobile numbers, suppression list ingestion and refresh cadence with a tested failure mode when the feed is late, consent state sourced from the system of record rather than duplicated in the dialer, abandonment rate controls and the accompanying message requirements, caller identification and branded calling registrations, agent disclosure scripting at the point in the call where it is required, and recording consent handling per jurisdiction. Document who owns each control, how it is monitored in production and what evidence is retained. Involve compliance during build rather than at testing, and rehearse one audit request end to end before cutover. A migration that improves agent experience and quietly weakens a calling-window control has created a liability that dwarfs the efficiency it delivered.
- Consent and suppression state is the artefact most often lost in outbound migrations
- Validate adapter behaviour on abandoned and transferred contacts before cutover
- Port number blocks in waves, each with its own tested rollback
- Roll out AI after the estate is stable so migration and automation risk stay separable
- Test platform fit against your ten hardest real scenarios and document accepted gaps before signature.
- Treat outbound compliance as design input: pacing, suppression, windows, disclosure and evidence of configuration.
- Reconcile metric definitions and publish a bridging report so trend comparability survives cutover.
- Validate a low-risk inbound queue first, then blended and outbound once pacing and compliance controls are proven.
Questions leaders ask us
- How long does a Five9 migration take?
- Inbound-only estates with light integration typically run 6–10 weeks. Adding outbound campaigns, dialer compliance validation and CRM write-back usually extends the program to 3–5 months.
- What is different about migrating outbound campaigns?
- Consent flags, suppression lists, frequency caps and time-of-day rules must migrate with the campaign and be validated in a controlled pilot. Inbound defects cost quality; outbound defects cost regulatory exposure.
- Should AI go live with the migration or after?
- After. Keeping cutover and automation in separate waves means a containment or assist problem is never confused with a routing or telephony problem during hypercare.
- When is Five9 the right platform choice?
- For operations with substantial outbound or blended volume, distributed agents, and a preference for a packaged platform over assembling and owning orchestration in-house.
- What compliance controls matter most in an outbound migration?
- Consent and suppression handling, calling window and timezone logic, dialer pacing and abandonment limits, disclosure scripting and recording consent — designed with compliance and evidenced in configuration.
- How do we preserve reporting history through migration?
- Decide per data class whether to migrate, archive with retrieval or retain in the legacy platform, reconcile metric definitions, and publish a bridging report before the first queue moves.
- Can we add AI capability after migrating?
- Yes. Layer self-service, agent assist and automated quality through the platform's APIs and events, keeping intent classification and orchestration behind your own interfaces so model choice stays independent.