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 XyDromatics 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.
n-2">Identifiers & classification
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 XyDromatics 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 XyDromatics 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.
See it
Live captures from a running installation — click any screen to enlarge it.
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 XyDromatics 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 XyDromatics Migration heavyweight.
Flow
Large multi-petabyte migrations benefit from horizontal pre-processing. Multiple Migration Engine workers normalize + coerce in parallel; clean data flows into XyDromatics 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 archive 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.
Availability
A migration is a long-running batch with a defined end, so availability here means the run survives being interrupted — not that traffic reroutes somewhere else. Pool failover is the wrong mechanism for this product, and we do not offer it.
Every study is a durable row in the engine’s encrypted job database with its own state, attempt count and retry gate. If the service is stopped, restarted, or crashes mid-study, anything in flight is automatically returned to the queue at startup and picked up again — the backlog is never lost. Transient target failures back off and retry rather than failing the study outright.
That makes a migration schedulable around your constraints: pause a run, patch the host, restart, resume. A graceful stop finishes in-flight studies and declines new inbound associations transiently, so the source PACS simply retries.
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 XyDromatics 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 XyDromatics Migration / third-party tools. |
| Worker cluster (4+ workers) | 15+ TB / day aggregate | 8 vCPU per worker | 16 GB per worker | Multi-petabyte migrations as XyDromatics 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 coercion rule sets, vendor-quirk handling, and MWL / Q-R pass-through proxy listeners.
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 + XyDromatics Migration, or Migration Engine + Router + archive family) get bundle pricing and shared site-key provisioning.
Documentation
Current GA release v1.0.3.179 · released 2026-08-07
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) | Known vendor quirks and the coercion rules that correct them, 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 XyDromatics Migration on large engagements. XyDromatics 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 / archive 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 XyDromatics 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.
No — and it is worth being direct about that, because the rest of the family does. Migration Engine has no export pseudonymization at any scope: it forwards studies as authored, and it reports that fact about itself in its own health telemetry. Put the Router (or SR Engine, for reports) on the leg that faces the AI vendor — those products carry the keyed-hash pseudonymization and, in the Router's case, the gated re-identification. What Migration Engine does carry is support-role PHI masking: identifiers shown to the read-only support role render as deterministic PSN- tokens under the same per-customer site key.
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, XyDromatics Repository, XyDromatics 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 XyDromatics 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 XyDromatics 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.
