What Actually Goes Wrong During Software Migrations

Most software migrations don't fail because the software was wrong. They fail because the workflow assumptions weren't.

The conversation is usually about the new system. The work that determines whether the migration succeeds is almost always about the old one.

The myth of "we'll just turn it on"

Vendors rarely lie about this — but the framing tends to flatter both sides. Sales conversations assume that:

• the data in the old system is consistent enough to map cleanly,
• the workflow lives in the system rather than in people's habits,
• staff will adapt to the new tool's way of doing things.

In a practice that has run on the old system for years, none of these are usually quite true.

What actually goes wrong

Data shape mismatches. Two systems that store “the same thing” rarely store it the same way. Patient name fields concatenate vs. split. Appointment types mean different things. Free-text notes carry meaning the new schema can't represent. The data audit is almost always more work than the migration plan estimates.

Undocumented workflow logic. “Why do we mark this here?” “Because the recall report doesn't pick it up otherwise.” The new system doesn't have that report. Or it does, but it works differently. The workflow logic that lived in habit suddenly needs to be made explicit — and surfaced before, not after, go-live.

Integration drift. The old system talks to imaging, accounting, comms, and a half-built spreadsheet someone inherited. Each of those integrations needs evaluating. Some are documented. Many are not. Some can't be replicated cleanly in the new stack.

Shadow processes. Every practice has a few “we always do it this way” steps that aren't in any manual. They surface during cutover, usually because someone says “wait, where do I…?”

Reporting. This is where most practices feel the migration weeks later. Reports that worked invisibly are suddenly missing or different. Owners can't see what they used to see. Confidence in the new system erodes from the reporting layer up.

What separates good migrations from bad ones

The successful migrations I've worked on share three things:

1. A workflow audit before vendor selection. Map what the practice actually does, including the workarounds, before deciding which system to move to. The audit often disqualifies vendors that looked fine on paper.

2. Parallel running, not big-bang cutover. For at least a billing cycle, both systems run side by side. It's painful and it works. It surfaces gaps early, while the old system is still there as a fallback.

3. An owner who can speak both old and new. Someone who understands what the practice has been doing and can translate that to the new system's way of working. This is often a manager rather than a vendor or implementer.

The honest framing

A software migration is not a software project. It's a workflow project that involves software. Treat it that way and the rest tends to follow.