Switching Admissions CRMs Without Losing Leads
The risk in a CRM switch is not old records — it is leads in flight. A six-step playbook for moving admissions systems without dropping anyone.
On this page
Switching admissions CRMs is a live-migration problem, and most teams prepare for the wrong risk. The instinct is to protect the archive — but history tolerates a rough migration. A closed record from last year can arrive a week late and nobody is harmed. What is actually at risk is the leads in flight: the family you spoke to on Tuesday, mid-conversation, still deciding. If they fall through the cutover crack, that is an admission lost and a person unhelped, and clean historical data buys none of it back.
The fix is not caution, it is order: freeze your definitions, map the critical fields, decide what history moves, run a short parallel window, cut over by team, and check the first week's work. Skip a step and the failure shows up two steps later, usually as a person nobody called back.
This playbook assumes the destination is already chosen. If it is not, settle that first — how to choose an admissions CRM covers the evaluation — because switching costs are real and you want to pay them exactly once. Census CRM is the CRM built for behavioral health admissions, and it arrives with the process already inside it, which matters most in the middle of a migration.
Key takeaways on switching admissions CRMs
- The risk in a CRM switch is the leads in flight, not the historical records. A dropped in-flight lead is a lost admission — about $10,000 — while old closed data can arrive late unharmed.
- Freeze your definitions — stages, statuses, sources — before mapping a single field. You cannot map fields you have not defined.
- Source attribution is critical migration data. A lead that arrives without its source breaks every cost-per-admission number downstream.
- Run a short parallel window: new inquiries land in the new system, in-flight conversations finish in the old, and one owner reconciles the two daily.
- Cut over by team, not by big bang, then spend the first week proving every lead lives in exactly one system.
What do you actually risk when you switch admissions CRMs?
The leads in flight — not the archive. A closed record has already done its work. If it lands in the new system a week late, or lands in an archive instead, the harm is zero. An open lead exists in a narrow moment: someone called, a conversation started, and the next touch is supposed to happen today. During a switch, the record may move, but the momentum around it often does not. The follow-up task never fires. The coordinator assumes the new system has it; the new system has a row with no owner. Each side politely assumes the other is handling it, and the family hears nothing.
That silence is the whole cost of a bad migration. Each admission carries about $10,000 of value, and the money is the smaller half of the loss. The larger half is a person who reached out and got nothing back.
Switching is not painless — it consumes coordinator attention for weeks — which is why the evaluation belongs up front: settle what a behavioral health CRM actually costs, switching included, before the move rather than during it.
In what order should you migrate to a new admissions CRM?
Each step exists to protect the one after it.
- Freeze your definitions. Write down your stages, statuses, and sources as they exist today, and stop changing them.
- Map the critical fields. Identity and contact details, stage, owner, next action, consent, referral partner — and source. Treat source attribution as critical, not cosmetic.
- Decide what moves and what gets archived. Recent pipeline and referral history travel; old closed records get archived read-only.
- Run a parallel window. New inquiries land in the new system from day one. In-flight conversations finish in the old system. One named owner reconciles the two daily.
- Cut over by team, not by big bang. Coordinators first, business development next.
- Run the first-week checks. Every lead in exactly one system, calls routing correctly, consent records intact, every referral partner's open conversations accounted for.
The steps that break the most migrations are the first, the fourth, and the plumbing underneath.
Why freeze your definitions before changing admissions CRMs?
Field mapping fails when the two systems mean different things by the same words and nobody wrote down which meaning wins.
Your old CRM says a lead is a "hot prospect." Your new pipeline says Qualification, Approval, Commitment. Is a hot prospect qualified? Approved? That is a decision, not a lookup, and it belongs to the admissions director, not to whoever happens to be running the import. The same goes for statuses ("unresponsive" versus "closed") and for sources, where years of free-typed entries have usually produced a dozen spellings of the same referral partner. Write the canonical list. Freeze it. Every renaming debate after the freeze is a defect, not a discussion.
Then map the fields that let the new system run a conversation: identity, contact details, stage, owner, next action, consent, referral partner, source.
Source sits with the non-negotiables. A migrated lead that loses its source looks whole and is not. It will still admit, but the admission attributes to nothing, and every downstream number that ties marketing spend to admitted patients — cost per admission, partner performance, next month's budget — quietly degrades. You will not notice at cutover. You will notice at the quarterly review, when the data is unrecoverable.
Which data should move to the new CRM, and which should you archive?
Move what the new system needs to run admissions; archive what only serves retention. The instinct to import everything is how a two-week migration becomes a two-month one. The question for each class of data is not "might we want this someday" but "does the new system need it to run admissions."
| Data | Move or archive | Why |
|---|---|---|
| Leads in flight | Move first, verify by hand | These are people mid-conversation |
| Recent closed inquiries | Move | Readmissions and reopens need context |
| Referral partner history | Move | It is the memory of the relationship |
| Texting consent records | Move | Consent belongs to the person, not the software |
| Source attribution | Move, attached to each lead | Cost-per-admission breaks without it |
| Closed records from five years ago | Archive, read-only | They serve retention, not operations |
Archive does not mean delete. Records-retention obligations for treatment data still apply, so keep the export somewhere durable, access-controlled, and retrievable. It means nobody spends migration week cleaning fields on records no coordinator will ever open.
How does the parallel window protect leads mid-conversation?
A hard cutover — everything moves Friday night, everyone logs into the new system Monday — reads as decisive and behaves as reckless, because the leads in flight are mid-conversation on both sides of that weekend. The parallel window is the honest alternative.
It works like this. From day one of the window, every new inquiry — every call, form, and referral — lands in the new system and only there. Conversations already in motion finish where they started, with the coordinators who own them. And one named person reconciles the two systems daily: a list of open leads from each side, checked against the other, until every lead lives in exactly one place. Not in neither. Not in both. That owner is the most important appointment of the migration, and it is a role, not a spare hour.
The window needs a firm end date, because the floor does not pause while you run it — calls keep coming, beds keep filling, and the daily bed census work carries on regardless. An open-ended parallel run means two half-trusted systems and a team quietly picking a favorite.
Cut over by team, not by big bang. Coordinators move first, because they own the leads in flight; business development follows once partner history has landed. Each team gets a named day when the old system goes read-only for them, which turns one enormous risk into several small, recoverable ones.
Then spend the first week checking, deliberately: every lead in exactly one system, every tracking number test-called, consent records present and attached, and every active referral partner's open conversations accounted for by a person, not a report.
What breaks most often during a CRM migration?
Three failures account for most of the pain in a CRM switch, and all three live in the plumbing.
Tracking numbers and call routing. Your call tracking numbers sit between your marketing and your phones, and they are wired into the system you are leaving. Port them early and test-call every one before cutover, because a routing failure does not look like an outage — it looks like a slow week, and by the time anyone questions the quiet you have been unreachable from your own ads for days.
Texting consent records. TCPA consent belongs to the person who gave it, not to the software that recorded it. If those records do not move, the new system cannot lawfully text people who already said yes — and asking a family in crisis to re-consent because you changed vendors is not a plan. Consent is critical-path migration data. (This is not legal advice; your counsel should see the plan.)
Automations. During the parallel window, both systems can believe they own the follow-up. The result is a family getting the same text twice — clumsy at best, a TCPA problem at worst — or nobody following up at all. Inventory every automation before the window opens, decide which system owns each one during it, and switch the other off.
How Census CRM handles the switch
Two things decide how hard a migration is: how much help you get, and how much you have to build before the new system can run a call. On the first, onboarding, training, and support are included with Census CRM licenses — the migration is planned work with the vendor in the room, not a professional-services line item discovered after signature.
The larger difference is what you are migrating into. Census arrives with the admissions process already built in: a 14-step guided talk-track shaped by 60,000+ admissions calls a month and 1,200+ placements a month — 200+ hours to build, more than ten years of refining — and a three-stage pipeline of Qualification, Approval, Commitment. Day one on the new system is a coordinator running a real call inside a working process, not a blank platform being configured while leads wait. The mapping conversation starts from a defined process instead of an empty schema.
The plumbing has homes too. Integrations with CallRail, CTM, Twilio, Google Ads, and Meta Ads keep tracking numbers and source attribution flowing after cutover. Texting is TCPA-safe. Access is role-based across Admin, Director, Coordinator, Clinical, and Read-only, with audit logs, so consent records and referral history land somewhere accountable. If the evaluation is still open, the comparison pages put Census next to the system you are leaving, line by line.
Where should you begin when you switch admissions CRMs?
Begin on paper, not in an export. Write down your stages, your statuses, and your canonical source list as they actually exist today — that one document drives the field map, the migrate-or-archive calls, and the daily reconciliation list. Then name the parallel-window owner, out loud, before anything moves.
If you are still weighing whether the destination justifies the disruption, the complete guide to behavioral health CRM software lays out what the category should do for you in the first place.
And if you want to see what the other side of the cutover looks like — a process already running on day one rather than a platform waiting to be configured — watch a live admissions call run through it.
Switching admissions CRMs FAQs
How long does it take to switch admissions CRMs?
For most centers the move is measured in weeks, and preparation is most of it. Freezing definitions and mapping fields takes longer than moving the data, and the parallel window itself should be short — long enough to catch what is missing, short enough that nobody settles into running two systems. A vendor whose onboarding is included and specified will give you a real timeline on the first call.
Will we lose leads when we switch admissions CRMs?
Only if the switch is treated as a data export instead of a live migration. Historical records tolerate delay; leads in flight do not. Protect them with a parallel window — new inquiries land in the new system while open conversations finish in the old — and one named owner reconciling both systems daily.
Should you migrate all historical data to the new CRM?
No. Move the open pipeline, recent closed inquiries, referral partner history, consent records, and the source attached to each lead; archive old closed records read-only where you can retrieve them if ever needed. Importing years of stale records slows the migration and buries the leads that matter under data nobody will open.
What happens to tracking numbers when you switch admissions CRMs?
They have to be ported and tested before cutover, or calls quietly stop reaching your team. Tracking numbers are often the most fragile piece of a switch because they sit between your marketing and your phones, and a routing mistake looks like a slow week rather than an outage. Port them early and test-call every number before you rely on the new system.
Do texting consent records transfer to a new CRM?
They must. Consent under the TCPA belongs to the person, not the software that recorded it, and if the record of it does not move, your new system cannot lawfully text people who already said yes. Asking families in crisis to re-consent because you changed vendors is not a plan — treat consent records as critical-path migration data.
Can you run two admissions CRMs at the same time during a switch?
Yes, briefly and deliberately. A parallel window — new inquiries in the new system, in-flight conversations finishing in the old — is the safest way to protect leads mid-conversation. It only works with one named owner reconciling the two systems daily and a firm end date; an open-ended parallel run becomes two half-trusted systems.
Keep reading
How to Choose an Admissions CRM
Choosing an admissions CRM is an exercise in sequence: diagnose your funnel, gate your non-negotiables, shortlist three, and run one real inquiry through each.
How Much Does a Behavioral Health CRM Cost?
A behavioral health CRM has two prices: recurring per-license seats and a one-time onboarding fee. What drives each, how to compare two quotes, and how to size the return.
Bed and Census Management for Admissions
The bed question is an admissions question — why availability has to be answered while the family is on the phone, and what a stale bed board really costs.
HIPAA, 42 CFR Part 2, and TCPA: Which Rule Applies to Which Channel
Three different rules govern a single admissions call — HIPAA covers the record, 42 CFR Part 2 covers the fact of contact, and TCPA covers the outreach itself. Which applies where, in one reference.
VOB and Bed Matching for Detox Admissions: Why the Clock Is Different
A detox admission and a residential admission run through the same VOB and bed-matching mechanics, but on a different clock — what actually changes for detox specifically.
VOB and Bed Matching for MAT Admissions: The Program-Capability Check
Medication-assisted treatment adds a question VOB and bed matching don't ask elsewhere: can this specific program actually administer this specific medication.
VOB and Bed Matching for Mental Health Admissions: The Safety-First Read
A mental health admission runs the same VOB and bed-matching mechanics as substance use placement, but psychiatric safety screening and benefit-structure quirks change what actually matters.
VOB and Bed Matching for Outpatient, IOP, and PHP: The Capacity Question
There's no bed to match at outpatient, IOP, or PHP — the equivalent question is group or session capacity, and VOB shifts from per-diem to session-based coverage.
VOB and Bed Matching for Residential Admissions: What Actually Changes
A residential admission still runs VOB and bed matching, but length-of-stay coverage and exclusion checks carry more weight than the speed that dominates detox.
What Is a Bed-Matching Algorithm? A Plain-English Definition
A bed-matching algorithm checks a patient against level of care, insurance, exclusions, and specialty needs before a bed is offered — not just whether one is empty.
What Is a Guided Talk-Track? A Plain-English Definition
A guided talk-track is software, not a script — a step-by-step flow embedded in the CRM that adapts to what the caller says as the call happens.
What Is the ASAM Criteria? The 6 Dimensions Explained
The ASAM Criteria is the standard framework addiction treatment uses to decide level of care, assessed across six dimensions from withdrawal risk to recovery environment.