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. Built-in scheduling, 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
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.
| 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. No FDA Device Listing required. 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.