Migrate an existing device portfolio into reconciled EUDAMED state
EUDAMED data migration is a bounded programme: discover every source, freeze reproducible exports, map and normalize approved facts, resolve exceptions, prepare the chosen submission channel, then prove record by record that intended and accepted states agree.
Move the portfolio, prove the outcome, and leave a maintainable process
Yarify implements the migration pipeline across source discovery, normalization, validation, submission preparation, exception ownership, and final reconciliation. Every source record receives a visible disposition.
What the engagement produces
- A versioned inventory, canonical model, and approved transformation map
- Controlled release waves with validation and exception evidence
- A reconciled target state plus an operational handover for future changes
Migration owns the initial portfolio conversion
The Commission publishes separate MDR, IVDR, and legacy-device dataset resources on the UDI/Device registration page. A migration must first select the applicable record routes; it cannot safely flatten all products into one generic template.
The target is more than valid XML. Official technical documentation separates schemas, samples, service definitions, business rules, enumerations, and data dictionaries. A governed migration records which artefact layer gives meaning to each check and which version or retrieval date was used.
This page covers the one-time conversion of an existing population. For a flat-file transformation, use the Excel-to-XML guide. For recurring source synchronization after handover, use the ERP integration guide.
One portfolio scope
Define populations, sources, exclusions, deadlines, current state, and ownership before transformation begins.
One canonical model
Preserve identifiers and relationships consistently even when sources represent them in incompatible structures.
One disposition ledger
Account for every source record as accepted, excluded, merged, rejected, or still owned as an exception.
Ten stages from discovery to accepted state
Each stage has a concrete exit artefact. Work may iterate, but a wave should not advance with hidden blockers or undocumented assumptions.
| Stage | Migration work | Control | Exit artefact |
|---|---|---|---|
| Discovery | Define the regulatory/device populations, Actors, source systems, record volumes, current EUDAMED state, owners, deadline exposure, and exclusions. | No source or population enters scope without an accountable owner and stable extraction key. | Approved source-system inventory and migration scope |
| Data export | Produce read-only, timestamped exports from Excel, ERP, PIM, PLM, regulatory systems, and legacy databases with source metadata preserved. | Record query/filter logic, extraction time, row counts, encoding, and checksums or equivalent integrity evidence. | Reproducible source snapshot and extraction log |
| Field mapping | Map each source attribute to a canonical meaning, applicable EUDAMED entity/attribute, transformation, owner, dependency, and evidence path. | Select the applicable current dataset first; do not force MDR, IVDR, and legacy routes into one assumed template. | Reviewed source-to-target mapping specification |
| Cleaning | Detect missing identifiers, duplicate rows, invalid formats, whitespace and encoding defects, contradictory values, and broken joins. | Never silently replace a missing regulatory fact with a convenience default. | Completeness report and traceable correction set |
| Normalization | Create explicit Actor, Basic UDI-DI, UDI-DI, package, certificate, market, language, and other applicable relationships and map approved controlled values. | Preserve original value, normalized value, rule version, source, reviewer, and approval status. | Canonical migration dataset and normalization rules |
| Validation | Apply types, required and conditional checks, enumerations, relationship integrity, XSD validation where relevant, and implementable business rules. | Keep syntax, schema, controlled-value, business-rule, reference, and current-state results as separate layers. | Validation report tied to a recorded technical baseline |
| Error resolution | Route each failure to its source owner or regulatory decision owner, apply approved corrections, and rerun the affected checks. | Track blocker, severity, affected records, owner, resolution evidence, retest result, and waiver decision if applicable. | Owned exception register with release disposition |
| XML or M2M preparation | Convert the approved canonical data into reviewable manual-entry packs, validated bulk XML packages, or M2M payloads for the chosen channel. | The submission method changes packaging and transport, not the approved meaning of the device facts. | Versioned release manifest and submission-ready payloads |
| Submission | Release approved records in controlled waves through the applicable EUDAMED method and capture identifiers, timestamps, correlation, and responses. | Separate payload preparation from authenticated user actions and production permissions. | Complete submission response log |
| Reconciliation | Compare intended state, submitted state, processing result, accepted EUDAMED state, and internal source status record by record. | Do not close a wave merely because a file was uploaded or a transport acknowledgement was received. | Signed reconciliation report and handover documentation |
The submission stage can use UI, bulk XML, or M2M. The Commission describes XML upload as semi-automated because the user uploads the file, while M2M automatically exchanges XML with the backend. See the official method definitions.
Ten deliverables make the migration reviewable
The deliverables form an evidence chain. They should refer to the same stable source and canonical record keys.
| Deliverable | What it proves | Primary consumers |
|---|---|---|
| Source-system inventory | Which populations, systems, files, owners, snapshots, and exclusions are in scope | Programme lead · RA/QA · data owners |
| Mapping specification | How every source value, dependency, and relationship reaches the selected target dataset | RA data owner · engineering · reviewers |
| Canonical data model | How identifiers and one-to-many relationships remain stable across unlike source structures | Engineering · migration operations |
| Completeness report | Which required or conditionally applicable facts are missing, conflicting, duplicated, or unresolvable | RA/QA · source owners |
| Normalization rules | Which approved conversions, controlled-value mappings, and hierarchy rules were applied | RA data owner · engineering |
| Exception register | Who owns each blocker, its affected records, resolution evidence, retest, and release decision | Programme lead · accountable reviewers |
| Validated XML packages or M2M payloads | Exactly which approved dataset and technical baseline were prepared for release | Submission operations · integration team |
| Submission response log | What was sent, when, by which method, with which correlation and processing result | Submission operations · support |
| Reconciliation report | Whether every intended record reached the correct accepted state or remains an owned exception | RA/QA · system owners · audit |
| Handover documentation | How to operate residual corrections, future registrations, artefact updates, and support escalation | Business-as-usual team |
Synthetic scenario: Excel and ERP disagree
This worked example shows migration decisions without implying universal field requirements or using customer data.
| Source observation | Migration treatment | Controlled output |
|---|---|---|
| 1,240 ERP product rows and 510 workbook rows overlap on local catalogue number, but neither source has a universally stable EUDAMED key. | Build a crosswalk using approved UDI identifiers and governed internal keys; quarantine ambiguous many-to-many matches. | Record identity table with match confidence and owner-approved exceptions |
| ERP contains commercial descriptions and status; Excel contains approved Basic UDI-DI and regulatory attributes. | Assign field-level authority instead of declaring one entire system the master; preserve provenance for each selected value. | Source-priority matrix and canonical device-family records |
| Country availability is stored as comma-separated text, and packaging levels occupy repeated spreadsheet columns. | Parse into explicit child collections, map only approved controlled values, and report unrecognized tokens. | Normalized market and package relationships plus exception list |
| Some Regulation-device rows lack an approved family relationship; other rows use an obsolete local classification label. | Block release, show dependent records, and route decisions to the regulatory owner without guessing the missing fact. | Decision worklist with downstream impact and retest status |
| The organization chooses bulk XML for the initial migration and manual UI for a small residual exception set. | Create channel-specific release manifests from the same approved canonical dataset and reconcile both result paths. | XML packages, manual-entry packs, response log, and one accepted-state ledger |
Explicit assumptions
- Synthetic manufacturer and counts: 1,600 planned device records after deduplication; no real customer data is shown.
- Two primary source families: one ERP export and 14 controlled Excel workbooks, with regulatory approval records available separately.
- The example assumes applicable UDI/Device registrations only; certificate, Actor, and other module migrations would be scoped as separate workstreams.
- Bulk XML is a project choice for illustration, not a legal requirement. The Commission's volume bands are indicative guidance, not statutory thresholds.
- Regulatory owners approve device route, identifiers, applicability, classification, and corrected facts before release.
Acceptance requires reconciliation, not upload
An acknowledgement only proves that an action reached one processing point. Close the project when every in-scope record has an evidenced final disposition and ongoing ownership.
| Acceptance criterion | Evidence |
|---|---|
| Population completeness | Every in-scope source row is accepted, intentionally excluded with reason, merged through an approved crosswalk, or held as an owned exception. |
| Identity and relationship integrity | Actor, Basic UDI-DI, UDI-DI, package, certificate, and other applicable relationships resolve without ambiguous or orphaned links. |
| Data approval | Every migrated value retains source and transformation provenance; regulatory facts and corrections have accountable approval. |
| Technical baseline | Dictionaries, rules, enumerations, XSDs, service definitions, or UI guidance used by the wave have recorded versions or retrieval dates. |
| Submission traceability | Each released record connects to its frozen source snapshot, canonical record, payload/entry pack, correlation, and response. |
| Final-state reconciliation | Accepted EUDAMED state and internal status agree, while every difference has an owner and next action. |
| Operational handover | The business-as-usual team owns remaining exceptions, change procedures, technical updates, monitoring, and support paths. |
Where available and appropriate, an Actor's own structured device-data download can support comparison. The official download guide warns that only records shown in the result list are included and multiple result pages require separate downloads, so extraction completeness itself must be controlled.
What Yarify can deliver
Source discovery, reproducible extraction specifications, canonical modeling, field and relationship mapping, quality profiling, normalization pipelines, technical validation, exception worklists, approval controls, XML or M2M preparation, release manifests, response capture, reconciliation, and operational handover.
What Yarify does not decide
Device route, classification, regulatory applicability, placement facts, identifier assignment, certificate applicability, and approval of source facts remain with the manufacturer and qualified regulatory advisers. A technically accepted migration does not guarantee MDR or IVDR compliance.
Use specialist guides for each downstream path
Migration owns initial portfolio conversion and acceptance. These pages own the deeper transformation, transport, validation, and recurring integration questions.
UDI requirements
Select the applicable dataset and inventory the facts, relationships, owners, and evidence.
Open guide →Excel to XML
Go deeper on tabular-to-hierarchical mapping and XML transformation.
Open guide →ERP integration
Build the ongoing source and status flows that begin after migration handover.
Open guide →XML validator
Separate syntax, schema, controlled-value, rule, reference, and response checks.
Open guide →Bulk XML upload
Prepare and operate a semi-automated, user-uploaded release path.
Open guide →M2M integration
Plan automated DTX transport, onboarding, security, and production operations.
Open guide →Check the 2026 deadlines guide to prioritize applicable records, or return to the EUDAMED automation hub.
EUDAMED migration questions
What is an EUDAMED data migration?
It is a bounded project that converts an existing device portfolio from one or more source systems into an approved, normalized, technically validated, submitted, and reconciled EUDAMED dataset. It includes discovery, cleansing, exception management, release control, and proof of accepted state—not only file conversion.
How is migration different from Excel-to-XML conversion?
Excel-to-XML focuses on transforming tabular source data into hierarchical XML. A migration can involve many workbooks, ERP/PIM/PLM data, legacy databases, existing EUDAMED records, ownership conflicts, deduplication, phased submission, and final-state reconciliation. XML generation is only one possible migration stage.
How is migration different from ERP integration?
Migration is a one-time or bounded portfolio conversion with entry and exit criteria. ERP integration is an ongoing operating capability for future changes, approvals, submissions, and status synchronization. A migration can establish the canonical model later reused by an integration, but the two scopes and acceptance criteria are different.
Must a migration use XML or M2M?
No. EUDAMED supports manual UI, semi-automated XML upload, and automatic M2M exchange. Choose the method based on volume, frequency, data readiness, controls, technical capability, and operating cost. A migration may use different methods for different release populations.
When is the migration complete?
Not when an export is cleaned or an XML file is generated. Completion requires a reconciled disposition for every in-scope source record, traceability from source through the accepted outcome, resolution or formal ownership of residual exceptions, and a documented handover to ongoing operations.
Does a successful migration guarantee regulatory compliance?
No. Yarify can implement data mapping, transformation, validation, exception workflows, submission preparation, response handling, and reconciliation. The manufacturer and qualified advisers remain responsible for regulatory applicability, classification, identifier assignment, and the truth and approval of device data.
Primary sources
Reviewed 9 September 2026. The live technical catalogue, data dictionaries, rules, enumerations, schemas, service definitions, workflows, and transition guidance can change. Record the applicable versions or retrieval dates for each migration wave and re-check them before production release.
European Commission — UDI/Device registration
Official module status and MDR, IVDR, and legacy-device dataset resources used to select the migration target
EUDAMED Information Centre — Categorisation of devices
Official concepts and relationships for Basic UDI-DI, UDI-DI, Package UDI-DI, EUDAMED DI/ID, legacy devices, and other supported categories
EUDAMED Information Centre — Technical-documentation guide
Official explanation of the distinct roles of XSDs, XML samples, service definitions, business rules, enumerations, and data dictionaries
EUDAMED Information Centre — Current technical documentation
Live catalogue of module dictionaries, rules, controlled values, service definitions, schemas, samples, and compatibility notes
EUDAMED Information Centre — Modes of data input
Official description of manual UI, bulk XML, and M2M input methods and indicative device-volume guidance
EUDAMED Information Centre — Data-exchange guidance
Official distinction between manual entry, semi-automated XML upload, and automatic M2M exchange
EUDAMED Information Centre — Download device data as XML
Official workflow and limitations for manually bulk-downloading an Actor's own device or system/procedure-pack data for comparison and reconciliation
European Commission — Device-registration transition infographic
Official transition timeline used to prioritize applicable existing device records without treating the date as universal