Specialized engine · Universal pre-processor

XyDromatics Migration Engine — vendor-agnostic by design.

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.

Request a demo See deployment patterns

Capabilities

Cheap, parallelizable edge work — for any migration target.

Migration Engine focuses on the syntactic cleanup that makes downstream verification, transformation, and audit faster — regardless of who’s doing the downstream work.

Multi-source ingestion

Read from any DICOM-conformant source, plus filesystem and HL7-driven inputs. Same source-system breadth as VNA Migration in a smaller footprint.

• C-STORE SCU (push from source) + SCP (pull-style ingest)
• Q/R against the source archive (C-FIND + C-MOVE / C-GET)
• STOW-RS for modern HTTP-based source systems
• HL7 / MWL-driven ingest (orders + worklist trigger pulls)
• File-watcher ingest for offline / disconnected sources
• Bulk DICOMDIR + filesystem-walk for raw exports

Normalization at the edge

The cheap, parallelizable cleanup work that makes downstream verification + audit faster. Run multiple Migration Engine workers; let downstream tools focus on their actual jobs.

• Character-set normalization (legacy non-UTF-8 sources)
• Malformed-header repair (legacy systems wrote non-spec data)
• Deprecated VR (Value Representation) coercion
• Non-spec timestamp formatting normalized to spec-compliant
• SOP Instance UID validation + remediation where possible
• Per-source-vendor profile handling (vendor X always emits this quirk)

Tag coercion

Force common tag values into the formats downstream systems expect — without changing the value semantics. Distinct from VNA Migration's audit-heavy tag transformation.

• Accession-number padding / formatting per institutional standard
• Date-string format normalization (YYYYMMDD vs ISO-8601)
• AE-Title remapping (legacy modality AE-Titles -> current naming convention)
• Patient-name format coercion (e.g., FAMILY^GIVEN canonicalization)
• Study Description / BodyPartExamined normalization to RadLex / institutional codes
• Configurable coercion rules per source / per modality

Scheduled sends + retry

A standalone migration appliance has to manage its own pacing. Built-in scheduling, retry policies, and dead-letter handling.

• Scheduled migration windows (off-peak only, weekends only, etc.)
• Per-destination bandwidth caps + priority queues
• Exponential-backoff retry with configurable policy
• Dead-letter queue for persistently-failing sends
• Pause / resume with state checkpointing
• Concurrent worker support for parallel sends

Universal pre-processor (vendor-agnostic)

Migration Engine doesn't care who's doing the actual migration delivery. Normalize and coerce upstream of any target platform — Synthology or third-party.

• Front-end for XyDromatics VNA Migration (packaged pattern for large engagements)
• Front-end for DataFirst engagements (via IES-Advisors)
• Front-end for Laurel Bridge migration tools (Compass, Navigator)
• Front-end for DicomSys migration tools (UVR)
• Front-end for customer's existing migration platform (any DICOM-conformant target)
• Standalone — no downstream migration platform required when Migration Engine handles the full move

Family-platform features

Same platform features as the rest of the router-pattern family.

• Keyed-hash pseudonymization with shared site encryption key (anon-IDs consistent across the customer's product portfolio)
• Built-in honest-broker capability for studies anonymized by Migration Engine
• AI-vendor PHI-shielded round-trip workflow
• Web administration UI with shared sidebar shell
• Role-based access control with full permission catalog
• Hash-chain audit log for migrated studies
• 21 CFR Part 11-aligned audit trail

Architecture

Source · Migration Engine · any downstream target.

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.

XyDromatics Migration Engine architecture Migration Engine reads from a source archive, performs normalization and tag coercion at the edge, and forwards cleaned data to any downstream target — Synthology VNA Migration / Repository / Clinical / SR Engine, third-party migration tools (DataFirst, Laurel Bridge, DicomSys), or a final archive directly. Multiple Migration Engine workers scale horizontally for large migrations.

Deployment patterns

Six deployment shapes.

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.

Pattern 1

Standalone small / medium migration

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

1. Source: legacy PACS via Q/R or filesystem export
2. Migration Engine ingests with normalization + coercion at the edge
3. Per-source / per-modality cleanup rules applied
4. Studies forwarded to target archive (any DICOM-conformant)
5. Hash-chain audit log + completion report at engagement end

Integration points

Sources, Synthology targets, third-party targets.

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.

Source systems (read from)

• Any DICOM-conformant SCP via Q/R
• Legacy PACS / VNA across all major vendors
• Filesystem exports (DICOMDIR, raw tree)
• HL7 / MWL-driven ingest for order-and-worklist-correlated migrations

Downstream targets (Synthology)

• XyDromatics VNA Migration (front-end pattern, packaged deployment)
• XyDromatics VNA Repository (retention-tier writes)
• XyDromatics VNA Clinical / Clinical Research (post-510(k))
• XyDromatics Router (routing layer downstream of cleanup)
• XyDromatics SR Engine (for SR-specific migrations)

System requirements & sizing

Sized to throughput, scales horizontally.

Migration Engine workers scale linearly until source-side throttling becomes the bottleneck. Add workers; throughput adds. Sizing is per-worker.

Licensing

Three packages, project-scoped or perpetual.

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.