What Actually Happens When a Residential Program Switches Software

Nobody stays on software they hate because they think it's good. They stay because the last conversion went badly, or because they heard about one that did. The fear is almost never the new system. It's the stretch in between, when the charts live in two places and the morning med pass still has to happen on time.

That fear is reasonable. Switching is disruptive. Any vendor who tells you otherwise is either not thinking about your program or hoping you won't ask a second question. The real question isn't whether a conversion will be disruptive. It's whether the disruption is bounded: how long, which staff, what breaks, and what you do if something goes wrong halfway through.

Here's what a migration actually involves, in principle, so you can tell the difference between a vendor who has been through one and a vendor who is guessing.

A conversion is really five conversions at once

People talk about "moving the data" as if it's one job. It isn't. There are five distinct piles, and they have different rules, different risk levels and different deadlines.

• Active charts. The residents in your building right now. Demographics, guardians, placing agency contacts, diagnoses, treatment plans, current goals, precautions. This has to be correct on day one, because staff will be documenting against it that night.
• Medication orders. Active orders, doses, times, PRN parameters, allergies, pharmacy information. This is the highest-risk piece of any conversion and the one most worth slowing down for. A dropped decimal or a missing PRN instruction is not the same class of problem as a mistyped mailing address.
• Authorizations. Payer, units approved, units already used, start and end dates. Programs get burned here because units-used is the field everyone forgets, and it's the field that decides whether you learn about a lapse before you deliver the service or after.
• Staff records. Roles, credentials and expiration dates, training completions, background check dates, permission levels. Half of this usually lives in an HR product or a binder rather than in the clinical system, which means it often has no export at all.
• Historical records. Discharged residents, closed charts, old incident reports, prior billing. Nobody documents against these, but you may have to produce them for a licensing review, a records request or litigation, sometimes years after the resident left.

How long you have to keep that last pile varies by state and by program type, and your licensing body is the authority on it, not your software vendor. Whatever your requirement is, it does not go away because you changed systems.

Historical records are a separate decision, and you should make it on purpose

There are two honest ways to handle history. Import it into the new system, or keep it readable somewhere else. Both are fine. What is not fine is assuming it came along and finding out during an audit that it didn't.

If you import it, understand that old records rarely land in the new system looking the way they looked in the old one. Notes come across as text. Structure gets flattened. That's usually acceptable for something you're producing on request, and unacceptable for something you're documenting against, which is why active and historical charts get treated differently.

If you keep it elsewhere, get it in writing. Ask your current vendor what you can export, in what format, whether they charge for it, and how long you keep access after you stop paying. That is a contract question and the answer is often already in the agreement you signed. Read it before you give notice, not after.

Migrating data and re-keying data are not the same thing

Migrating means a machine reads an export file, maps the old fields to the new ones, and loads them. Re-keying means a person sits down and types it in. Both are legitimate. For a small active census, re-keying can genuinely be faster and more accurate than building a mapping for a handful of residents. The difference is cost, time and who absorbs it.

The problem is that "we'll migrate your data" gets used to describe both. Some vendors mean an import. Some mean your staff will type it in on nights and weekends while the new system is technically live. Those are very different projects with the same sentence attached.

So ask it flatly, category by category: is this an import or is somebody typing it? If somebody is typing it, who, on whose shift, and for how many hours? A vendor who has done this before will answer without flinching, because the answer is usually a mix and there's nothing embarrassing about saying so.

What usually does not move cleanly

Anyone who tells you everything transfers has not done a conversion. The things that reliably get messy:

