CMMS Migration in Healthcare: How to Move Asset Data Without Losing Compliance History
A practical guide to migrating biomedical and facilities equipment records between CMMS platforms
CMMS migrations in healthcare are high-stakes projects. Equipment records carry compliance history — maintenance logs, inspection records, recall responses — that cannot be lost in the transition. This guide covers the full migration workflow, from data extraction to post-migration validation.
Key Takeaways
- Compliance history — maintenance logs, inspection records, recall responses — must be migrated alongside asset records, not treated as optional.
- The migration is an opportunity to normalise the asset register: fix manufacturer names, expand model abbreviations, assign GMDN codes, and structure location fields.
- A parallel-run period (both old and new CMMS active simultaneously) is essential for high-risk healthcare environments.
- Post-migration validation should include a record count reconciliation, a sample audit of compliance history, and a test of the maintenance scheduling workflow.
Why Healthcare CMMS Migrations Are High-Stakes
A CMMS migration in a manufacturing plant is a data project. A CMMS migration in a healthcare setting is a compliance project.
Healthcare equipment records carry compliance history that has regulatory and patient safety implications. Maintenance logs demonstrate that preventive maintenance was performed on schedule. Inspection records document that equipment was tested and found safe before use. Recall response records confirm that affected devices were identified and remediated. This history cannot be lost in the transition to a new CMMS.
The migration is also an opportunity. Most healthcare asset registers have accumulated years of inconsistent data — manufacturer names in dozens of variants, model abbreviations that no longer match any known device, location strings that reference wards that were renamed or closed. A migration that normalises the data as it moves it produces a cleaner, more reliable register in the new CMMS than the one that existed in the old one.
Phase 1: Data Extraction and Audit
The migration begins with a full extraction of the source CMMS — asset records, maintenance history, inspection records, and any linked documents.
The extraction audit answers four questions:
How many assets are in scope? Count the total records and identify any obvious duplicates (same serial number appearing multiple times, same asset tag on multiple records).
What is the data quality baseline? Run a quality assessment to identify the proportion of records with missing manufacturer names, missing model names, missing serial numbers, and unstructured location fields. This baseline determines how much normalisation work is required before import.
What compliance history exists? Identify the maintenance records, inspection records, and recall response records that need to be migrated. Classify them by type (preventive maintenance, corrective maintenance, inspection, recall) and by format (structured records in the CMMS database, PDF attachments, scanned paper records).
What is the asset ID mapping strategy? Determine how asset IDs will be mapped from the old CMMS to the new one. The most reliable approach is to use serial number as the primary key — if the serial number matches, the records are the same asset. Establish a mapping table before the migration begins.
Phase 2: Normalisation
Before importing into the new CMMS, normalise the extracted data. This is the step that most migrations skip — and the step that causes the most post-migration cleanup.
Normalisation covers: manufacturer name standardisation, model name expansion, GMDN classification, UDI cross-referencing, location parsing, and serial number formatting. See Healthcare Asset Register Normalisation: A Complete Guide for the full normalisation workflow.
The normalisation step also resolves duplicates. Two records with the same serial number (after formatting normalisation) are almost certainly the same asset. The migration should consolidate them into a single record, merging the compliance history from both.
Phase 3: Reference Data Creation
Before importing asset records into the new CMMS, create the reference data: manufacturers, models, locations, and department records. The sequence matters — you cannot create a model without a manufacturer, and you cannot assign a location without the location hierarchy existing.
For large migrations (5,000+ assets), automate the reference data creation using the CMMS's bulk import functionality. For smaller migrations, manual creation is feasible but time-consuming.
Try Struktive on your own data
Upload a raw asset CSV and get back a normalised, DCIM-ready file in minutes. No account required.
Phase 4: Asset Record Import
Import the normalised asset records using the CMMS's bulk import tool. Run a test import on a representative subset (100–200 records) before committing the full dataset. Review the import log for errors and resolve them before proceeding.
After the full import, run a record count reconciliation: the number of records in the new CMMS should match the number of records in the normalised export (minus any intentional deduplication). Investigate any discrepancies before proceeding to compliance history migration.
Phase 5: Compliance History Migration
Migrate compliance history in two passes.
Structured records — work orders, maintenance logs, and inspection records that exist as structured data in the source CMMS can be exported and imported into the new CMMS using the asset ID mapping table established in Phase 1. Map the old asset ID to the new asset ID, and import the records against the new ID.
Unstructured records — PDF inspection reports, scanned paper records, and email attachments need to be manually attached to the migrated asset records in the new CMMS. Prioritise life-critical equipment and any equipment subject to active recalls.
Phase 6: Parallel Run and Validation
Before decommissioning the old CMMS, run both systems in parallel for a defined period — typically 4–8 weeks for a healthcare environment. During the parallel run:
- All new work orders are created in the new CMMS
- The old CMMS is read-only (no new records, but accessible for reference)
- A sample of 50–100 asset records is audited to confirm that compliance history was migrated correctly
- The maintenance scheduling workflow is tested end-to-end in the new CMMS
The parallel run ends when the biomedical engineering team is confident that the new CMMS contains a complete and accurate record of all assets and their compliance history.
Common Migration Failures
Lost compliance history — the most common and most serious failure. Caused by asset ID mapping errors, where the old asset ID and the new asset ID are not correctly linked. Prevented by establishing a robust mapping table before migration and validating it against the compliance history records before import.
Duplicate assets — caused by normalisation gaps, where the same physical asset appears under two different serial numbers (one formatted, one not). Prevented by serial number normalisation before import.
Missing reference data — caused by importing asset records before the manufacturer, model, and location reference data is created. Prevented by following the correct import sequence.
Broken maintenance schedules — caused by GMDN codes not being migrated, so the new CMMS cannot apply category-based maintenance schedules. Prevented by including GMDN codes in the normalised export and mapping them to the correct field in the new CMMS.