XyDromatics™ Migration — archive-to-archive at scale.

Different scale and different shape -- but they're often deployed together. Migration is the multi-petabyte archive-to-archive workhorse: full HA, parallel worker nodes, multi-month migration plans, per-study verification, transformation, and a per-study integrity record. Migration Engine is the smaller-footprint standalone appliance -- right-sized for short-lived migration projects (50-100 GB modality cleanups, single-site cutovers) AND, increasingly, for use as a horizontally-scaled normalization / tag-coercion front-end in front of Migration on large engagements. Same family, complementary roles.

Generally for migrations larger than ~100 TB, or where the source archive is known to have heavy character-set / malformed-header / non-spec-VR baggage that's going to cause retries during verification. Deploying Migration Engine as a front-end means you can parallelize source-side reads on cheap compute (multiple Migration Engine workers) and clean up the common syntactic issues at the edge before Migration spends its CPU on verification + audit-trail work. Net effect is meaningfully higher overall throughput. Packaged deployments are quoted as a single SOW; the discovery phase will tell you whether the front-end is worth it for your specific source archive.

The Router can route studies between archives — that's a common pattern for parallel-run migrations during a PACS cutover window. But the Router's job is real-time routing of live clinical traffic, not bulk historical migration with verification. Migration is purpose-built for the bulk historical use case: per-study verification, pause/resume, scheduled windows, stakeholder reporting. Use both together during a cutover (Router for new traffic, Migration for historical) and the patterns reinforce each other.

Highly dependent on source PACS and network. Conservative targets: 5-10 TB/day per worker node against a typical legacy PACS Q/R interface. Modern source systems with STOW-RS or filesystem export can reach 50+ TB/day per worker. Multi-worker deployments scale roughly linearly until you hit source-side throttling. Discovery phase produces the realistic forecast specific to your sources.

Routes to the quarantine queue. Common causes: corrupted pixel data on the source, malformed DICOM headers (legacy systems sometimes wrote non-spec-compliant data), or character-set encoding bugs. Each quarantined study is individually adjudicated -- clinical review decides repair, skip, or escalate. The audit trail captures every decision. Silently dropping studies is never the default.

Yes -- this is the standard pattern. Source-side reads happen in scheduled off-peak windows (typically nights + weekends). Bandwidth caps prevent the migration from saturating your network or source-PACS load. The Router can be configured to send new clinical traffic to the target archive during the migration window, so by cutover day the target already has both the live recent data and the historical migrated data.

Per study: the study UID, source vs destination series and instance counts, the SOP-UID delta in both directions, status, timestamp, operator identity and any transformation applied — each transformation also recorded in the object's Original Attributes Sequence. Per instance: a SHA-256 taken when the object is stored. To be precise about what that hash is and is not: it is computed on the destination side, so it proves the archived object has not changed since it landed. It is not a source-side digest, and there is no source-to-target hash comparison — completeness is established by count and SOP-UID reconciliation instead. The append-only audit trail covers the entire migration from start to finish. An independent re-verification tool can re-walk every record at any point. The audit trail is the deliverable -- not just the migration itself.

Three layers. First: count reconciliation -- source study count vs target study count vs quarantine count, with named-reason buckets for any difference. Second: hash verification -- random sample of studies re-verified at target. Third: clinical-spot-check -- radiologist team picks studies and confirms diagnostic-quality match against source. All three are part of the standard closeout package.

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 Repository -- Migration handles storage and forwarding without modifying clinical interpretation. Tag transformation in flight is constrained to non-interpretive changes (anonymization, AE-Title remapping, etc.); clinical-tag-edit (changing PatientName, AccessionNumber, etc.) is out of scope for this product. Every Synthology product is non-device software under FD&C Act §520(o)(1)(D).