Overview
A migration onto Orthanc moves DICOM studies, their metadata and the modality routing that connects scanners, workstations and archives from a legacy PACS or archive into an Orthanc instance you operate. Routing is the part teams most often underestimate, because the old system's DICOM endpoints, AE titles and forwarding rules usually have to be rebuilt and retested in Orthanc before any study moves. Confirm early which modalities, viewers and external systems send to or pull from the legacy system.
Moving the Orthanc index from SQLite to PostgreSQL is a separate case. The Orthanc Book's scalability FAQ says the built-in SQLite index should be replaced by an enterprise database engine once several hundred thousand DICOM instances are stored, and it recommends the PostgreSQL plugin for large datasets. Since Orthanc 1.9.2 with PostgreSQL or MySQL plugins 4.0, several Orthanc instances can share one database. Decide whether this change happens before, during or after the PACS move, because it changes the index and not the image store.
Teams usually start a migration because of a trigger: the legacy vendor ending support, license cost rising, several archives being consolidated, or a move to a cloud or data center you control. The trigger sets the deadline and the scope. A support end date fixes the decommission date, while consolidation often means mapping several sources with different metadata habits into one model. Write down the trigger and the date it imposes before you agree on a scope.
Teams with DICOM networking, PostgreSQL and Linux operations experience can plan and run a migration in-house, and many do. A partner adds value when the legacy estate is large, when many modalities must be cut over in sequence, or when auditors will ask for documented validation. The hardest parts are data validation and cutover, not the transfer itself. Plan counts per study and instance, checks on patient and study attributes, and a tested rollback before you schedule the switch.
What the work includes
The work falls into eight work packages. Each produces named deliverables, and the written scope states which packages are fixed and which are optional before any work starts.
Source inventory and data assessment
We catalog the legacy PACS or archive: modalities and AE titles feeding it, study and instance counts, storage footprint, transfer syntaxes in use, and private tags or nonstandard objects that Orthanc must preserve. The deliverable is an inventory report that sets the transfer scope and flags data that needs a decision before moving. Check whether the source vendor permits bulk export and whether its counts match what the archive reports.
Transfer design and tooling
We choose how studies move: DICOM C-STORE or C-MOVE from the legacy system, DICOMweb, or file-level export, and whether a database-to-database step is needed when moving from SQLite to PostgreSQL. The design covers throughput limits, retry behavior, and handling of duplicates and failed instances. Ask which methods your legacy vendor supports and what it licenses for bulk export.
Pilot and full transfers
A pilot moves a bounded subset of studies, usually selected across modalities, date ranges and transfer syntaxes, to test the design before the full run. The full transfer then runs in batches with logged progress and resumable checkpoints. Confirm which pilot size and batch schedule are fixed in the written scope and which are agreed after the pilot results.
Verification reports
After each transfer we compare counts of patients, studies, series and instances between source and Orthanc, and sample pixel data and key DICOM attributes for integrity. Discrepancies are listed with their cause, whether a re-transfer fixed them, or whether they are accepted by your data owner. Ask for the report format and the sign-off role before the first transfer begins.
Parallel running and cutover runbook
During parallel running, new studies are sent to both systems so radiologists can compare results before the switch. The cutover runbook sets the order of changes: freezing the source, final delta transfer, DNS or AE title changes, and viewer redirection. A rollback plan defines the conditions to revert and how the legacy system stays readable until those conditions are no longer relevant.
Modality and viewer reconfiguration
Each modality, workstation and viewer that talks to the legacy PACS must point to Orthanc with the correct AE titles, ports and, where used, TLS settings. We configure Orthanc's DICOM modality list and the viewers you choose, which may include Orthanc Explorer 2, Stone Web or OHIF. Confirm early which devices can be reconfigured by your team and which need vendor support.
Handover documentation
The handover pack covers the final architecture, configuration files, database and storage layout, backup and restore steps, monitoring points, and the runbooks for routine tasks. It also records open items and the support path for Orthanc and its plugins. Ask for the handover to be tested by your operations staff before the engagement closes.
What drives cost and duration
The table lists the factors that move effort in an Orthanc migration from a legacy PACS, why each one matters, and what a client can do to keep it under control.
| Driver | Why it moves effort | How to keep it down |
|---|---|---|
| Study and instance count | Every study must be read, validated, transferred and counted, so verification and transfer time grow with volume. Orthanc's documentation notes that the built-in SQLite index should give way to an enterprise database once it holds several hundred thousand instances. | Confirm counts per source before quoting. Decide early whether the database should be PostgreSQL so the index is sized for the expected volume. |
| Total storage volume | Transfer time, network capacity, storage provisioning and checksum verification scale with the bytes moved. Large legacy archives often include uncompressed or poorly compressed objects that take longer to move. | Agree the retention window first. Migrate active studies in the first wave and archive older data separately where policy allows. |
| Source system type and export options | A PACS with a supported DICOM export or C-MOVE path is far simpler than one that requires database extraction or file-system copying. Each route needs its own mapping, testing and rollback steps. | Ask the source vendor which DICOM services and bulk export tools are licensed and enabled. Confirm this in writing before planning the transfer method. |
| DICOM quality issues | Malformed headers, mixed transfer syntaxes and inconsistent patient identifiers cause rejected instances, duplicate patients and manual review. Each defect adds analysis and rework time before data can be trusted. | Run a header and identifier audit on a sample before the full transfer. Agree rules for merging duplicate patients and for handling objects that cannot be parsed. |
| Modalities and viewers to re-point | Every scanner, workstation and viewer that sends or retrieves images needs its AE title, address and port changed and tested. Missed devices cause outages at cutover. | Build an inventory of modalities and viewers with owners. Test each one against Orthanc in parallel running before the cutover window. |
| Integrations such as HL7 and worklists | Patient and order feeds, modality worklists and reporting links must point to the new archive. Message formats and identifiers often need mapping, which takes analysis and testing time. | List every interface, its message types and its owner. Decide which feeds are retired and which are re-pointed, and confirm the Orthanc plugins needed for worklists with the vendor or integrator. |
| Number of sites | Each site adds network paths, DICOM connectivity tests, local storage and staff training. Inter-site exchange may also need DICOM TLS, which must be configured and verified per link. | Pilot at one site, then repeat the proven runbook. Confirm which sites share a database and which run separate instances. |
| Environments | Development, test, staging and production each need configuration, data subsets and verification runs. Skipping a non-production environment usually moves the work to cutover night. | Use a small, anonymized or approved test subset for rehearsals. Confirm with your privacy office what data may leave production. |
| Compliance evidence needs | Regulators, internal audit and assessors may ask for transfer logs, reconciliation reports, access records and sign-off. Producing this evidence adds documentation and review effort. | Define the evidence list at the start, such as instance counts by source and destination, checksum results and cutover approvals. DeployOpen prepares evidence but does not issue audit reports or certifications. |
Project phases and outputs
The sequence moves a legacy archive into Orthanc in verified stages, so each phase closes with evidence that the next one can rely on.
Assess the source and design the target
We inventory the legacy PACS or archive, including study and instance counts, storage layout, modality and viewer connections, and the DICOM transfer methods it supports. The target design covers the Orthanc database choice, storage backend, plugins and environments. The phase closes with an inventory report and a target architecture document that you approve before any data moves.
Build transfer scripts and run a pilot
We write the transfer tooling for the methods the inventory confirmed and run it against a representative sample of studies chosen with your clinical and imaging owners, covering modalities, transfer syntaxes and edge cases such as incomplete or malformed series. Results are compared against the source. The phase closes with pilot results, a list of defects found and fixes applied, and tested scripts.
Run the full transfer with checksums and counts
We move the complete dataset in controlled batches, recording per-batch study, series and instance counts and checksums on both sides. Failed items are logged and retried rather than silently skipped. The phase closes with a verification reconciliation that lists every difference between source and target and how each was resolved.
Operate in parallel with routing changes
Modalities and viewers are pointed at Orthanc for new studies while the legacy system stays available for reads and fallback. Routing rules, worklist behavior and any duplicate handling are tested and watched during this period. The phase closes when routing has been confirmed for every modality and viewer on your agreed list, with the issues log showing no open routing defects.
Cut over using a written runbook
We execute the cutover from a runbook that sets out the freeze point, final delta transfer, routing switch, rollback steps and named owners for each action. The runbook is rehearsed before the production run. The phase closes with a signed cutover record showing the time of each step and the verification result at the switch.
Verify after cutover and hand over
After the switch we repeat the count and checksum checks against the final state, confirm viewer and modality access, and review logs for failed transfers or access errors. Operating documentation and the support handover are delivered. The phase closes with a post-cutover verification report and an agreed date for retiring or archiving the legacy system.
What usually goes wrong
Most Orthanc migrations from a legacy PACS fail in the handoff rather than in the software itself. The cards below name the failure points we see most often and the checks that catch them before cutover.
Studies lost or duplicated in transfer
Bulk transfers can stop partway, retry without de-duplication, or skip studies that were updated while the job ran. Reconcile the source and target after each batch, and keep a list of every study identifier that failed or was sent twice so each one can be resent deliberately.
Mismatched patient and study identifiers
The legacy archive and Orthanc can normalize patient IDs, issuer of patient ID, accession numbers or name formats differently, so the same patient may appear as two records. Agree the identifier rules with the clinical and HIM owners before the first load, and test them on a sample of known patients.
Character set and private tag loss
Specific character set attributes and vendor private tags can be dropped or rewritten during import, which can corrupt non-Latin patient names and break vendor-specific viewer or reporting features. Compare sampled headers before and after transfer, and confirm which private tags your modalities and viewers depend on.
Transfer syntax changes altering pixel data
Transcoding a compressed image to another transfer syntax changes the stored pixel data, which matters for clinical review, AI inputs and any lossy source. Decide which transfer syntaxes must be preserved as received, configure Orthanc to avoid unplanned transcoding, and verify a checksum or pixel comparison on a sample.
Counts that match at study level only
Study counts can agree while instance counts differ because a series or a few images were missing or split. Reconcile counts at study, series and instance level against the source, and treat any mismatch as a failed batch until the missing objects are traced and resent.
Modalities still sending to the old archive
Scanners and workstations keep a stored AE title and address for the legacy archive, so new studies can continue to land there after cutover. Inventory every modality, worklist consumer and forwarding rule, switch each one in a planned change window, and monitor the legacy archive for inbound traffic during the parallel running period.
SQLite to PostgreSQL moves without a tested restore
Moving the index from SQLite to PostgreSQL is a one-way change in practice, and a backup that was never restored may not work when it is needed. Restore the PostgreSQL backup to a separate host, start Orthanc against it, and confirm study lookups and file retrieval before the production switch.
In-house or partner: who does what
This table compares the migration work your team usually keeps with the work often outsourced, along with the skills each part needs, so you can decide where to draw the line.
| Work area | Usually kept in-house | Often outsourced | Skills required |
|---|---|---|---|
| Clinical sign-off on data scope | Decide which studies, date ranges, patient populations and legacy objects move, and approve the final scope in writing | Prepare inventory counts and reports that show what the legacy PACS holds to support the decision | Clinical IT governance, radiology operations, knowledge of retention rules |
| Network and modality changes | Approve firewall rules, AE title changes and modality reconfiguration windows with your network and biomedical teams | Document the required DICOM endpoints, ports and AE title mappings for each source and target | DICOM networking, firewall administration, biomedical engineering coordination |
| Clinical workflow testing | Run reading, reporting and viewer tests with radiologists and technologists, and sign off on results | Script test cases and checklists that cover C-STORE, C-FIND, C-MOVE and viewer retrieval paths | Radiology workflow knowledge, DICOM conformance testing, test case design |
| Governance and change decisions | Set cutover go or no-go criteria, parallel running duration, rollback authority and access approvals | Draft the decision record and risk register entries that support those governance decisions | Clinical IT governance, information security risk management, change control |
| Transfer tooling | Review and approve the transfer method, rate limits and source system load limits | Build and run the transfer jobs that move studies from the legacy archive into Orthanc | DICOM networking, Linux operations, scripting, familiarity with Orthanc REST API |
| Verification scripts | Confirm which counts and checksums are authoritative for sign-off | Write scripts that compare study, series and instance counts between source and target | Scripting, DICOM data model knowledge, SQL for reconciliation queries |
| Orthanc configuration and PostgreSQL setup | Provide the target database environment, backup policy and storage platform, and approve settings | Configure the Orthanc core, the PostgreSQL plugin and the database schema, and tune storage paths | PostgreSQL administration, Orthanc configuration, Linux operations, backup and restore testing |
| Runbook authoring | Own the operational runbook after handover and approve steps that touch clinical systems | Write migration runbooks covering start, pause, resume, verification and rollback steps | Technical writing, Linux operations, incident response procedures |
How the migration differs by starting point
Most commercial PACS and vendor archives control how studies leave the system. Export limits, licensing terms and vendor-side tooling often decide the transfer method before any engineering starts.
- Transfer method: Plan for DICOM C-MOVE or C-STORE from the source, or a vendor bulk export to disk. Confirm whether bulk export is licensed, throttled or limited per day.
- Verification: Compare study, series and instance counts per modality and per year against the source. Keep a reconciliation list of any studies the export skipped or flagged.
- Cutover: Run both systems in parallel for read access while new studies route to Orthanc, then retire the old route after counts match.
- Confirm with the vendor: Export throughput limits, whether private tags and compressed transfer syntaxes survive export, and the format of any exported metadata.
- Confirm internally: Who owns the license exit terms and the retention obligation for the source archive during overlap.
This path keeps the DICOM data model but moves the index. The work centers on the database change and on checking that the stored files still match the index after the move.
- Transfer method: Usually a database-level migration of the index plus a check of the storage area, rather than a full re-send of images. Confirm the exact Orthanc version before choosing the procedure.
- Verification: Compare the instance count in the SQLite index with the PostgreSQL index and sample-check retrieval of studies from each year.
- Cutover: Stop writes briefly, take a consistent backup of both the index and the storage area, then switch the configuration and restart.
- Confirm with the environment owner: Whether any other Orthanc instance reads the same storage, and the PostgreSQL version and plugin version the platform team supports.
- Plan for: Version compatibility checks and a tested rollback that restores the SQLite configuration.
When studies sit as files on a network share, the main risk is that the files and their metadata drift apart. Import is usually a controlled ingest of files, not a live network transfer.
- Transfer method: Ingest files through Orthanc's import path or a scripted upload, grouped by folder and date so failed batches can be rerun.
- Verification: Count files, DICOM instances and unreadable or non-DICOM files separately. Record checksums for files before and after import.
- Cutover: Freeze the share as read-only during the final delta import, then cut over once the delta count matches.
- Confirm with the storage owner: Snapshot or backup schedules, file permissions for the service account, and whether the share latency is acceptable for retrieval.
- Watch for: Duplicate studies across folders and files that are compressed or damaged in ways that only show on read.
Moving into containers changes where storage, configuration and secrets live. The migration steps stay similar, but persistence and rollout details decide whether the cutover is safe.
- Transfer method: The same DICOM or file ingest methods apply, run from a job or pod with the storage volume mounted. Confirm that the volume is writable and sized for the planned data.
- Verification: Check that the index and storage volume persist across pod restarts before loading production data.
- Cutover: Use a defined route change, such as a DICOM alias or DNS update, and keep the previous endpoint available for rollback.
- Confirm with the platform team: The storage class, backup method for volumes, and whether the database runs inside or outside the cluster.
- Confirm the image source: Which Orthanc image tag and plugin versions your registry mirrors, and how they are pinned.
Isolated networks limit what tools can reach the source and destination. Transfer usually depends on approved media, a DICOM route allowed through a controlled gateway, or a staged relay inside the enclave.
- Transfer method: Choose between direct DICOM over an allowed route, or export to approved media and import inside the destination enclave. Each route needs its own change approval.
- Verification: Hash exported media and record counts on both sides. Repeat the check after every media transfer.
- Cutover: Plan the cutover window with the network team, since routing changes may need a separate approval cycle.
- Confirm with the security owner: Media handling rules, whether transfer tools must be scanned or allow-listed, and logging requirements for the transfer.
- Confirm with the source vendor: Whether the export format can be created and read entirely inside the enclave without outside services.
What the client needs to provide
Before an Orthanc migration starts, the client must supply the inputs that the plan depends on. The first is read access, or export rights, to the legacy PACS or archive. Confirm with the vendor or your PACS administrator whether studies can be exported as DICOM over C-STORE or through a bulk export tool, and whether the source keeps data in a form that can be read without the original application. Also ask who can approve a temporary service account on the source and for how long it stays active.
The client also provides a representative sample dataset for the pilot, covering several modalities, transfer syntaxes and institutions if you receive them. Name the network paths the migration will use between the source, Orthanc and any modalities, and have your network team identify the firewall rules and DICOM port changes needed. Confirm whether the target environment, including its operating system, database host, storage, backup and monitoring, meets your infrastructure standards before the build begins, since that decision affects every later phase.
Decisions and named people matter as much as systems. Assign owners for clinical sign-off on the pilot results and for modality and worklist changes, because a migration that moves images but leaves modalities pointing at the old archive will fail at cutover. Decide which studies migrate: all of them, only active patients, or studies within a date range. Record retention rules and access rules for the archive, including who may view, export or delete studies, so the authorization design can be built to match.
Finally, ask your compliance lead which evidence the assessors will expect for the migration, such as records of transfer counts, access decisions and retention settings. DeployOpen does not issue audit reports or attestations. It can prepare the system documentation, configuration records and verification evidence that your independent auditor or certification body reviews, but the scope of that evidence should be agreed in writing before the migration plan is signed off.
Frequently asked questions
What drives the cost of an Orthanc migration from a legacy PACS?
The main cost drivers are the number of studies and instances to move, the export options the legacy system offers, how many modalities and sites must be re-pointed, and how much metadata cleanup the data needs. Orthanc has no paid edition, so the quote pays for people and services, not a software license. Ask for one-time costs (scoping, mapping, transfer runs, verification and cutover) shown separately from recurring costs such as hosting, storage growth and any support hours. DeployOpen works to a fixed scope agreed in writing before work starts, and the quote follows from that scope.
How long does an Orthanc migration from a legacy PACS take?
The timeline depends on the scope written into the quote, so there is no general figure to rely on. The variables that matter most are data volume, the throughput of the legacy system's export, how long parallel running must last for your clinical teams, and how many interfaces must change at cutover. Ask for the schedule broken into phases with dependencies named, and ask how the plan handles a missed transfer window or a failed verification step.
Can our own team migrate imaging studies to Orthanc without a partner?
Yes, a capable team can run the migration without an outside partner, because the Orthanc core is open source under GPLv3 or later. The harder work is planning: confirming what the legacy PACS can export, how each modality will send to the new server, and how results will be checked. Your staff will need imaging IT, DICOM networking and database skills, plus clinical time for sign-off during parallel running. Ask a partner to confirm which of these skills you lack before you decide.
Is moving Orthanc from SQLite to PostgreSQL a separate project?
It can be, and it should be decided during planning. The Orthanc Book says the built-in SQLite index should be replaced by an enterprise database once a store holds several hundred thousand DICOM instances, and it recommends the PostgreSQL plugin for large datasets. If you are loading a legacy archive into a new Orthanc, choosing PostgreSQL from the start avoids a second migration. An existing SQLite-backed Orthanc needs its own move, with schema changes, backups and restore tests planned separately.
How do we prove that every migrated study arrived intact?
Verification compares counts and identifiers between source and target at defined checkpoints, covering patients, studies, series and instances. Where the plan calls for it, it also includes checksums or sampled image comparisons. Reconciliation reports list every gap, and each gap is either resolved or accepted in writing before cutover. Keep these reports as evidence. DeployOpen prepares the systems, controls and evidence, but independent auditors and certification bodies decide whether they meet your compliance requirements.
What happens to the old PACS archive after cutover to Orthanc?
The old archive is usually kept read-only for an agreed fallback and retrieval period after cutover, then retired under your records policy. Decide before cutover whether the legacy PACS stays reachable, how older studies will be served, and who approves final deletion. Source data should not be removed until verification reports are signed off and backups of both systems have been tested. Retention duties come from your own regulations and policies, so confirm them with your compliance lead before the plan is fixed.
How DeployOpen works on Orthanc migrations
DeployOpen plans and carries out Orthanc migrations from a legacy PACS inside your own infrastructure, from written scope through cutover and ongoing support. The work follows a fixed scope agreed in writing before any migration begins.
How we scope
- We inventory the source PACS or archive, its modalities, DICOM transfer methods and study volumes before naming a target.
- The written scope states which studies move, which transfer methods are used and how migrated counts will be verified.
- We agree the database choice, SQLite or PostgreSQL, and the storage location, since both affect the migration plan and quote.
- We confirm parallel running, cutover windows and rollback conditions with your clinical and IT owners in the scope document.
How we build
- We stand up Orthanc in non-production environments, with the plugins your workflow needs, configured for your network.
- We move a representative sample of studies first and compare instance and study counts between source and target.
- We test the chosen DICOM transfer method and the modality connections against real modality settings in a controlled window.
- We run parallel reads and writes as agreed, then execute the cutover plan with documented checkpoints and a rollback path.
How we hand over
- You receive the configuration, deployment records and runbooks for the Orthanc instance and its database in your environment.
- You receive verification reports that show source and target counts, failed transfers and how each exception was resolved.
- We document the cutover steps, backup and restore procedures and the access settings applied to the server.
- We walk your operations staff through daily checks, alerts and the steps for escalating an issue after handover.
How we support
- Engagements are fixed-scope, and support after handover is agreed as a separate written item.
- Ongoing support, upgrades and testing are available as a retainer, scoped to your Orthanc version and plugin set.
- Before any Orthanc upgrade, we review release notes and test database and plugin changes in a copy of your environment.
- Ask for the support response expectations, upgrade cadence and who holds on-call duties in your quote before signing.
