PACS migration checklist: how imaging practices change PACS without losing a day of reporting

Why PACS migrations go wrong

Changing PACS is one of the highest-stakes IT projects an imaging practice ever runs, because it touches the archive, the worklist, the reporting workflow, and the referrer experience all at once. The software swap is rarely the hard part. Migrations run into trouble in a handful of predictable places:

• Underestimated data migration timelines. Years of studies add up, and migration speed is limited by the old archive as much as the new one. Vendors can profile throughput, but any timeline quoted before anyone has looked at your actual archive is a guess.
• DICOM tag and mapping issues. Study descriptions, procedure codes, accession numbers, and patient identifiers drift over years of operation. If that metadata is not mapped and cleaned during migration, studies arrive in the new PACS mislabelled, duplicated, or effectively invisible to search and prior linking.
• Modality worklist reconfiguration. Every modality (CT, MRI, ultrasound, x-ray, mammography) points at the worklist and archive. Each one needs to be repointed, tested, and confirmed against the new system, and older modalities can be temperamental about it. Forgetting a single machine surfaces as a technologist standing at a console that cannot send.
• Prior-study availability during the transition. Radiologists report against priors. If a staged migration leaves last year’s studies on the old system with no reliable way to fetch them, reporting slows down and confidence in the project evaporates quickly.
• Reporting downtime at cutover. The cutover window is where poor planning becomes visible. Without a parallel run, a rollback plan, and a quiet-window schedule, a problem that should have cost an hour costs a reading day.

None of these are exotic. They are all foreseeable, which is why a checklist approach works. The phases below are a starting structure you can adapt with your vendors and your IT partner. If you want help running this process end to end, Trucell’s radiology IT support and PACS and RIS services cover exactly this ground.

Phase 1: scoping and data audit

Before anyone signs anything, understand what you actually hold.

• Count and profile the archive. How many studies, over what date range, at what total volume? Which modalities, and are there legacy formats or compressed archives in the mix?
• Assess metadata health. Sample studies across the years and look for inconsistent study descriptions, duplicate patient records, changed accession number formats, and site or procedure codes that no longer exist. This sample is what turns tag mapping from a surprise into a work item.
• Map the integration landscape. List everything that talks to the current PACS: the RIS, modality worklist, reporting and dictation tools, referrer portals or image-sharing services, billing touchpoints, and any downstream archives. Each connection is a migration task.
• Identify what does not need to move. Some practices carry test studies, orphaned data, or studies past every retention obligation. Deciding what is in scope before migration is far cheaper than migrating everything and cleaning up later.
• Document current reporting workflow. Peak reporting hours, on-call arrangements, and the days the list absolutely cannot slip. Cutover planning in Phase 5 depends on this.

The output of this phase is a written scope: study counts, data volume, metadata risks, integration list, and workflow constraints. That document keeps vendor conversations honest.

Phase 2: vendor due diligence questions

Whether you are evaluating a new PACS vendor, a migration specialist, or both, the questions that matter are the ones about your data rather than their demo. Ask:

• Have you migrated from our current PACS before? Migrating out of a specific legacy system is a skill in itself. Ask for references from practices of a similar size on the same source system.
• How will you profile our archive before committing to a timeline? A credible answer involves analysing your actual data, not quoting an average.
• How is DICOM tag mapping handled, and who signs it off? You want a documented mapping that someone clinical reviews, not a silent default.
• What happens to studies that fail to migrate? There will be some. Ask how exceptions are detected, reported, reprocessed, and reconciled, and what the acceptance threshold is before cutover.
• How do you verify completeness? Study counts alone are not verification. Ask how they reconcile study-level and image-level counts between source and destination, and what the verification report looks like.
• What is the rollback plan if cutover fails? If the answer is vague, the plan does not exist.
• What does the old vendor charge for data export? Exit costs and export formats from the incumbent are a common late surprise. Establish them early, in writing.
• Who owns the migration end to end? When a PACS vendor, a migration contractor, a RIS vendor, and an internal IT team each own a piece, gaps appear at the joins. One party should hold the overall plan.

Phase 3: choose the migration approach

There are two broad approaches, with hybrids in between.

Big bang. All historical data is migrated to the new PACS first, and cutover happens once the archive is complete and verified. Radiologists start on the new system with full priors available. The tradeoffs are a longer runway before cutover, a larger up-front migration effort, and the need to keep the archive synchronised with new studies while the migration catches up.

Staged with prior fetch. Recent studies and a defined prior window are migrated first, cutover happens sooner, and older studies either continue migrating in the background or are fetched on demand when a patient with old imaging returns. This gets the practice onto the new system faster and spreads the migration load, but it lives or dies on prior availability: the fetch mechanism must be fast and reliable, and radiologists need to know exactly what to expect when they open a study whose priors have not yet moved.

