Whitepaper · The Migration Suite

A vendor-neutral accelerator, and a complete path for legacy-PACS retirement

Retiring a legacy PACS is two problems at once: moving the data, and not disrupting the clinical reads still happening on the source archive while you move it. The Migration Suite addresses both — and is designed to be adopted incrementally: start with a single product that complements a migration tool you already own, and expand to a complete, single-vendor workflow if and when you want it.

Migration Engine can front the legacy source as a standards-based DICOM Query/Retrieve provider, so any migration server — Synthology’s own, or a third party’s — can point at it and take query load off the live production PACS. When you want the migration itself from Synthology, VNA Migration normalizes, de-duplicates, remediates, and quality-gates every study; and both engines report PHI-free counts to SynthInSight for one view of the whole migration.

This paper describes architecture and behavior, not performance. Synthology publishes no throughput or “N× faster” figures for the Suite — they depend on your source PACS, network, and study mix. Where a capability is licensed or off by default, this paper says so; see “What we do not claim.”

Book a demo Suite overview

The problem

A migration competes with clinical work

A legacy-PACS retirement runs for weeks or months, and for most of that time the legacy archive is still the system of record for clinical reads. A migration tool that queries and pulls directly from that live archive competes with radiologists for the same connections and the same I/O. The usual mitigations — throttling the migration, running it only overnight — trade migration duration against clinical impact, and neither removes the coupling.

Two more problems travel with it. Bit-for-bit copying produces a worse archive — it moves the legacy archive’s accumulated problems (duplicate studies, tag inconsistencies from years of different modalities and HL7 feeds) straight into the new one. And nobody can see the whole migration: when more than one tool is involved, there is no single, consistent view of how many studies have moved, failed, or been skipped — and building one usually means exporting logs that carry PHI. The Migration Suite is organized around these three: offload the live source, clean the data in transit, and see the whole thing without moving PHI.

Dataflow

Legacy PACS to net-new PACS, end to end

The suite sits between the old and new estates. Migration Engine takes the query load off the live production archive; VNA Migration cleans and gates every study on the way through; SynthInSight gives the program one PHI-free view of progress.

A print version — the Migration Suite poster — is available as an 11×17 tabloid PDF on the posters page.

Migration Engine

The vendor-neutral accelerator

Migration Engine is a standalone, non-device data-mover. Its defining capability for a migration is to front the legacy source(s) so a migration server you already own can treat it as a single source PACS — taking query load off the live production archive. We state the protocol scope and configuration it requires up front, because a migration architect needs them to design the cutover.

A federating DICOM Query/Retrieve provider

With the federation feature licensed and enabled, Migration Engine presents one DICOM Q/R endpoint that fronts N legacy source PACS. A downstream client — a third-party migration server, or Synthology’s own VNA Migration — issues a single C-FIND and Migration Engine fans it across every configured source concurrently, returning a single, de-duplicated, merged study list (matched by Study Instance UID) tagging each result with which source holds it. On C-MOVE it retrieves the study from the holder and delivers it to the requested destination. The federation is verified end-to-end by an automated real-host wire test.

What it requires (stated plainly)

This is a licensed capability (federated_qr) and is off by default. The provider speaks C-FIND and C-MOVE (plus C-ECHO and Modality Worklist) — it does not offer C-GET to downstream clients. Because retrieval is buffered (store-and-forward), the C-MOVE destination a client names must be known to Migration Engine — either its own receiving endpoint or a destination PACS the operator has registered as a target; an unregistered destination is staged but not forwarded. This is a one-time configuration, not a per-study action. Federation members are DICOM (DIMSE) query sources.

DICOMweb sources

Migration Engine works with DICOMweb archives two ways. For end-to-end jobs (dicom_web_source) it queries a source over QIDO-RS and retrieves over WADO-RS, then forwards to the target — full QIDO+WADO. For federated multi-source query (federated_dicomweb) a QIDO-RS archive can join the federated C-FIND fan-out so its studies merge into the same unified result (aligned with IHE XCA-I); this path is query-only.

