Go-live Monday, just after ten. One of our physicians stood in a doorway holding a laptop, a patient already roomed behind him, hunting for an order he had placed a hundred times a week in a system that no longer existed. The vendor's trainer told him it gets easier around week three. He said something I will not reprint. He was not angry about software. He was angry because he was forty minutes behind and nobody had warned him he would be.
I have run a system migration as practice manager of a large Cincinnati medical practice, and the part that surprises people is never the technology. It is the arithmetic. A practice that changes systems loses throughput for a stretch after go-live, and that loss has a predictable shape and a roughly predictable size. It almost never appears anywhere in the project budget.
The budget covers the purchase, not the transition
Look at how these projects get costed in the field and you find license fees, implementation fees, interface builds, hardware refresh, overtime for the build team. All real money, all of it leaving the practice for something you can point at. None of it the largest number.
The largest number is clinician hours at reduced speed. For several weeks, providers who used to see a full panel see fewer patients, spend longer in the note, and finish charting at home. Multiply a modest per-day visit reduction across every provider across six or eight weeks and the figure dwarfs the interface build. It belongs in the pro forma, on the same page as the license cost, before anyone signs. Leaving it out does not avoid the expense, it only guarantees being surprised by it.
Cut the schedule on purpose, or it cuts itself
The reduction is happening either way. You can thin the template deliberately for the first weeks, or hold volume and watch it come out as forty-minute delays, staff staying past six, and patients rebooked from a day that fell apart. The second version costs the same visits and buys resentment with them.
So we thinned it on purpose, hardest in the first week, stepping back up in stages as the floor got faster. That is an unpopular decision with owners, and the way to make it survivable is to say out loud what the money buys: a go-live the staff are still standing at the end of. I watched third-next-available through the whole period too. A thinned template pushes access out, and access that goes out during a migration stays out unless somebody works it back down on purpose.
The revenue dip arrives later than the productivity dip
This is the piece that catches finance off guard. Visit volume falls in week one. Cash does not. Charge capture lag stretches while providers learn where charges live, claims sit while the billing team works out which fields moved, and early claims carry new-build errors that pull clean claim rate down before anyone has diagnosed why. Registration fields land in different places, so the front desk starts generating denials it never used to. All of it surfaces in the deposit a month or more after go-live, exactly when everyone has decided the hard part is over.
I would rather tell physician owners in advance that one month's collections report will look bad, and why, than explain it afterward.
The build is a political project with a technical component
Vendors staff migrations as implementations. They are adoption projects. Templates and order sets can be correct and still sit unused if the people expected to use them had no hand in shaping them. What moves adoption is other physicians. A colleague who says a workflow is usable outweighs any trainer, which is why the clinicians who help build it are the whole game. Give them real time for it, protected on the schedule rather than squeezed between patients, and plan on spending your own days in persuasion. The trainers go home after go-live week. The build is yours permanently.
Optimization is the phase that pays, and the one that gets cancelled
By the time a practice is through go-live, everyone is tired, the open issues list is embarrassing, and the pressure to declare victory and go back to running the place is enormous. Optimization gets pushed to a quarter that never quite arrives.
That phase is where the return lives. It is where order sets start matching how these providers actually practice, where templates lose the fields nobody fills, where in-basket routing stops sending every result to the busiest physician in the building, and where the CliniSync data a provider needs sits in front of them instead of two clicks away. A migration is finished when the practice is faster than it was before, and that date has to be scheduled and defended. It never arrives by itself.
What I sequence differently now
The dip goes in writing before the contract is signed, with the weeks it covers named. The optimization sprint goes on the calendar the same day the go-live date does, because a phase with no date is a phase that will not happen. And I stopped calling any of it a temporary inconvenience to get through. It is a planned, financed loss taken in exchange for something better, and that is a conversation physician owners are willing to have, as long as you have it early.