
How to Migrate Your PACS to the Cloud Without Losing Studies: A Step-by-Step Guide (2026)
Migrating your PACS from a local server to the cloud is one of the best technology decisions an imaging center can make. But it's also one that generates the most anxiety: what if I lose studies? What if something doesn't work? How long will I be without a system?
The good news is that a well-planned migration is predictable, safe, and can be done without disrupting your daily operations. In this guide we explain how to do it step by step.
Why migrate to the cloud (and why now)
If you still operate with an on-premise PACS, you probably face some of these problems:
- Aging hardware: Your server is 5+ years old and failing more often. Replacing it costs between $10,000 and $30,000 USD.
- Uncertain backups: When was the last time you verified your backup is restorable? 40% of backups fail when restoration is attempted.
- Limited access: You can only view studies from the internal network. External radiologists need VPN or CDs.
- Growing costs: Server maintenance, software licenses, electricity, physical space, dedicated IT support.
- Zero scalability: Each additional terabyte of storage requires buying and configuring more disks.
A cloud PACS eliminates all these problems: you pay a monthly subscription, access from any browser, data is backed up automatically, and storage scales without intervention.
The 6 steps of a successful migration
Step 1: Inventory and assessment (Week 1)
Before moving anything, you need to know exactly what you have:
- Data volume: How many studies? How many terabytes? Which modalities (CT, MR, CR, US)?
- Date range: How far back do your stored studies go?
- Data integrity: Are there corrupt, incomplete, or metadata-less studies?
- Current integrations: Does your PACS connect with an HIS, RIS, or worklist? How?
- Imaging equipment: Which devices send studies to the PACS? Which DICOM protocols do they use?
Tip: Davix performs this inventory as part of the onboarding process, at no additional cost.
Step 2: Cloud PACS configuration (Week 1-2)
While data is being assessed, the new environment is configured:
- User and role creation
- Worklist and assignment rule configuration
- Report template customization
- AE Title configuration to receive studies from your equipment
- Patient portal and referring physician portal activation
Step 3: Historical data migration (Week 2-4)
This is the most critical part. There are two strategies:
| Strategy | How it works | Pros | Cons |
|---|---|---|---|
| Full migration | ALL historical studies are transferred to the cloud PACS | Complete history in one place | May take longer; higher transfer cost |
| Selective migration | Only studies from the last N years are transferred; older ones remain in an archive | Faster; lower cost | Need to keep the old archive accessible |
How is data transferred?
- Via network (DICOM C-STORE): The on-premise PACS sends studies to the cloud PACS using standard DICOM protocol. Cleanest method but depends on bandwidth.
- Via physical disk: For very large volumes (>5 TB), data is exported to an encrypted external disk and shipped to the cloud provider for direct upload. Faster for large volumes.
- Hybrid migration: Recent studies via network; historical via disk.
Ready to digitize your health center?
Discover how Davix can transform your hospital or clinic management with world-class technology.
Schedule Free DemoStep 4: Parallel operation period (Week 3-5)
For 1-2 weeks, both systems operate simultaneously:
- Imaging equipment sends studies to the cloud PACS (new destination)
- The on-premise PACS remains accessible for studies not yet migrated
- Radiologists work on the cloud PACS for new studies
- All workflows are verified to function correctly
This phase is your safety net: if something doesn't work, the old PACS is still operational.
Step 5: Validation and verification (Week 4-5)
Before shutting down the on-premise PACS, verify:
- Study count: Does the number of studies in the cloud match the source?
- Image integrity: Random samples of migrated studies are reviewed to verify images are complete and uncorrupted.
- Correct metadata: Were patient data, dates, and descriptions preserved correctly?
- Full functionality: Do reports, worklists, and portals work as expected?
Step 6: Cutover and decommissioning (Week 5-6)
Once everything is validated:
- All imaging equipment is redirected to send exclusively to the cloud PACS.
- The on-premise PACS is removed from active operation.
- The old server is kept powered off for 30-90 days as a contingency backup.
- The old server is formally decommissioned.
How long does a typical migration take?
| Center size | Estimated volume | Total time |
|---|---|---|
| Small center (1-2 modalities) | < 1 TB | 2-3 weeks |
| Medium center (3-5 modalities) | 1-5 TB | 3-5 weeks |
| Large center / hospital | 5-20 TB | 5-8 weeks |
| Multi-site group | > 20 TB | 8-12 weeks |
7 mistakes to avoid
- Not doing a prior inventory. If you don't know how many studies you have, you can't validate they all arrived.
- Migrating without a parallel period. Never shut down the old PACS until the new one is 100% validated.
- Ignoring integrations. If your PACS connects with an HIS or RIS, those connections must be reconfigured in the new system.
- Underestimating bandwidth. A 500 MB CT scan over 10 Mbps internet takes ~7 minutes. Multiply that by thousands of studies.
- Not training staff. The new system may have a different interface. Invest time in training before go-live.
- Forgetting studies on CDs. If you have studies delivered on CD that aren't in the PACS, this is the time to import them.
- Not verifying integrity after migration. Just because a file arrived doesn't mean it's complete. Open random studies and visually verify.
Frequently asked questions
Can I keep operating normally during the migration?
Yes. Historical data migration happens in the background. Your daily operation continues without interruptions. During the parallel period, new studies go to the cloud PACS while historical ones are being migrated.
What if my internet isn't fast enough for a cloud PACS?
For daily operations, 20 Mbps upload is sufficient for most centers. For massive historical data migration, physical disk shipping can be used. Once migrated, bandwidth consumption is much lower since you're only uploading new studies.
Are my current imaging devices compatible with a cloud PACS?
Yes. Any device that supports DICOM C-STORE (virtually all devices from the last 15 years) can send images to a cloud PACS. The configuration is identical to an on-premise PACS — only the destination IP address changes.
How much does migration cost with Davix?
Migration is included in the Davix PACS/RIS implementation process. There are no additional costs for data migration. The Davix team accompanies the entire process, from inventory to old server decommissioning.
Conclusion
Migrating your PACS to the cloud doesn't have to be an odyssey. With proper planning, a parallel operation period, and rigorous validation, you can do it without losing a single study and without disrupting your operation:
- Plan before moving. A good inventory prevents surprises.
- Operate in parallel. Never shut down the old system until the new one is validated.
- Validate everything. Count, integrity, and metadata.
- Train your team. Technology is only as good as the people who use it.
Check the Davix PACS/RIS pricing or schedule a demo to start your cloud migration.
Related articles

How to Automate Appointment Scheduling at Your Clinic and Reduce Administrative Burden (2026)
Practical guide to automating medical appointment scheduling: reduce phone calls, eliminate double booking, and improve patient experience with digital tools.

Set Up Teleradiology with Davix in 15 Minutes: Step-by-Step Tutorial
Practical tutorial to configure teleradiology with Davix PACS/RIS: from creating users to receiving the first signed report, in under 15 minutes.

How to Turn Satisfied Patients Into Ambassadors for Your Clinic (2026)
Practical strategies to transform satisfied patients into active promoters who recommend your clinic: from NPS to action with a scalable system.