Which is right depends on your archive size, how heavily your case mix depends on long prior histories (screening and oncology work leans harder on priors than emergency work), how long you can run two systems side by side, and your appetite for a longer project versus a more complex transition period. Decide this consciously with your vendor rather than inheriting whichever approach their standard project plan assumes.

Phase 4: parallel run and validation

Do not take the vendor’s word that the migration worked. Prove it while the old system is still available.

• Reconcile the counts. Compare study and image counts between source and destination across the full date range, and chase every discrepancy to a named cause.
• Validate clinically, not just technically. Have radiologists open a sample of migrated studies across modalities and years and confirm that images display correctly, series are complete, priors link to the right patient, and measurements and annotations behave as expected.
• Test the worklist end to end. Send test studies from every modality, confirm they arrive against the correct order, and confirm the reporting workflow completes through to result distribution.
• Exercise the exception process. Review the failed-study list from the migration tooling and confirm each exception is either resolved or consciously accepted.
• Run the two systems in parallel on live work for an agreed period, with new studies flowing to both, so the new PACS is proven on real volume before the old one stops being the system of record.

This phase is also where backup arrangements for the new environment should be confirmed and tested, not assumed. A brand new archive with no proven restore path is a risk you have just paid to create. Trucell’s backup and recovery page covers what a tested restore actually involves.

Phase 5: cutover planned around reading lists

Cutover is a scheduling exercise as much as a technical one.

• Pick the quietest safe window based on the workflow documentation from Phase 1: typically outside peak reporting hours and clear of days when the list cannot slip.
• Freeze changes to the PACS environment in the lead-up. Cutover night is not the time for unrelated upgrades.
• Keep the old system read-only. Radiologists and technologists should be able to look things up on the old PACS during the transition period without any risk of new data landing there.
• Agree the rollback decision in advance. Define who makes the call, by what time, and against what criteria. A rollback decided calmly at the planning table is cheap; one improvised at 2 am is not.
• Staff the morning after. The first reading session on the new system is when small issues surface. Have vendor and IT support on hand, and a rapid channel for radiologists and technologists to report problems.
• Tell the people around you. Referrer portal users, after-hours reading services, and any teleradiology partners need to know the date and what changes for them.

Phase 6: decommissioning and retention obligations

The project is not finished when the new PACS goes live.

• Keep the old system read-only for a defined safety period agreed with your radiologists, rather than an open-ended “just in case” that quietly becomes permanent.
• Confirm retention obligations before destroying anything. Australian health records law sets minimum retention periods that vary by state and territory and treat children’s records differently from adults’. Diagnostic images and their reports may also be treated differently from each other. Confirm the current requirements for your jurisdiction and patient cohort with your registration body, indemnity insurer, or a suitably qualified adviser before deletion.
• Verify the final export. If the old system is being switched off entirely, confirm you hold a complete, readable, documented copy of anything you are obliged to retain, stored somewhere with its own backup and restore arrangements.
• Close out contracts deliberately. End support and licensing for the old system on your schedule, retrieve or securely destroy any vendor-held data, and get certificates of destruction where data is wiped.
• Update your documentation. Network diagrams, disaster recovery plans, backup scopes, and asset registers all reference the old PACS. Stale documentation is how the next incident gets worse.

Who should be in the room

PACS migrations go wrong in the gaps between roles, so put the roles at one table from the start:

• A radiologist owner. Someone who reports daily and can say what prior availability, hanging protocols, and cutover timing actually mean for the reading list.
• The chief technologist or senior radiographer. Modality worklist changes land on technologists first; they know every machine, including the temperamental ones.
• Practice management. Owns scheduling, referrer communication, and the commercial relationship with both vendors.
• The RIS owner. Whether that is a vendor or an internal role, the RIS side of the integration needs a named person.
• Your IT partner. Network capacity for the data transfer, storage, backup, security, and the integration plumbing between everything else on this list.
• Both PACS vendors. The incumbent controls export; the new vendor controls import. Getting them talking directly, with you in the room, shortens every timeline.

One of these people should chair the project and hold the single plan. If you would rather not build that capability in-house for a once-a-decade project, this is exactly the kind of work Trucell’s PACS and RIS and radiology IT support teams run alongside practices.

A note on scope

This is general guidance, not compliance or legal advice. Migration approaches, vendor capabilities, and data volumes differ between practices, and health records retention requirements differ between Australian states and territories and change over time. Confirm retention and privacy obligations for your jurisdiction with your registration body, indemnity insurer, or a suitably qualified adviser, and confirm technical specifics with your PACS and RIS vendors, before relying on any of the above.