Migrating from legacy systems without downtime
An operational guide to moving your IPS to a new platform without stopping clinical care or billing.
An IPS (instituciones prestadoras de salud, Colombia’s healthcare provider institutions) cannot shut down. No Saturday night maintenance window works when the emergency department keeps receiving patients and inpatient care never stops. That is the constraint that makes migrating a hospital system look very little like migrating any other software.
The good news is that the problem is well studied. The bad news is that most migrations fail for reasons that have nothing to do with technology.
Why migrations fail
It is almost never a data problem. It is a sequencing problem: trying to move everything at the same time.
The typical pattern is the big-bang migration: a long weekend, everyone working, and on Monday you start on the new system. It works in small institutions with simple processes. In an IPS with several sites, what happens is that fifteen problems show up at once at 7 a.m. on Monday, nobody knows which one caused which, and there is no way to isolate the failure because everything changed at the same time.
The alternative is boring and it works: migrate in phases, in an order that respects the real dependencies of the operation.
The order that does work
Phase 1. The foundations, without users.
Before anyone touches the new system, you configure what does not change day to day: the fee schedule, the contracts with the EPS (entidades promotoras de salud, Colombia’s health insurers), the chart of accounts, the warehouses, the cost centers, the service structure and the user roster with its profiles.
This phase has no glamour, and it is where the project is won or lost. A badly loaded fee schedule does not show on day one; it shows on day 45, when billing does not add up and there are already six weeks of operation on top of it.
Phase 2. A pilot service, in parallel.
Choose a contained, low-risk service: outpatient care for one specialty, or a small site. For two or three weeks that service runs on the new system while the rest stays on the old one.
Yes, there is double data entry at the boundary. It is a real and limited cost, and it is much cheaper than discovering a configuration problem with the whole institution already inside.
Phase 3. The care cycle.
Admissions, scheduling, clinical records, inpatient care. This is where the system touches doctors, and where resistance to change is highest and most legitimate: a doctor who takes three more minutes per patient sees twenty fewer patients a week.
Phase 4. Billing and accounts receivable.
It moves near the end for a specific reason: you need the care cycle to be producing clean data before you bill it. If you bill on a clinical record that is still stabilizing, the claim objections (glosas) of the first quarter are going to hurt.
Phase 5. Administration.
Inventory, purchasing, accounting, shift rosters. Important, but it can coexist with the old system longer without affecting patient care.
Which data to move, and which not to
The temptation is to migrate everything. It is rarely the right decision.
Migrate hot what the operation needs tomorrow: active patients, current inpatients, future schedules, open accounts receivable, current inventory, contracts in force.
Migrate cold what gets looked up but not worked on: closed clinical records, billing filed in previous years, historical inventory movements. These can come in after go-live, without pressure, and can even stay in a lookup repository.
Do not migrate what you will never look at again. Every table you drag along is a table you have to map, validate and maintain. A migration is the only realistic chance to leave fifteen years of accumulated junk behind. Take it.
One important nuance: clinical records have legal retention and availability requirements. “Do not migrate” never means “delete”: it means deciding consciously whether they live in the new system or in a searchable archive, and keeping that decision documented.
Reconciliation is non-negotiable
After each phase, before moving on to the next, you have to prove that the data arrived complete. Not with a visual check: with counts.
How many patients there were in the source and how many there are in the target. What accounts receivable adds up to on each side. How many units the inventory holds. If the numbers do not match 100%, you do not move on, and every difference gets explained one by one, not averaged out.
This step is often skipped because it is tedious and because the timeline is tight. It is exactly the step that separates a migration from a silent disaster discovered three months later.
The factor nobody budgets for
Your own team’s time.
During a migration, your billing lead, your admissions coordinator and your IT manager will spend between 20% and 40% of their workday on the project, on top of their regular work. If that is not planned, it will come from somewhere: almost always from the quality of the configuration or from your people’s rest hours.
Plan for it explicitly. Reassign workload, bring in temporary help, or extend the timeline. All three are reasonable options; pretending the time will appear on its own is not.
A realistic timeline
For a midsize IPS with several sites, four to twelve weeks is a reasonable range, depending on how many modules are activated and how clean the source data is.
Be wary of anyone who promises you two weeks. Not because it is technically impossible to move the data in two weeks, but because the migration is not the bottleneck: your team’s capacity to absorb the change while still caring for patients is.
