The TAS migration checklist — moving off a legacy answering service platform without losing a client
Importing client scripts, rebuilding dispatch rules, preserving on-call contact trees, migrating reporting formats, parallel testing high-risk clients, and sequencing go-live so nothing breaks at 2 a.m.
On this page
Why TAS migrations are different
A single-brand contact center migrates one program. An answering service migrates dozens — every client account is its own program with its own script, its own dispatch rules, its own on-call tree, its own reporting format. Miss one detail on one account and that client's 2 a.m. emergency call goes to the wrong on-call doctor or the wrong plumber. That's how answering services lose clients during migrations, and it's why so many TAS operators stay on legacy platforms years past the point of pain.
The fix isn't bravery. It's a migration run as a checklist, account by account, with parallel testing for the accounts that can't tolerate a mistake. This guide is the checklist, in the order the work actually happens. Most migrations run this way complete in weeks, not quarters.
Step 1: Inventory and import client scripts
Start with a full inventory of every active client account: scripts, greetings, intake forms, special instructions, and the informal knowledge living in agent notes and sticky-note lore. Then convert scripts into structured workflows, not flat documents.
- Export whatever the legacy system gives you — even screenshots beat memory
- Rebuild each script in a drag-and-drop workflow builder so branching logic, data capture, and the client's voice live in the flow the agent follows
- Build a small set of client templates first (medical practice, HVAC, property management, legal intake) and clone from the closest template for each account — the first draft of an account takes hours, not days
- Flag every account whose script references data in the client's CRM, so the integration gets built before cutover, not discovered after
Supervisors should be able to make script changes themselves on the new platform. If a client requests a wording change mid-migration, ship it same day in both systems.
Step 2: Rebuild dispatch rules and on-call contact trees
Dispatch logic is the hardest thing to migrate and the most dangerous thing to get wrong. For each account, document and rebuild:
- Dispatch templates per channel — what goes out by SMS, email, phone, pager, or secure messaging, and what each message says
- Time-of-day and day-of-week rules — business hours, after hours, weekends, holidays
- On-call contact trees — who gets reached first, who is second, and what the client's override instructions are
- Escalation chains — what happens when the first contact doesn't acknowledge, and how long the system waits before moving down the tree
Verify on-call trees directly with each client during migration. Legacy systems accumulate stale contacts — the doctor who left the practice two years ago is still third on the tree. Migration is the one moment you have a legitimate reason to ask every client to re-confirm their tree. Use it.
Step 3: Migrate reporting formats
Clients judge an answering service by the reports they receive. If the morning message summary arrives in a different format the Monday after cutover, the phone rings — and not in a good way.
- Collect a sample of every report each client currently receives: format, columns, schedule, delivery method
- Rebuild each as a supervisor-built custom report with scheduled Excel or CSV delivery on the same cadence
- Where the new platform's report is better (and it usually is — dispatch and acknowledgement detail the legacy system never captured), offer it as an addition, not a surprise replacement
Step 4: Train agents on the unified desktop
Legacy TAS work is tab-hopping: the script in one window, the dispatch tool in another, the contact tree in a binder. A unified desktop collapses that into one screen — which is the point, but it means agents need real practice before live traffic.
- Train on real client accounts, not demo data — agents should rehearse the exact scripts they'll run on day one
- Drill the dispatch flow specifically: sending, watching for acknowledgement, and what the escalation chain does on its own
- Start with your strongest agents and let them surface workflow gaps before the full floor moves over
The payoff is concrete: eliminating tab-hopping drives up to 20% reduced AHT, which agents feel within the first week.
Step 5: Parallel test the high-risk clients
Rank accounts by consequence-of-failure. Medical practices, utilities, property emergencies — anyone whose calls trigger urgent dispatch — get parallel testing before cutover:
- Run the account on both platforms simultaneously, with the new platform shadowing: same calls scripted, same dispatches generated, but only the legacy system actually sends
- Compare the dispatch output line by line — right contact, right channel, right template, right time-of-day rule
- Verify acknowledgement tracking and auto-escalation fire as designed, using test contacts on the client's tree
- Only cut the account over when the shadow output matches the legacy output for a full cycle including a weekend and an after-hours window
Low-risk accounts — daytime-only message taking, no urgent dispatch — can cut over on verification testing alone.
Step 6: Sequence the go-live
Never cut the whole book of business over in one night. Sequence it:
- Wave one: a handful of low-risk, friendly accounts. Prove the path end to end with real traffic
- Wave two: the bulk of standard accounts, in batches sized to what your supervisors can monitor closely
- Wave three: the high-risk accounts that completed parallel testing, each with a named supervisor watching the first after-hours cycle
- Keep the legacy system warm as a fallback until every wave has run clean through at least one weekend
After each wave, pull the dispatch audit trail and reconcile it against expectations. Audit-ready evidence of every dispatch isn't just a compliance feature — during a migration it's your proof that nothing fell through.
The short version
Migrate an answering service account by account, not big-bang: inventory and rebuild every client script as a structured workflow, rebuild dispatch templates and time-of-day rules per channel, re-confirm every on-call contact tree with the client, and reproduce every client report before changing anything they see. Train agents on a unified desktop using real accounts, parallel test the high-risk clients until shadow dispatches match legacy output through a full after-hours cycle, then go live in waves with the legacy system warm behind you. Run it as a checklist with professional services support and the whole move takes weeks — with every client's 2 a.m. call landing exactly where it should.
Back to
Industries
Return to the main industries page to see the full product family.
Related guides
Guide
The year-end giving campaign playbook — planning the December surge without burning out your team
Compliant appeal outreach, SMS-first touchpoints, volunteer staffing with one-day onboarding, secure donation processing at volume, and the post-campaign follow-up that turns December givers into January donors.
Guide
The subscriber retention playbook — saves, win-backs, and the calls that keep circulation alive
Renewal reminders, price-increase notices, cancellation save offers, payment-failure outreach, and win-back campaigns — plus the two numbers that tell you whether any of it is working.
Guide
Routing a shared agent pool — serving every client without commingling any of them
Per-client skill routing, hard data boundaries between tenants, blending inbound and outbound work, protecting each client's SLA when agents are shared, and what to put in front of each client's stakeholders.