A PACS migration means moving a clinic's actual patient archive from one vendor to another, not just switching software. That is what makes it feel riskier than almost any other buying decision in radiology: the thing being moved is years of studies, and for the length of the move, the outgoing vendor still holds the only copy you can be sure works.
Why PACS migration is the scariest move in the category
Change an EHR and the old vendor hands over a data export, a finite, well-understood job. Change a PACS and the outgoing vendor is sitting on a decade of studies with every incentive pointed the wrong way: a painful export makes leaving harder, and a vendor losing a customer has little reason to make that customer's exit fast. This is not a conspiracy theory, it is how the incentives actually line up, and some vendors lean on that leverage openly when a clinic mentions switching.
Three specific things turn "we are switching PACS" into a stalled project instead of a clean one:
- The archive is the leverage. A vendor that knows the export is painful has one less reason to make it painless.
- Export runs on their calendar. A support ticket that used to close in a day can sit for weeks once you have announced you are leaving.
- The format fight. Some archives export as standard DICOM with a DICOMDIR the new system reads directly. Others export into a container only the old vendor's own software can open, turning "export" into a paid conversion project.
None of that is a reason to stay somewhere that no longer fits. It is a reason to plan the migration itself as its own project, with its own checklist, rather than trusting it to happen as a footnote of signing with the new vendor.
The four stages of a clean PACS migration
Every migration that goes well breaks down the same way, regardless of which two systems are on either end. Skipping a stage is usually where the horror stories start.
1. Get the full DICOM export, in writing, first
Before signing anything with a new vendor, get the outgoing vendor's export terms in writing: standard DICOM with a DICOMDIR, reports included, a real delivery date, and the cost, if any. A verbal "we'll get you your data" is not a plan. Confirm this before the new contract is signed, not after, because your negotiating leverage with the old vendor is highest while you are still a paying customer.
2. Bulk import with resume, not one all-or-nothing transfer
A migration that moves a real archive in one uninterruptible transfer is a migration designed to fail at least once. Real clinic connections drop, offices close for the night mid-upload, and a multi-gigabyte disc takes real time on real bandwidth. The import step needs to survive an interruption and continue from where it stopped, not restart the whole job because a router rebooted.
3. Run both systems in parallel
Keep the old PACS live and readable while the new one runs a real stretch of studies, ideally with new studies routed to both. This is the step that catches a gap, a missing modality, a series that did not transcode, a report that got separated from its images, before the old system is switched off and the gap becomes permanent.
4. Cutover, on a date you chose
Cutover happens once every study from the parallel window is confirmed present and readable on the new system, worklist, reporting and referral routes all tested with real staff. The old system's exit terms, read-only or fully retired, should already be settled from stage one, so cutover day is a formality, not a negotiation under pressure.
| A risky migration | A clean migration | |
|---|---|---|
| Export | A support ticket on the outgoing vendor's calendar, format decided by them | Full DICOM export secured in writing before signing anywhere else |
| Transfer | One long upload that restarts from zero after any dropped connection | Chunked import that resumes from the last completed piece |
| Duplicates | Manual checking, or the same study re-imported twice after a retry | Automatic two-layer dedup by file hash and DICOM instance ID |
| Verification | Cutover on faith that everything arrived | Old and new systems run in parallel until every study is confirmed |
| Mid-transfer failure | A support ticket, a manual restart, and hope nothing duplicated | The import resumes itself after a crash or reboot, nothing lost or doubled |
How MiniPACS actually handles the bulk import
Picture the migration day itself. An administrator drags the folder holding years of exported studies from the old PACS onto the MiniPACS import screen, no software to install first, whole folders accepted, junk files like Thumbs.db and .DS_Store filtered out automatically instead of uploaded alongside the real DICOM files. Twenty minutes in, the clinic's internet drops. Fifteen minutes later it is back. The import does not start over. It picks up from the exact chunk it was on, and when it finishes, nothing has landed twice.
That behavior is not a claim, it is a specific mechanism:
- Chunked, resumable upload. Every file is split into 5MB chunks, uploaded several files and several chunks at a time. The server remembers exactly which chunks already arrived, so a resumed upload after a dropped connection sends only what is missing, not the whole file again.
- A streamed checksum before a single byte commits. The browser computes a SHA-256 hash of each file as it prepares to upload and checks it against every archive already imported, catching an accidental re-upload of the same disc before the transfer even starts.
- Two-layer dedup. The file-hash check catches the same package uploaded twice. A second, independent check against each image's own DICOM instance ID catches the same study arriving repackaged differently, for example from two different export discs of the same patient. Both have to disagree for an image to import twice.
- Self-healing after a crash. If the import server itself restarts mid-job, a deploy, a reboot, a power event, the job is not left stuck showing "processing" forever. On restart it is marked accordingly, the chunks already on disk are kept, and retrying re-uploads only the missing part. The same resume logic covers a clinic-to-clinic transfer interrupted by a deploy and a branch gateway that loses power mid-upload, three independent recovery paths, not one shared assumption that nothing ever crashes.
- A four-phase view of exactly where an import stands. Hash, dedup, upload, store, shown as a timeline instead of one spinner, so a stall shows up as "stuck at dedup" rather than a generic error with no next step.
- A full import history. Every job a clinic has ever run stays searchable, with the studies it created one click away, so "where did that batch from the old system end up" has an answer months later.
None of this is theoretical. The same chunked-import engine already moves millions of images in production, at clinics that migrated exactly this way, off exactly the kind of export a vendor was in no hurry to hand over.
Questions to ask your outgoing PACS vendor before you sign anything
- What format will the export be in, and does it include reports? Standard DICOM with a DICOMDIR, or a proprietary container that needs their software to open. Get the answer in writing, not as a verbal assurance.
- What does the export cost? Some vendors invoice a separate migration or egress fee, sometimes only disclosed after you give notice. Ask for the number before you announce anything.
- What is the timeline, on paper? A support ticket that "usually" takes a few days is not a delivery date. Ask for a written SLA on when the full export lands.
- Do you keep read access during the transition, or does it go dark? Confirm whether the archive stays viewable while the export processes, or whether giving notice cuts off access to your own patients' images immediately.
- Does the export include everything, or just images? Signed reports, share-link history, referring-physician contacts. Losing the structured extras quietly turns a migration into a partial one.
The same checklist works regardless of which vendor is on the way out; for the categories those vendors fall into and how their pricing models differ, see PACS system vendors. For what the switch actually costs on both ends, see the PACS cost guide.
Where MiniPACS fits
MiniPACS is built to be the receiving end of exactly this kind of migration: a self-hosted archive with a resumable bulk import, browser viewing with nothing to install, and a flat $300 per month per location with no migration fee added on top. Setup starts at $1,500. If the archive being migrated has been through a bulk import before, the process is the same one described above, not a special one-time script. For the deployment question in general, see self-hosted PACS; for the hardware and connection steps, see how to self-host a DICOM server; and for pricing and a live demo you can click through yourself, see the landing page.
FAQ
How long does a PACS migration take?
It depends on archive size and the outgoing vendor's export timeline more than on the transfer itself. The export step is usually the slow part, days to weeks depending on how cooperative the old vendor is. The import step is bandwidth bound: MiniPACS's own stale-import thresholds are tuned around a median clinic uplink of about 8.7 Mbps, where a single 4GB disc can take close to an hour to move. A resumable, chunked import does not make the transfer faster, but it means a slow connection or a dropped Wi-Fi link only costs the time actually lost, not a restart from zero. Plan for a parallel run of at least a week or two on top of the transfer time before cutover.
How much does PACS data migration cost?
Two separate numbers, and vendors like to blur them. The outgoing vendor may charge an export or egress fee, sometimes disclosed only after you give notice, so get that number in writing before you announce you are leaving. The incoming side is usually simpler: MiniPACS charges no migration fee on top of the published price, one-time setup starts at $1,500 and the monthly license is a flat $300 per location, so moving in a decade of studies costs the same $300 a month as moving in a handful.
Can I run two PACS in parallel during a migration?
Yes, and it is the single best insurance against a bad cutover. Point new studies at both systems for a trial window, most modalities can send C-STORE to two destinations, keep the old archive live and read-only, and confirm every study lands correctly on the new system before you switch reading over. MiniPACS's PACS Nodes page is built for exactly this: register the old system as a node, test the connection with a one-click C-ECHO, and route studies to both archives without an admin call to either vendor.
What DICOM export format should I ask my old PACS vendor for?
Standard DICOM, not a proprietary container. A well-formed export includes a DICOMDIR at the root so any DICOM-aware system can walk the archive without a conversion step, and it includes the signed reports alongside the images, not as a separate request. If the outgoing vendor's answer to 'what format' is a proprietary backup file that only their own software reads, that is the format fight already starting, and it is worth pushing back on before you sign anything with anyone new.
What happens if a PACS migration gets interrupted halfway through?
With a well-built import, nothing gets lost or duplicated, it just resumes. MiniPACS marks any import job left unfinished by a restart or a crash rather than leaving it stuck as 'processing' forever, the chunks already received stay on disk, and retrying the job re-uploads only what is missing rather than the whole archive. The same self-healing logic covers a C-STORE transfer interrupted by a deploy and a branch gateway that loses power mid-upload. The honest failure mode to worry about is a migration built as one long unresumable transfer, where a dropped connection two hours in means starting the whole thing over.