Written for operations leaders leaving Avaya, Genesys, NICE or a smaller dialler: what actually transfers, what should stay behind, and how to cut over without a dark fortnight.
What actually transfers when you migrate to Five9 from another platform?
Three things transfer: numbers through carrier porting, data through export, and people through training. Configuration does not port and mostly should not, since rebuilding beats cloning legacy IVR flows and stale dispositions. Submit porting LOAs in week one because carrier timescales set the critical path, choose a cutover pattern matched to your risk, and keep legacy reporting read-only because metric definitions drift between platforms.
Numbers, data and people move. Everything else is a decision.
Strip a migration to its parts and only three things genuinely transfer. Your numbers move through carrier porting. Your data moves through export: contact lists, suppression files, recordings, historical reports. Your people move through training. That is the whole list.
Everything else, the IVR flows, the campaign definitions, the disposition sets, the routing logic, the report templates, is configuration. Configuration does not port. It gets rebuilt, and that is an opportunity dressed up as a chore, because the rebuild is your one chance to shed fifteen years of accumulated workarounds without an argument about ownership.
The instinct that ruins migrations is the instinct to recreate the old platform exactly, then call the project done when Five9 behaves like the thing you just paid to leave. We see it in the estates we audit: a cloud dialler configured to imitate a 2009 PBX, faithfully, right down to the queue nobody has staffed since the pandemic. Lift-and-shift feels safe because it defers every decision. Rebuild is faster in practice, because most of those decisions turn out to be deletions.
The rest of this guide works through each transfer channel in order of how badly it hurts when you start it late.
Submit LOAs in week one. Nothing else in the project can compress carrier timescales.
One workstream runs on somebody else's clock. Configuration can be accelerated with more hands; a port cannot. The losing carrier processes it at the pace regulation and their internal queues allow, which is why the Letter of Authorisation (LOA) belongs in week one of the project, not week six when the build looks finished.
The LOA itself is a short document authorising the new carrier to take your numbers (Bandwidth has a plain-English explainer), and in our experience it fails for boring reasons: the company name, service address or billing telephone number on the form does not exactly match the losing carrier's records. Pull a copy of your latest bill, request a customer service record if you can, and make the forms match to the character. In our experience a first-time-right LOA is the cheapest week you will ever save.
On timescales, the honest answer is a range. In the UK, keeping your numbers when you switch is a regulated right under Ofcom's general conditions, but the working reality for business numbers is measured in weeks: one UK provider, Gradwell, publishes 5 to 8 working days for a single line, rising to 18 to 23 working days for complex ports, with most requests completing inside 10 to 20 working days. In the US the FCC requires simple ports to complete in one business day and bars the losing provider from refusing a port over an outstanding balance, but a contact centre estate with DID ranges across multiple carriers is rarely a simple port.
Plan interim routing so the port date stops being scary. Outbound can go live on new Five9 numbers immediately, before any port completes. Inbound stays on the legacy numbers with a divert to Five9 until each range confirms, which also means the legacy carrier contract stays alive until the last number lands. Cancelling the old service early is how estates go dark for a fortnight, and we have been called in to more than one of those.
We build Five9 estates for a living and run outbound floors on them daily, so the quote you get reflects how the platform behaves in production, not a services rate card. Tell us what you are moving from and we will give you a straight answer on scope, sequencing and cost.
Cloning the legacy estate preserves your technical debt at cloud prices.
Three legacy assets get dragged into new platforms out of habit, and all three should stay where they are. Our Five9 implementation guide makes the longer case that rebuild beats lift-and-shift; here is what that means in practice.
The IVR first. A phone menu that has grown for a decade is an archaeology site: options built for a product you discontinued, branches added to appease a director who left, a voicemail box that empties nowhere. Cloning it into Five9 reproduces every dead end at cloud prices. Rebuild from evidence instead: pull six months of keypress and abandonment data, keep the routes callers actually use, and give everything else the retirement it has earned. Nobody has ever missed option seven.
Dispositions second. Most legacy diallers carry a code list in the low hundreds, of which agents use a dozen, inconsistently, because that is what a decade of 'just add one for this campaign' produces. A migration is the one moment you can reset to a short set where every code drives an action: a callback, a suppression, a reporting line. If a disposition changes nothing downstream, it is not data, it is decoration.
Dead campaigns and orphan skills third. Export their history for the archive, then let them go. Migrating a campaign that has not dialled since 2023 costs configuration time now and reporting confusion forever.
The platform you leave shapes the work more than the platform you join.
Five9's own migration material names Avaya, Genesys and Cisco as its common source platforms, and that matches what we see, with a long tail of smaller diallers behind them. The technical move is broadly similar in each case. The work around it is not.
This is the biggest operating-model shift, and the hardware is the least of it. An on-prem estate comes with an ecosystem: a PBX admin team, change freezes, maintenance contracts, an upgrade cycle that structures the IT calendar. Move to Five9 and that ecosystem dissolves. Telephony engineers become platform administrators or become redundant, change control moves from quarterly releases to same-day configuration, and the finance model swaps hardware capex for per-seat licences. Plan the people side as deliberately as the technical side; some of the sharpest Five9 admins we work with are former Avaya engineers who were given a retraining path instead of a leaving date.
Technically the gentlest move, which is exactly why teams under-scope it. The trap is concept mapping: the platforms describe similar machinery with different words and different maths. Queues, skills, wrap-up codes and campaign states do not translate one to one, and reports that share a name rarely share a formula. Build a translation table before touching configuration, and treat any feature you assumed was like-for-like as unverified until someone has demonstrated it on your own call flows.
Coming off ViciDial or one of the volume outbound platforms, the telephony migration is usually the easy fortnight. The real work is hygiene. These estates tend to arrive with years of recycled leads, suppression handling held together by habit, and disposition sprawl nobody can decode. Do the cleanse before the import, not after; our outbound list strategy guide covers the rebuild. Importing a dirty list into a clean platform gives you a clean platform with a dirty list.
A parallel run needs an exit test, not an end date you keep moving.
Every migration ends with a version of the same decision: how much of the operation moves at once, and how long both platforms stay alive. Running the two in parallel is the safety net, and it is a paid-for safety net, since every parallel week is a week of double licences. The discipline that keeps it affordable is an exit test agreed in writing: the specific numbers (calls handled, port confirmations, report reconciliation) that switch the legacy platform off. Parallel runs without an exit test do not end. They fade, expensively.
Three cutover patterns cover almost every estate we have moved.
| Pattern | Fits when | The catch |
|---|---|---|
| Pilot group. One team or queue lives on Five9 for a week or two while the rest stay put. | Mixed inbound estates, integration-heavy builds, boards that need to see it work before committing. | Pick a pilot team senior enough that their verdict carries. A pilot of new starters proves nothing. |
| Campaign-by-campaign. Each outbound campaign moves as a unit with its lists, CLIs and dispositions. | Outbound and blended floors, BPOs and multi-brand estates where campaigns are natural seams. | Reporting spans two platforms mid-move, so agree how the seam weeks get counted before they start. |
| Hard cutover. Everything moves on one date. | Smaller centres, tight budgets, seasonal businesses with a genuine quiet window. | Cheapest and least forgiving. It needs a written rollback plan and a named go/no-go owner before the day. |
The deciding variable is rarely technical. It is how bad a bad day is: a claims line where an outage means regulatory letters justifies a long pilot, while a twelve-seat sales floor in its quiet month can take the hard cut and bank the licence saving.
The platforms count differently. Re-base the definitions before anyone compares.
Two reporting problems arrive with every migration, and the second is sneakier than the first.
The first is access. The day your legacy licence lapses, its reporting dies with it. Export everything with a retention need (historical reports, call recordings, contact history) before the final invoice, and where the contract allows it, negotiate read-only access to the old reporting environment for a year. Land the exports in a warehouse beside your new Five9 data rather than merging the two, because merging is where the second problem bites.
The second is definition drift. Metrics that share a name do not share maths across platforms. Abandon rate is the canonical example: measured properly it is abandoned calls divided by calls answered by a live person, and the regulators on both sides of the Atlantic agree on that denominator. The US telemarketing safe harbour caps abandonment at 3 percent of calls answered by a person, measured per campaign over 30-day periods (16 CFR 310.4); Ofcom's persistent misuse policy defines an abandoned call as a connection made with a live individual and then terminated, with its published rate measured against live calls per campaign over a 24 hour period. The windows differ; the denominator does not. Plenty of legacy diallers nonetheless report abandons as a percentage of dials, which flatters the number enormously. Move to Five9, measure it properly, and month one looks like a collapse that never happened.
Handle time has the same disease (wrap included or excluded), and so does 'answered' (human answer, or any connect including machines). Before anyone screenshots a month-one comparison for the board, publish a translation sheet: each headline metric, the legacy formula, the Five9 formula, and which one you now govern by. The regulatory definitions move as well; both regimes have been revised more than once and enforcement practice shifts, so check the current texts rather than a migration-era crib sheet, and put anything with real stakes in front of qualified counsel rather than a blog, ours included. We keep the operational detail current in our Ofcom dialler rules and US abandonment rules guides.
Agents adapt in days. Supervisors carry the real curve.
Vendors sell training as a formality and change consultants sell it as a crisis, and neither is telling you the whole of it. On the floors we run, agents come up to speed on core call handling in days. The browser softphone, screen pops and disposition entry are simpler than most legacy desktops, and anyone comfortable with a modern web app finds nothing frightening in the agent workspace. Expect week one to be slower anyway: handle times stretch while muscle memory rebuilds, so set targets and occupancy plans that admit it, and do not schedule go-live into your peak trading fortnight, however tidy it looks on the project plan.
Supervisors are the actual curve. Real-time dashboards, campaign management, list loading and report building are where Five9 differs most from whatever you left, and supervisors field every question on the floor in week one. Train them first, train them deepest, and make at least one of them a genuine platform expert rather than spreading a thin layer of familiarity across all of them.
Admins from an on-prem world face the biggest identity change: the job stops being keeping boxes alive and becomes managing configuration, campaigns and integrations. It is a better job. It is also a different one, and pretending otherwise is how migrations lose their most experienced people.
On format, scenario-based sessions on your own call types beat generic platform tours every time. An hour handling your real awkward calls in a sandbox is worth a day of feature walkthroughs.
Six failures, all avoidable, all seen in the last year.
Every one of these comes from a real estate we have either migrated or been called in to rescue.
None of these is a platform problem. All six are sequencing problems, which is the good news, because sequencing is cheap to fix in week one and expensive to fix in week ten.
The build follows the implementation bands. Porting adds a floor you cannot compress.
Migration timelines get quoted with false confidence in both directions, so here is the honest structure. The configuration and integration work follows the same three bands we published in our implementation guide, where the band you land in is set by scope, not luck. A migration adds two things on top: the porting lead time, which is a floor no amount of effort compresses, and the parallel-run period you choose, which is a cost you control with a decent exit test.
Sequence it so the fixed parts start first. LOAs and data exports go in during week one, build and training run through the middle, and the cutover pattern gets chosen early enough that the training schedule matches it. Run that order and the port date and the build converge instead of queueing behind each other.
If you want a number for your own estate rather than a band, that is a scoping conversation, and a short one: what you are on today, what integrates, how many seats, how many numbers. We will give you a straight answer, including the annoying parts, like whether your CRM integration is the long pole.
The build follows the same bands as any Five9 implementation: scope sets the band, not luck, and our implementation guide publishes the ranges we actually see. Migration adds one fixed constraint on top, which is number porting. UK business ports routinely take two to four working weeks on published provider lead times, and complex multi-range ports take longer, so the port date, not the configuration work, usually sets the earliest realistic cutover. Start the paperwork in week one.
Yes. Number portability is a regulated right in both the UK and the US, and the losing provider cannot refuse to release numbers because you are leaving. The transfer runs on a Letter of Authorisation that must exactly match the losing carrier's records; mismatched names, addresses or billing numbers are the most common cause of rejection and delay. Submit the paperwork in the first week of the project and keep the old carrier contract alive until every range confirms.
No, and no migration tool changes that. Five9 reporting starts at go-live. Export historical reports, call recordings and contact history before your legacy licence lapses, negotiate read-only access to the old reporting environment for a year where the contract allows, and land the exports in a warehouse beside the new data. Do not try to merge the two histories into one series, because the platforms calculate core metrics differently.
Almost never wholesale. A decade-old IVR is accumulated technical debt: menus for discontinued products, branches nobody remembers building, dead ends callers have learned to avoid. Rebuild from evidence instead. Pull six months of keypress and abandonment data, keep the routes callers genuinely use, and retire the rest. A faithful clone pays implementation rates to preserve your worst legacy decisions on a new platform.
Avaya and other on-prem estates involve the biggest change, not because the technical move is harder but because the operating model changes: no PBX to maintain, admin roles redefined, change processes rebuilt. Genesys and NICE migrations are technically straightforward but need careful concept mapping, since queues, skills and wrap codes do not translate one to one. Smaller diallers mostly surface data problems: recycled lists, missing suppressions and disposition sprawl that should not be imported as-is.
Core call handling comes quickly, typically days rather than weeks in our experience, because the browser-based agent desktop is simpler than most legacy screens. The heavier curve belongs to supervisors: dashboards, campaign management and report building differ most from legacy platforms, and supervisors answer every floor question in week one, so train them first and deepest. Expect a productivity dip in the first week and set targets that admit it.
Usually, but a bounded one. Every parallel week costs double licences, so agree an exit test in writing before you start: the specific reconciliation and volume numbers that switch the legacy platform off. Pilot groups suit inbound and integration-heavy estates, campaign-by-campaign moves suit outbound floors, and a hard cutover suits smaller centres with a genuine quiet window, provided a rollback plan exists on paper before the day.
Usually definition drift rather than performance. Platforms attach different maths to the same metric names: abandon rate measured properly is abandoned calls divided by calls answered by a live person, but some legacy diallers report it against total dials, which flatters it. Handle time may include or exclude wrap. Publish a translation sheet mapping each legacy formula to its Five9 equivalent before comparing month one to history, and treat the first thirty days as tuning, not judgement.
Score your operation in the free 17-question Five9 Health Check. Five minutes, no sign-up hoops, instant results.
A migration done properly is mostly sequencing: LOAs early, rebuild rather than clone, a cutover pattern that matches your risk. We have run this playbook from Avaya, Genesys, NICE and half a dozen smaller diallers, with a named pod on your project rather than a ticket queue. Talk to us before you sign the licence order.
Talk to us