Practice management
How to migrate your PACS without stopping the service
Almost no center changes PACS for fun. You change when the current system costs more than it solves: the viewer requires installing clients that break with every update, support takes days, renewing the servers cannot be justified, or every new integration arrives with a separate quote.
And yet the decision gets postponed for years. The reason is nearly always the same: the legacy archive. Nobody wants to be the person who lost ten years of studies.
It is a reasonable fear, but it is a solved problem. It is worth understanding how.
First: verify the archive can be extracted
Before talking about timelines there is one question that defines everything else: can the archive be pulled out of the current system using standard DICOM?
If the PACS responds to C-MOVE, C-GET or exposes DICOMweb, the migration is viable even without active cooperation from the outgoing vendor. Query access to the archive is enough. If the system stores in a proprietary format and exposes no DICOM services, the picture changes and extraction has to be negotiated — a good reminder of why it is worth demanding open-standard export in the contract for the new system.
This is the first thing examined in any serious migration assessment, before any proposal.
The migration runs in parallel, not as a cutover
The idea of “switch off on Friday, switch on on Monday” is what makes a migration feel like a major risk, and it is not how it is done.
The current system keeps operating normally. In parallel, the new PACS starts receiving new studies while the legacy archive transfers in the background. During that period there are two live systems and the service never stops. The old system is shut down only once the archive is complete and verified.
That also allows prioritization: typically the last two or three years come first — the ones used as comparisons in daily reading — and the rest arrives in a second phase. The center starts operating on the new platform long before the full transfer finishes.
Copying is not migrating: you have to prove everything arrived
This is where well-executed migrations separate from the ones that cause problems two years later.
Transferring studies is the easy part. The part that matters is reconciliation: comparing source and destination at the level of studies, series and instances, and validating patient identifiers. Any discrepancies that surface — a duplicate patient with two ID numbers, an incomplete series, a study that never transferred — get resolved before the migration is declared closed.
Without that reconciliation report, what is missing does not get discovered during the migration. It gets discovered months later, when a radiologist looks for a comparison and it is not there.
The reports are part of the archive too
A detail that is frequently overlooked: migrating the images is not migrating the history. The associated reports and their metadata have to travel as well, or the archive ends up with the images but without the reading that interpreted them.
It is worth stating explicitly in the scope from the start, because not every migration proposal includes it by default.
Not repeating the problem
If you are migrating because you got trapped in a system that was hard to leave, the obvious lesson is not to sign the same thing again.
Ask the new vendor, in writing: what format is it stored in? Does it expose DICOMweb? What is the procedure and the cost of extracting the entire archive if I decide to leave? A vendor that stores in standard DICOM and exposes WADO, QIDO and STOW can answer that without hedging, because it is technically verifiable.
One cost point worth anticipating: bulk download of images from the cloud generates traffic, and that traffic is billed. It is not a hidden charge as long as it is sized in the proposal; it is one when it shows up in the fine print.
At NOVA Imaging the migration works like this: in parallel, over standard DICOM, with study-by-study reconciliation and without the service stopping. You can see the platform in detail on the RIS/PACS page, or message us on WhatsApp telling us which system you use and how much archive you have, and we will tell you whether it is viable and how it would be done.