Specialized engine · Universal pre-processor The right-sized migration appliance — and the universal pre-processor for any migration project. Use it standalone for small / medium migrations, in front of VNA Migration for large engagements, or as a normalization + tag-coercion layer in front of third-party migration tools (DataFirst, Laurel Bridge, DicomSys, or a customer’s incumbent platform). Migration Engine doesn’t care who’s doing the actual migration delivery.
Same family-platform features as the rest of the router- pattern hosts — keyed-hash pseudonymization, built-in honest-broker capability, shared site encryption key when deployed alongside other Synthology products.
Capabilities
Migration Engine focuses on the syntactic cleanup that makes downstream verification, transformation, and audit faster — regardless of who’s doing the downstream work.
Read from any DICOM-conformant source, plus filesystem and HL7-driven inputs. Same source-system breadth as VNA Migration in a smaller footprint.
The cheap, parallelizable cleanup work that makes downstream verification + audit faster. Run multiple Migration Engine workers; let downstream tools focus on their actual jobs.
Force common tag values into the formats downstream systems expect — without changing the value semantics. Distinct from VNA Migration's audit-heavy tag transformation.
A standalone migration appliance has to manage its own pacing. Operator-controlled start/pause, retry policies, and dead-letter handling.
Migration Engine doesn't care who's doing the actual migration delivery. Normalize and coerce upstream of any target platform — Synthology or third-party.
Same platform features as the rest of the router-pattern family.
Architecture
The architectural shape is deliberately flexible — Migration Engine sits between source and target, and the target can be any migration platform (Synthology, third-party, customer- incumbent) or a final archive directly.
Deployment patterns
Customers use Migration Engine in multiple complementary patterns. Standalone for small projects, front-end for VNA Migration on large engagements, front-end for third-party tools where the customer has an incumbent platform, modality- side cleanup as a permanent fix.
A bounded migration project — single source PACS, one or two target archives, weeks-to-months runway. Migration Engine handles the full move: read source, normalize, coerce, send to target. No need for the multi-petabyte VNA Migration heavyweight.
Flow
Large multi-petabyte migrations benefit from horizontal pre-processing. Multiple Migration Engine workers normalize + coerce in parallel; clean data flows into VNA Migration which focuses on per-study verification, full tag transformation, and hash-chain audit.
Flow
IES-Advisors engagements using DataFirst as the migration platform can layer Migration Engine in front to handle the syntactic cleanup that DataFirst doesn't natively do — character sets, malformed headers, deprecated VRs. Migration Engine cleans; DataFirst delivers.
Flow
Customer has an existing migration tool (Laurel Bridge Compass, DicomSys UVR, or another vendor's platform) and wants to add Migration Engine as a normalization + coercion layer to improve migration throughput and reduce retry / quarantine volume on their existing tool.
Flow
A single modality (or a small group) emits chronically malformed DICOM that downstream PACS struggles with. Migration Engine sits in front of the PACS as a permanent cleanup layer — turning bad-data emission into an architecture problem rather than a daily ops headache.
Flow
Same family-wide round-trip pattern as the Router and the VNA siblings. Migration Engine de-identifies via keyed-hash on the way out, AI vendor analyzes anonymized data, findings come back, Migration Engine re-identifies and routes findings to the correct downstream destination.
Flow
Integration points
Migration Engine’s third-party-target list is what makes it vendor-agnostic. Customers running an incumbent migration platform don’t have to choose between replacing it and skipping the cleanup benefits — Migration Engine slots in upstream of any DICOM-conformant target.
System requirements & sizing
Migration Engine workers scale linearly until source-side throttling becomes the bottleneck. Add workers; throughput adds. Sizing is per-worker.
| Tier | Workload | CPU | RAM | Notes |
|---|---|---|---|---|
| Worker (single) | 1 – 5 TB / day throughput | 4 vCPU | 8 GB | Standalone single-site migration. Modality-side cleanup. Single front-end worker for medium VNA Migration engagements. |
| Worker pair (2 workers) | 5 – 15 TB / day aggregate | 4 vCPU per worker | 8 GB per worker | Larger standalone migrations, or 2-worker front-end for VNA Migration / third-party tools. |
| Worker cluster (4+ workers) | 15+ TB / day aggregate | 8 vCPU per worker | 16 GB per worker | Multi-petabyte migrations as VNA Migration front-end, or large-scale standalone consolidation. |
Licensing
Migration Engine licensing fits both project shapes: short-engagement migrations (project-scoped) and ongoing modality-cleanup deployments (perpetual). Tier choice depends on the breadth of coercion needs and whether AI-vendor PHI shielding is required.
The base appliance — multi-source ingest, normalization, basic forwarding. Suited for standalone small / medium migrations.
Adds full per-source coercion profiles, vendor-quirk handling, and HL7 / MWL-driven ingest.
Everything, plus parallel worker deployment, AI-vendor PHI shielding, and family-platform features.
Project-scoped licensing for short-engagement migrations; perpetual licensing for ongoing modality-cleanup deployments. Multi-product bundles (Migration Engine + VNA Migration, or Migration Engine + Router + VNA family) get bundle pricing and shared site-key provisioning.
Documentation
Current GA release v1.0.3.179 · released 2026-08-06
Every Migration Engine 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.
Scheduled Migration — keep a source and target continuously in sync
| Document | Title | Notes |
|---|---|---|
| DOC-2026-103 | Hardware & Software Requirements (Migration Engine) | Sizing, OS support, dependencies |
| DOC-2026-099 | DICOM Conformance Statement (Migration Engine) | Public — full SOP class + transfer-syntax matrix |
| DOC-2026-106 | EULA Annex (Migration Engine) | Annex to the Synthology Master EULA (DOC-2026-063) |
| DOC-2026-098 | Penetration Test Results (Migration Engine) | Available under NDA |
| DOC-2026-108 | QA Runner Manual (Migration Engine) | Internal QA + customer-validated test runs |
| DOC-2026-105 | User Guide (Migration Engine) | Operator + administrator workflows |
| DOC-2026-104 | Installation Guide (Migration Engine) | Includes MSI deploy + Linux tarball + multi-worker pattern |
Migration Engine-specific documents beyond the standard set. Items marked Pending are tracked for authoring under SynthQMS change control.
| Document | Title | Notes |
|---|---|---|
| DOC-2026-400 | Vendor-Quirk Profile Catalog (Migration Engine) | Per-vendor known-quirk profiles maintained as living documentation |
Frequently asked
Different scale and different shape -- but they're often deployed together. Migration Engine is the smaller-footprint appliance: standalone for small / medium migrations, or as a horizontal pre-processor in front of VNA Migration on large engagements. VNA Migration is the multi-petabyte workhorse with full HA, parallel worker nodes, multi-month migration plans, full per-study verification, transformation, and hash-chain audit. Same family, complementary roles.
No. Migration Engine is fully standalone-licensable. Many customers buy it on its own for small / medium migration projects, modality-side cleanup, or as a pre-processor for their existing third-party migration platform (DataFirst, Laurel Bridge, DicomSys, etc.). No other Synthology product required. If the customer later adds Router / VNA family / SR Engine, the products inherit the same site encryption key for cross-product anon-ID consistency.
Yes -- this is one of its core value propositions. Migration Engine doesn't care who's doing the actual migration delivery. Insert it upstream of DataFirst (via IES-Advisors), Laurel Bridge Compass / Navigator, DicomSys UVR, or any customer-incumbent migration platform. Migration Engine normalizes character sets and malformed headers, coerces common tag misalignments, and hands clean data to whatever platform is doing the actual move. Net effect: higher throughput, fewer retries, less quarantine queue volume on the downstream platform -- without disturbing an existing investment.
Coercion forces values into expected formats without changing their semantic meaning -- accession-number padding, date-string format normalization, AE-Title remapping. It's cheap, parallelizable edge work. Transformation (which lives in VNA Migration, not here) changes values semantically per a documented audit-trailed rule -- e.g., re-mapping a study description from a source institutional code to a target institutional code per a migration plan. Migration Engine handles coercion; downstream systems handle transformation.
Same family-wide mechanism as the Router, SR Engine, and VNA family. Migration Engine uses keyed-hash pseudonymization on the way out (to the AI vendor), retains the source ↔ anon-ID mapping, and re-identifies AI-returned findings on the way back. Available in the Enterprise license tier. If the customer has multiple Synthology products, the site encryption key is shared for cross-product anon-ID consistency.
Insert upstream. The third-party tool keeps its own configured source connections, workflow, and target. Migration Engine becomes a new "source" for the third-party tool -- but with pre-cleaned data that flows through normalization and coercion before the third-party tool sees it. The customer's migration plan, project schedule, and stakeholder reporting don't change; Migration Engine improves the throughput transparently.
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. Same framework as Router, VNA Repository, VNA Migration, and SR Engine -- Migration Engine handles storage and forwarding without modifying clinical interpretation. Coercion is constrained to syntactic / format-level changes; semantic value changes are out of scope (those belong in VNA Migration).
Yes -- Windows and Linux, same as the rest of the router-pattern family. MSI installer for Windows, self-contained Linux tarball for Linux. Multi-worker deployments can mix OS platforms.
Standalone migration? Front-end for VNA Migration? Cleanup layer for an existing third-party migration tool? Modality- side cleanup that’s become a daily ops headache? Tell us the shape and we’ll come back within one business day with a proposed deployment.