• Narrative notes. The words come across. The formatting, the templates, the section headers and the tidy structure often don't.
• Scanned documents and attachments. Frequently movable in bulk, frequently arriving as a pile of files that has lost its link to the specific chart section it was filed under.
• Custom fields and forms. Anything your old vendor built specifically for you exists nowhere else, so it has to be rebuilt rather than moved. That's not necessarily bad news, because it's a chance to stop collecting the four fields nobody has looked at since 2019, but it is work. Ask how custom forms and fields get rebuilt in the new system and who builds them.
• Signatures on prior documents. A signed note in the old system is evidence that a specific person signed it there. Imported, it's text that says a name. This is one of the strongest arguments for keeping the old records readable in their original form.
• Audit logs. Access history from the old system almost never transfers. Your new system's log starts the day you go live.
• Billing history with live claim status. Historical claims can usually be brought over as records. Claims still in flight are a different matter, which is why most programs finish their open claims in the old system rather than moving them mid-cycle.

Who actually does the work

Three parties, and the third one is the one that gets underestimated.

Your current vendor has to produce an export. They have no incentive to make this pleasant. Establish what they will give you and in what format before you commit to anything else.

Your new vendor has to map the export and load it, then show you what landed where.

Your staff have to verify it. This is the part no vendor can do for you, because nobody at either company knows that a resident's order changed last Tuesday or that a guardian contact is out of date. Verification is clinical work done by people who know the residents. Plan for it explicitly: someone senior checks med orders against the current MAR, someone checks authorizations against the payer portal, someone spot-checks a sample of charts against what's actually in the paper file.

PHI is moving during all of this, which means the migration itself is covered work. The vendor should be willing to sign a BAA that covers the conversion, not just ongoing use, and should be able to tell you how the data is encrypted in transit and at rest and who on their side can see it.

The overlap period, and why ambiguity is what kills conversions

For a while both systems are live. That's unavoidable. What is avoidable is being vague about which one counts.

Pick a date and a time. After that moment, all new documentation goes in the new system and the old one is read-only. Two weeks of "use whichever one you're comfortable with" produces charts that are half in each, which is the worst possible outcome for an audit and a genuine safety problem for medication administration.

Expect to be slower for a while. Documentation takes longer when people are hunting for buttons. Staff who were fast on the old system will be annoyed. That is normal and it ends. What you can control is when it happens. Don't cut over the week before a licensing visit, during a known audit window, over a holiday, or in a month when you're already short staffed. The most common cause of a bad conversion is not the software. It's picking a date that was already going to be a hard month.

Questions to ask a vendor before you sign anything

These are not gotchas. They're the questions a vendor who has done this expects, and the ones a vendor who hasn't will answer with adjectives.

• Field by field, what will you import, and what will you not import?
• For the things you don't import, who does the data entry: your people or mine?
• What does the conversion cost, and is it included or billed separately? Get this next to the ongoing number so you're comparing the same thing. Ask how it fits with flat per-agency pricing rather than a per-item quote you can't predict.
• How many hours of my staff's time does this take, and which roles?
• What is the rollback plan if we're a week in and it isn't working?
• If I ever leave you, what do I get on the way out, in what format, and how long do I keep access?
• Will you sign a BAA that covers the migration itself?
• Who is my contact during the first month, and is it the same person who sold it to me?

That last one isn't a joke. The handoff from sales to implementation is where most of the disappointment in this industry lives.

What "bounded" actually looks like

A bounded conversion has a date, a written list of what moves, a written list of what doesn't, a named person accountable on both sides, and a way back. An unbounded one has enthusiasm and a start date.

There's a related point worth making, because it's the reason this article exists. A program running eight or ten separate vendors is doing some version of this every time one of those contracts renews or one of those companies gets acquired. The conversion tax gets paid over and over, in smaller installments, forever. Consolidating charting, billing, HR, scheduling and training into one system built for residential programs doesn't make the painful part free. It makes you do it once.

Anything built for a hospital or a clinic will still need bending to fit a residential program, and that bending has its own cost, both during conversion and every day afterward. Worth weighing against the switch itself. The question isn't only "how bad is the move," it's "what am I moving into, and will I be doing this again in three years."

We'd rather tell you up front what won't come across than discover it with you in week two.

If you want to walk through what a switch would actually look like for your program, including the parts we can't do for you, book a demo and bring the list of systems you're currently running. That list is usually the most useful thing in the conversation.