Every software implementation reaches a moment when the old system has to stop being the system of record and the new one has to start. How a practice manages that moment is the go-live strategy, and it shapes everything from staffing levels in the first week to how long the legacy contract needs to stay active. There are three broad approaches, and none is right for every situation. This guide explains each one, lays out the trade-offs in plain terms, and offers a way to decide which fits a particular clinic and a particular kind of software.
The three go-live strategies
A hard cutover, sometimes called big-bang, switches every user and every workflow from the old system to the new one at a single moment. A parallel run keeps both systems live for a period, with staff entering data into both, so results can be compared before the old system is retired. A phased rollout moves one location, department, or function at a time, so part of the practice is on the new system while the rest is still on the old one.
The right choice depends on what the software does, how many people use it, how tolerant the practice is of a disrupted week, and how much the two systems need to agree with each other during the transition. A scheduling system and a billing system, for example, have very different failure modes when the transition goes badly.
Hard cutover: fast, clean, unforgiving
A hard cutover has the great virtue of simplicity. There is one go-live date, one set of training deadlines, and one system to support afterward. Staff are never asked to enter the same information twice, and there is no confusion about which system is authoritative. For a small clinic replacing an EHR or a practice management system, a hard cutover over a weekend is the most common approach and often the right one.
The cost is that there is no safety net. If the data migration is incomplete, if an interface is not working, or if a workflow was never configured, the practice discovers it on Monday morning with patients in the lobby. A hard cutover therefore demands rigorous preparation: a completed user acceptance test, a verified data migration on a recent snapshot, a rehearsed downtime procedure, and elevated vendor support on site or on call for the first several days.
- Best for: single-site practices, systems where dual entry is impractical, teams that have completed thorough testing.
- Watch out for: incomplete migration, untested interfaces, and staff who skipped training because "it will be fine."
- Typical duration of disruption: two to ten business days of reduced productivity, depending on system complexity.
Parallel run: safe on paper, expensive in practice
A parallel run sounds like the cautious choice, and for certain narrow systems it is. Running an old and a new claims scrubber side by side for a month, comparing which claims each one flags, is a reasonable way to validate the new tool before trusting it. The same is true of a new payroll system or a new reporting tool where outputs can be compared mechanically.
For systems that staff interact with all day, a parallel run is usually a mistake. Entering every appointment, every note, or every charge twice doubles the workload during the period when staff are least familiar with the new system. Errors creep into both systems because people are rushed. Worse, the parallel period tends to get extended, because the comparison never looks clean enough and nobody wants to be the one who says the old system can be turned off. Practices that intended a two-week parallel run sometimes find themselves paying for two systems six months later.
Rule of thumb: a parallel run makes sense when the two systems produce outputs that can be compared automatically and the data entry is already automated or minimal. If humans have to type everything twice, choose a different strategy.
Phased rollout: the middle path
A phased rollout limits the blast radius of any problem to one location, one department, or one function. A multi-site group might move its smallest clinic first, learn from that experience, and then move the rest on a schedule. A single practice might move scheduling and registration first, then clinical documentation, then billing. Each phase is a small hard cutover with the lessons of the previous phase applied.
The trade-off is complexity in the middle. While the practice is split across two systems, data has to flow between them or be reconciled manually. A patient scheduled in the new system but charted in the old one creates work for someone. Interfaces between old and new systems for the interim period are sometimes possible but often not worth building. Phased rollouts also stretch the total project timeline, extend the period during which both vendors need to be paid, and can exhaust the implementation team.
- Best for: multi-site groups, large departments with distinct workflows, and situations where a pilot site can prove the configuration before wider rollout.
- Watch out for: the interim period where data lives in two places, and the temptation to keep delaying later phases.
How to choose for your practice
A few questions usually settle the decision. First, can the outputs of the two systems be compared automatically? If yes, a short parallel run may be worthwhile. If no, rule it out. Second, is there a natural unit, a site or department, that can go first without breaking shared workflows? If yes, a phased rollout is available. If everyone shares the same schedule and the same charts, it probably is not. Third, how confident is the team in the migration and testing? If user acceptance testing was completed and signed off, a hard cutover is reasonable. If testing was skipped or rushed, no go-live strategy will save the project, and the honest answer is to delay the date.
| Factor | Hard cutover | Parallel run | Phased rollout |
|---|---|---|---|
| Staff workload during transition | High for a short period | Very high, doubled entry | Moderate, spread over time |
| Risk of undiscovered defect at go-live | Highest | Lowest | Contained to one phase |
| Duration paying for two systems | Shortest | Often longer than planned | Length of the full rollout |
| Data consistency during transition | Clean after cutover | Two copies to reconcile | Split across systems |
| Best-suited systems | EHR, PM, scheduling | Scrubbers, reporting, payroll | Multi-site EHR, departmental tools |
Planning the transition week
Whichever strategy is chosen, the week of go-live needs a plan of its own. Reduce the schedule for the first two or three days, typically by 30 to 50 percent, so staff have time to work slowly in the new system. Name a command center, even if it is just a conference room and a group chat, where problems are logged and triaged. Assign super-users on every shift who can answer questions before they become tickets. Confirm the vendor's support escalation path and who on the practice side is authorized to approve emergency configuration changes.
Decide in advance how long the old system stays accessible in read-only mode and who has access. Most practices keep the legacy system available for reference for several months, then export what must be retained and decommission it. Finally, schedule a review at the end of the first week and again at thirty days, and write down what would be done differently. The next implementation, and there will be one, benefits from that record.
Common questions
Is a parallel run ever the right choice for an EHR?
Rarely. Dual charting doubles clinician workload during the most stressful period of the project and introduces errors in both systems. Parallel runs work best for systems whose outputs can be compared automatically, such as claim scrubbers or reporting tools.
How long should a practice keep the old system after a hard cutover?
Most practices keep it in read-only mode for several months for reference, then export any records that must be retained and decommission it. The retention requirements for the records themselves do not go away when the software does.
How much should we reduce the schedule during go-live week?
A common approach is 30 to 50 percent for the first two or three days, returning to normal volume over one to two weeks as staff regain speed.
What is the single biggest predictor of a smooth go-live?
A completed, signed-off user acceptance test on a recent data migration. No go-live strategy compensates for skipped testing.