Router-pattern host · Migration Multi-petabyte archive-to-archive migration. Multi-source ingestion from any DICOM-conformant PACS or VNA, per-study cryptographic verification, scheduled migration windows that respect your clinical operations, in-flight tag transformation for legacy-data cleanup, and the audit trail a regulated migration demands.
Capabilities
A migration platform earns its keep over months, not minutes. Per-study verification, pause/resume, scheduled windows, stakeholder reporting — the capabilities below are the ones that distinguish a real migration tool from a clever cron script.
Read from any DICOM-conformant source — and from non-DICOM exports too.
For migrations >100 TB, deploy Migration Engine as a horizontal pre-processor in front of VNA Migration. Cheap edge work happens at the front-end, freeing VNA Migration to focus on verification and audit.
Cryptographic proof that every migrated study matches the source. The defense against silent data loss in long-running migrations.
Multi-month migrations can't run at maximum throughput 24x7. Schedule the work to fit your operational windows.
Migrations are the moment to clean up legacy data — wrong-patient corrections, scheme changes, AE-Title remappings, deprecated vendor tags.
Multi-month migrations with stakeholders need accountable progress visibility — not just a CLI percent counter.
Same shared admin shell as the rest of the XyDromatics family.
Architecture
A migration is fundamentally a three-actor system: a source archive being read, a target archive being written, and the migration host orchestrating the transfer with verification on every study.
The migration host can run multiple parallel worker processes for large migrations; the source-host throttling and target-host rate limits keep the overall move bounded by whichever side is slower. Quarantine queue volume is a meaningful health metric — a clean source rarely produces more than 0.01% quarantine rate.
On large engagements, the recommended deployment is the packaged pattern shown above: Migration Engine sits in front of VNA Migration, normalizing character sets and coercing common tag misalignments at the edge so VNA Migration sees clean data. Migration Engines scale horizontally to parallelize source-side reads cheaply; VNA Migration then spends its CPU on the per-study verification and hash-chain audit work that actually matters. Net throughput increases meaningfully on sources with heavy syntactic baggage.
Common use cases
Most engagements combine two or three of these — vendor consolidation paired with cloud migration, or legacy retirement followed by a compliance export of the final state.
The classic shape: an aging PACS with 10-20 years of accumulated data, a contracted end-of-support date, and a target VNA waiting to receive everything. Months of careful migration with verification at every study.
Flow
Health-system mergers leave you with 3-5 different PACS / VNA platforms. Consolidate to one target archive — typically a clean greenfield VNA Repository, but any DICOM-conformant target works.
Flow
A healthcare-system acquisition or hospital purchase comes with imaging archives whose ownership transitions on a deal-close date. Migrate the historical record while preserving full audit chain for the regulatory paper trail.
Flow
On-prem archive to cloud-native archive (or vice versa). Different storage substrate; same migration mechanics with bandwidth-aware scheduling for the WAN crossing.
Flow
A legal-hold or regulatory request demands extraction of a defined study set. Use Migration as a one-way export tool — same verification rigor, different scope.
Flow
Integration points
A migration platform lives or dies by the breadth of source systems it can read from. Anything DICOM-conformant works; the lists below highlight the systems we’ve worked with most often, organized by clinical specialty.
Every vendor product on these lists is a system Synthology principals have implemented, supported, or migrated from — not a vendor-research summary. Imaging is broader than radiology; cardiology, pathology, mammography, and ophthalmology all carry their own PACS / CVIS / image-management product lineages, often with 3–5 generations of products in deployment today. If your source isn’t on the lists, ask — as long as it speaks DICOM (or exports a sensible filesystem tree), we’ve probably worked with something close to it.
System requirements & sizing
Migration sizing factors in the total source volume, the desired throughput per day, and the source-system constraints (Q/R rate limits, network bandwidth, off-peak windows). Realistic forecasting comes out of discovery.
| Tier | Source size | Throughput | CPU | RAM | Typical engagement |
|---|---|---|---|---|---|
| Small migration | < 100 TB source | < 5 TB / day | 8 vCPU | 32 GB | Single-PACS retirement at a community hospital. 1-3 month runway. |
| Medium migration | 100 TB – 1 PB | 5 – 25 TB / day | 16 vCPU | 64 GB | Multi-site PACS migration or vendor consolidation. 6-12 month runway. |
| Large migration | 1 PB – 10 PB | 25 – 100 TB / day | 32 vCPU + parallel workers | 128 GB | Health-system VNA replacement, cloud migration. 12-18 month runway. |
| Enterprise migration | > 10 PB | > 100 TB / day | Multiple worker nodes, 64+ vCPU each | 256+ GB per node | IDN-scale consolidation. 18-36 month runway with phased cutovers. |
Full hardware/software requirements are in DOC-2026-059 (HW/SW Requirements), available under NDA. Includes OS support matrix, source-system compatibility matrix, network requirements, and parallel-worker deployment patterns.
Licensing
Core handles small-scale migrations with verification. Transform adds in-flight tag rewriting and quarantine workflow. Enterprise unlocks parallel workers, anonymization, and stakeholder reporting for multi-petabyte engagements.
The base migration platform — DICOM source/target, per-study verification, basic scheduling.
Adds in-flight tag transformation, per-source rules, and quarantine workflow.
Everything, plus parallel worker nodes, anonymization profiles, and stakeholder reporting.
Migration licensing is typically project-scoped (fixed migration volume + window) rather than perpetual — you license the platform for the duration of the migration, with the option to retain it for follow-on cleanups or compliance exports. Specific pricing in your engagement SOW.
Documentation
Every VNA Migration deployment ships with the documents below, all managed under SynthQMS document control. The DICOM Conformance Statement is publicly available; the rest are shared under mutual NDA.
| Document | Title | Notes |
|---|---|---|
| DOC-2026-129 | Hardware & Software Requirements (VNA Migration) | Sizing, OS support, dependencies |
| DOC-2026-139 | DICOM Conformance Statement (VNA Migration) | Public — full SOP class + transfer-syntax matrix |
| DOC-2026-134 | EULA Annex (VNA Migration) | Annex to the Synthology Master EULA (DOC-2026-063) |
| DOC-2026-149 | Penetration Test Results (VNA Migration) | Available under NDA |
| DOC-2026-144 | QA Runner Manual (VNA Migration) | Internal QA + customer-validated test runs |
| DOC-2026-160 | User Guide (VNA Migration) | Operator + administrator workflows |
| DOC-2026-165 | Installation Guide (VNA Migration) | Includes MSI deploy + Linux tarball install |
Frequently asked
Different scale and different shape -- but they're often deployed together. VNA Migration is the multi-petabyte archive-to-archive workhorse: full HA, parallel worker nodes, multi-month migration plans, per-study verification, transformation, and hash-chain audit. Migration Engine is the smaller-footprint standalone appliance -- right-sized for short-lived migration projects (50-100 GB modality cleanups, single-site cutovers) AND, increasingly, for use as a horizontally-scaled normalization / tag-coercion front-end in front of VNA Migration on large engagements. Same family, complementary roles.
Generally for migrations larger than ~100 TB, or where the source archive is known to have heavy character-set / malformed-header / non-spec-VR baggage that's going to cause retries during verification. Deploying Migration Engine as a front-end means you can parallelize source-side reads on cheap compute (multiple Migration Engine workers) and clean up the common syntactic issues at the edge before VNA Migration spends its CPU on verification + audit-trail work. Net effect is meaningfully higher overall throughput. Packaged deployments are quoted as a single SOW; the discovery phase will tell you whether the front-end is worth it for your specific source archive.
The Router can route studies between archives — that's a common pattern for parallel-run migrations during a PACS cutover window. But the Router's job is real-time routing of live clinical traffic, not bulk historical migration with verification. VNA Migration is purpose-built for the bulk historical use case: per-study verification, pause/resume, scheduled windows, stakeholder reporting. Use both together during a cutover (Router for new traffic, Migration for historical) and the patterns reinforce each other.
Highly dependent on source PACS and network. Conservative targets: 5-10 TB/day per worker node against a typical legacy PACS Q/R interface. Modern source systems with STOW-RS or filesystem export can reach 50+ TB/day per worker. Multi-worker deployments scale roughly linearly until you hit source-side throttling. Discovery phase produces the realistic forecast specific to your sources.
Routes to the quarantine queue. Common causes: corrupted pixel data on the source, malformed DICOM headers (legacy systems sometimes wrote non-spec-compliant data), or character-set encoding bugs. Each quarantined study is individually adjudicated -- clinical review decides repair, skip, or escalate. The audit trail captures every decision. Silently dropping studies is never the default.
Yes -- this is the standard pattern. Source-side reads happen in scheduled off-peak windows (typically nights + weekends). Bandwidth caps prevent the migration from saturating your network or source-PACS load. The Router can be configured to send new clinical traffic to the target archive during the migration window, so by cutover day the target already has both the live recent data and the historical migrated data.
Per-study record: source SOP Instance UID + source-side hash + target SOP Instance UID + target-side hash + timestamp + operator identity + any transformation applied. Hash-chain audit log covers the entire migration from start to finish. Independent re-verification tool can re-walk the chain at any point. The audit trail is the deliverable -- not just the migration itself.
Three layers. First: count reconciliation -- source study count vs target study count vs quarantine count, with named-reason buckets for any difference. Second: hash verification -- random sample of studies re-verified at target. Third: clinical-spot-check -- radiologist team picks studies and confirms diagnostic-quality match against source. All three are part of the standard closeout package.
Non-device software under FD&C Act §520(o)(1)(D), the 21st Century Cures Act §3060 carve-out for software that transfers, stores, converts, or displays device data without interpreting or analyzing it. No FDA Device Listing required. Same framework as VNA Repository -- VNA Migration handles storage and forwarding without modifying clinical interpretation. Tag transformation in flight is constrained to non-interpretive changes (anonymization, AE-Title remapping, etc.); clinical-tag-edit (changing PatientName, AccessionNumber, etc.) is exclusively in VNA Clinical. Every Synthology product, VNA Clinical included, is non-device software under FD&C Act §520(o)(1)(D).
Tell us your source archive, target archive, total volume, and target cutover date. We’ll come back within one business day with a discovery proposal and a realistic-not-marketing forecast for the migration window.