Router-pattern host · Migration

# XyDromatics VNA Migration — archive-to-archive at scale.

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

### Built for multi-petabyte migrations.

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.

### Multi-source ingestion

Read from any DICOM-conformant source — and from non-DICOM exports too.

- C-STORE SCU (push from source PACS) + SCP (pull to migration host)
- Q/R against the source archive (C-FIND + C-MOVE / C-GET)
- STOW-RS for modern HTTP-based source systems
- File-watcher ingest for offline / disconnected sources
- Bulk DICOMDIR + filesystem-walk for raw exports
- Configurable concurrency + rate limits per source

### Migration Engine front-end (recommended pattern)

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.

- Normalization at the edge — character sets, malformed headers, deprecated tag VR mismatches, non-spec timestamp formats
- Tag coercion — force common values into expected formats (accession-number padding, date-string normalization, VR coercion) before they reach VNA Migration
- Horizontal scaling — multiple Migration Engine workers parallelize source-side reads
- Quarantine fixable issues at front-end so VNA Migration sees clean data
- Net effect: higher overall throughput by reducing retry / error-handling load on the audit-heavy VNA Migration host

### Per-study verification

Cryptographic proof that every migrated study matches the source. The defense against silent data loss in long-running migrations.

- SHA-256 checksum captured at source-side extract
- Re-verified at target-side ingest before commit
- Mismatches route to a quarantine queue for clinical review
- Full per-study audit record: source UID, target UID, hash pair, timestamp

### Pause / resume + scheduling

Multi-month migrations can't run at maximum throughput 24x7. Schedule the work to fit your operational windows.

- Pause / resume at any point with full state checkpointing
- Scheduled migration windows (off-peak only, weekends only, etc.)
- Per-source bandwidth caps and priority queues

### In-flight tag transformation

Migrations are the moment to clean up legacy data — wrong-patient corrections, scheme changes, AE-Title remappings, deprecated vendor tags.

- Tag-level rewrite (set / unset / map values) per study
- Per-source transformation rules (different legacy systems, different cleanup needs)

### Progress reporting

Multi-month migrations with stakeholders need accountable progress visibility — not just a CLI percent counter.

- Real-time dashboard — studies/hour, bytes/hour, ETA per source
- Per-source + per-modality + per-date-range breakdown

## Architecture

### Source · Migration · Target.

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.

Source archive Legacy PACS / VNA Filesystem export Q/R · C-STORE · STOW-RS

## Common use cases

### Five patterns that cover most migrations.

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.

Pattern 1: Legacy PACS retirement

### Flow

1. Source: legacy PACS via Q/R or filesystem export
2. Migration plan: per-modality, per-date-range, prioritized by clinical relevance
3. Run in scheduled off-peak windows so source PACS isn't impacted

## System requirements & sizing

| 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. |

### Licensing

### Migration Core

The base migration platform — DICOM source/target, per-study verification, basic scheduling.

- C-STORE / Q/R / STOW-RS source + target
- Per-study SHA-256 verification
- Basic scheduling (off-peak windows)

### Documentation

| Document | Title | Notes |
| --- | --- | --- |
| DOC-2026-059 | Hardware & Software Requirements (VNA) | Sizing, OS support, source-system compatibility matrix |
| DOC-2026-141 | DICOM Conformance Statement (VNA Migration) | Public — full SOP class + transfer-syntax matrix |
| DOC-2026-065 | EULA Annex (VNA) | Annex to the Synthology Master EULA (DOC-2026-063) |

## Frequently asked

### How is VNA Migration different from Migration Engine?

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.

### What's the audit trail?

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.

## Talk through your migration.

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.