Scale controls

Parallel retrieval (parallel_cmove) migrates multiple studies concurrently via a configurable worker pool; without it the engine runs one study at a time. Rate limiting (rate_limiting) applies per-source and global throttles — a requests-per-second cap and a megabytes-per-second cap — to protect an older source PACS and the downstream target during a large migration; enforcement is verified on the running product by an in-process self-test. These are capability and enforcement facts, not benchmarked speedups.

In transit

What Migration Engine does on the way through

These behaviors are independent of the downstream tool — they apply whether the studies land in VNA Migration or a third-party migration server.

Query the source once, then forward from a buffer

Migration Engine uses a store-and-forward model: each study is retrieved from the source once per successful retrieval into local staging, then forwarded to the destination from that buffer. The write leg to the destination never reaches back to the legacy source — so the legacy archive answers the migration once per study and is otherwise left alone.

Optional lossless transcoding

On the federated buffered path, Migration Engine can losslessly transcode each study’s images to an operator-chosen transfer syntax (transcode_target_ts, opt-in and licensed). Permitted targets are lossless only — JPEG Lossless, JPEG 2000 Lossless, and the uncompressed syntaxes. It is fail-closed: a missing codec or a non-lossless target aborts that instance rather than forwarding it incorrectly. Non-image objects pass through unchanged. It never alters image content and is never lossy.

Data transforms before forwarding

Migration Engine can apply operator-authored data transforms to each instance just before forwarding (data_transforms): tag transformations (add, modify, copy, regex-replace, or delete tags by pre-authored rules) and normalization (the PS3.x-conformance policy sweeps described under VNA Migration). Rules use the same shared model and algorithm as XyDromatics Router. An edit to a clinical-meaning tag is not blocked; it is recorded with an “advisory” flag on the audit trail. With no rules configured, the step is a no-op.

Skip re-sending — not re-pulling

Before forwarding a study, Migration Engine asks the target which SOP Instances it already holds and forwards only the missing ones (on by default; if the target can’t be queried, the full study is forwarded). Separately, an optional analysis (dedup_against_target, off by default) inventories the source and reports target overlap for planning. What it does NOT do: it does not skip pulling a study from the source because the target appears to already have it — a study is always fully retrieved from the source; only re-forwarding of already-present instances is avoided.

VNA Migration

The migration server

When you want the migration itself from Synthology, VNA Migration is the migration server. It moves imaging over standard DICOM networking, and it co-hosts its own vendor-neutral archive, so migrated studies land in an archive it controls. Its ingest pipeline cleans and gates every study, in this order:

De-duplication (on by default)

Before each retrieval, an idempotent pre-flight skips a study already present in the migration target (or narrows to an image-level top-up of only the missing instances), keyed on Study Instance UID and judged by comparing instance counts. On by default, bypassable per-batch or per-source, and fail-safe — if the source doesn’t report a count or the archive is unavailable, it falls through to a full retrieval and never deletes anything. This is a study-level skip by UID and counts, not a byte- or hash-level de-duplication.

Normalization — first in the ingest chain

A dedicated DICOM Normalization Engine runs first in the ingest pipeline, so validation, tag remediation, and quality gates all operate on PS3.x-compliant input. It is a set of canned, toggleable conformance policies (not free-hand editing): trim/collapse whitespace, canonicalize dates and times, regenerate malformed UIDs and UID hygiene, strip private tags, force UTF-8, normalize Patient Name caret delimiters, file-meta sanity, SOP-class consistency, and VR-length compliance (report or truncate). Policies group into presets (off / baseline / strict / custom) and are configurable and off unless enabled. This keeps years of accumulated legacy non-conformance from being copied verbatim into the net-new archive.

Tag remediation by pre-authored rules

Operator-authored, priority-ordered rules with nine condition operators and eight actions — set (can add an absent tag), copy, prepend, append, regex-replace, clear (null a value), lookup, and delete. Rules are pre-authored and persisted (a preset specification applied deterministically on ingest), not hand-editing at apply time. The engine can write any tag, including clinical-meaning tags; such an edit is not blocked — it is flagged “advisory” on the audit record. With no rules configured, remediation is a no-op.

Configurable quality gates + rejection queue

The ingest pipeline includes DICOM validation, missing-data derivation, and configurable quality gates (required / not-empty / min-length / regex / value-in / conditional-not-blank), backed by a rejection queue. When enabled, an instance that fails a reject-policy rule is diverted to the rejection queue (bytes + metadata retained) for operator triage and one-click re-feed. These are per-instance metadata/conformance checks, rule-driven — with nothing configured, nothing is gated.

Automatic post-migration reconciliation

When every job in a batch reaches a terminal state, a background service reconciles automatically: for each completed study it C-FINDs the source and compares the source’s series/instance counts against the migration archive, classifying each study as matched, partial, missing, source-extras, or source-unreachable, and persisting per-study results plus a per-batch summary. An opt-in setting can auto-requeue partial/missing studies. The comparison is count-based against VNA Migration’s own archive.

Two reference architectures

Adopt one product, or the whole workflow

Migration Engine + a third-party migration server

Keep your existing migration tool and point it at Migration Engine as its source, to offload the live PACS and (optionally) condition studies in transit. The incremental, single-product entry point.

The full Suite

Migration Engine fronts the source; VNA Migration is the migration server; SynthInSight is the analytics view. One vendor, one workflow. Each product ships and is licensed independently — the Suite is a commercial bundle, not a fused binary.

Analytics

One PHI-free view of the whole migration

Both Migration Engine and VNA Migration write one aggregate row per completed migration job to a shared feed that SynthInSight reads as a single, cross-product “Migration Suite” view — product, instance, source, modality, status, and channel are its breakdown dimensions. The feed is PHI-free by construction: each row records only counts and non-identifying topology (product, instance, timestamp, source, modality, status, channel, images, bytes, duration, attempts, first-pass, skipped) — there is no field capable of holding a patient name, patient ID, Study Instance UID, accession number, or free-text note.

The per-patient / which-study detail stays in each product’s own on-premise store, behind its PHI-reveal control. Only the de-identified aggregate rows reach SynthInSight, which is general-purpose business software — it handles counts, not images, and is not a medical device.

Honesty

What we do not claim

In the interest of an accurate evaluation, here are the boundaries:

No performance figures. This paper makes no throughput, studies-per-hour, “N× faster,” or “reduces load by N%” claim — those depend on the customer environment.
Migration Engine does not skip pulling studies already at the target. It reports overlap and avoids re-sending instances the destination already has; it does not suppress retrieval from the source.
De-duplication is study-level, by UID and counts — not byte-level or hash-verified.
Reconciliation is count-based against VNA Migration’s own archive — not a per-image hash comparison.
Transcoding is lossless only — never lossy, never “compression” in a sense that implies data loss.
The federated Q/R proxy and several conditioning features are licensed and off by default — real, shipped capabilities, but explicitly enabled and configured, not automatic.

Regulatory & privacy posture

Non-device software; analytics is a business tool

XyDromatics Migration Engine and XyDromatics VNA Migration are non-device software under FD&C Act §520(o)(1)(D) — they transfer, store, convert, and display medical device data without clinical interpretation. Neither is a medical device.

SynthInSight is general-purpose business software — fleet operational analytics. It is not a medical device, has no clinical function, and handles no PHI (aggregate counts only). PHI stays on the on-premise image path; only de-identified aggregate counts reach SynthInSight, and the shared feed has no field capable of carrying a patient, study, or accession identifier.

Planning a legacy-PACS retirement?

Whether you want the full Suite or just Migration Engine in front of your existing migration server, tell us about your source PACS and your net-new destination and we’ll come back with a proposed architecture.

Request a demo Suite overview