CMMS Data Migration Guide

Introduction

CMMS migration is not the act of importing rows. It is the process of deciding which maintenance information the organization trusts, how it will be represented in the new system, what must remain accessible, and who accepts responsibility for the result.

A fast import of inconsistent asset names, duplicate parts, expired preventive tasks and vague work history can make a new platform less usable than the spreadsheets it replaces. Conversely, waiting for “perfect data” can stall improvement indefinitely. The goal is fit-for-purpose data for a controlled first release, with governance that improves it over time.

Table of Contents

1. Migration principles
2. Inventory sources and define scope
3. Design the target model
4. Profile and cleanse
5. Decide what history to keep
6. Map and transform
7. Trial loads and testing
8. Cutover and reconciliation
9. Post-launch governance
10. FAQs

Migration Principles

Business owners decide meaning

IT or an implementation partner can profile, transform and load data. Maintenance and operations must decide which asset is real, which hierarchy is useful, which PM remains valid and which part description is approved.

The target process determines the data

Do not migrate a field merely because it exists. Identify the workflow, decision, compliance need or integration that uses it. Data without an owner and purpose becomes clutter.

History and master data are different

Master data—assets, locations, parts, job plans, users—controls future work and requires high quality. Historical transactions can be migrated selectively or retained in an archive depending on value and obligation.

Reconciliation is mandatory

A successful tool message does not prove a correct migration. Reconcile counts, relationships, critical fields and sample records against approved sources.

Migration is a repeated process

Use multiple trial loads. The repeatable extraction, transformation and validation process matters as much as the final file.

Inventory Sources and Define Scope

Create a source register:

Look for hidden sources: technician notebooks, printed schedules, personal files, barcode lists, calibration tools and vendor databases. Do not promise to migrate what has not been inventoried.

Define the first-release sites, assets, users, work and PM. Identify regulatory, warranty, safety, financial and contractual records that require specialist review.

Design the Target Data Model

Asset and location hierarchy

Define levels that support finding equipment, assigning work, rolling up history and reporting. A possible hierarchy is company/site/area/system/maintainable asset, but operations vary.

Specify:

• Unique ID and naming standard.
• Parent/location rules.
• Asset class/type.
• Lifecycle status.
• Criticality.
• Owner/cost center references.
• Make/model/serial and relevant dates.
• Meters/units.
• Required vs optional fields.
• Legacy identifiers.

Avoid a hierarchy so deep technicians cannot navigate it or so shallow the team cannot distinguish equipment.

Work and failure codes

Design controlled work type, priority, status, problem, cause and action values. Keep the initial list teachable. Map old free text to unknown/legacy when no defensible conversion exists rather than inventing precision.

PM and job plans

Separate the maintenance strategy from generated work. Define task, trigger, interval, asset assignment, labor/skill, instructions, parts/tools, readings, safety references, revision and owner.

Parts and inventory

Decide which system owns item master, on-hand, value, purchasing and issues. Normalize IDs, descriptions, units, bins and supplier/manufacturer references. Link parts to assets/job plans only where evidence supports the relationship.

Users and roles

Map active people to approved identities, role, site/team and authority. Do not migrate shared accounts. Define treatment for contractors and departed staff referenced in history.

Profile and Cleanse

Profile every target field for completeness, uniqueness, validity, consistency and relationship integrity.

Assets

• Duplicate serial/tag or near-identical name.
• Missing parent/location.
• Retired equipment marked active.
• Conflicting owner or criticality.
• Invalid make/model/serial.
• Asset listed in PM/work but absent from register.

PM

• Duplicate schedules for the same failure control.
• Past-due next date caused by an abandoned calendar.
• Job text too vague to execute.
• Interval/unit conflict.
• PM assigned to retired/wrong asset.
• Missing owner or safety requirement.

Parts

• Duplicate part under multiple codes.
• Inconsistent unit of measure.
• Description insufficient to distinguish item.
• Invalid/empty bin.
• Negative or unexplained quantity.
• Supplier number used as internal identity without governance.

Work history

• Missing asset/work type.
• Completion before start.
• Vague “fixed” descriptions.
• Duplicate events.
• Costs/labor in inconsistent units.
• Attachments with broken paths.

Create cleansing rules and exception queues. Automate deterministic corrections, such as date format or trimmed spaces. Route semantic decisions to owners. Preserve an audit of changes.

Decide What History to Keep

Classify history:

1. Must migrate: needed in daily CMMS decisions or a controlled requirement.
2. Useful migrate: recent, reliable history that supports planning and reliability.
3. Archive: retained and searchable but not required in transactional screens.
4. Dispose: only under approved retention/privacy/legal policy.

Evaluate each dataset by:

• Regulatory/legal/warranty need.
• Decision value.
• Data quality.
• Ability to map to current assets/users/codes.
• Volume and attachment cost.
• User access requirement.

An archive needs ownership, readable format, access control, retention, backup and retrieval testing. “Leave it on the old server” is not an archive plan.

Map and Transform

Maintain a mapping specification:

Use stable IDs. Do not join only on names. Preserve source record IDs for traceability. Define time zone, currency, units and encoding. Protect personal or sensitive data and migrate only what is necessary.

For attachments, validate file type, size, path, duplicates and malware-handling process according to IT policy. Link current manuals to governed document sources when possible rather than copying uncontrolled versions.

Trial Loads and Testing

Run at least one representative trial before final migration; complex projects need several.

Structural validation

• Expected record counts.
• Required fields populated.
• Unique keys remain unique.
• Parents exist before children.
• Valid code/reference values.
• No orphan PM, parts or work.

Business validation

• Technicians can find representative assets.
• Planners can understand and generate PM.
• Supervisors see correct site/team scope.
• Part units/bins make sense.
• Asset history is readable and linked.
• Critical assets/documents/readings are correct.

Process validation

Create new work using migrated masters. Generate PM. Issue a migrated part. Run reports. Test integrations and permissions. Migration acceptance is not separate from workflow acceptance.

Reconciliation

Create totals and samples before/after. For example:

• Active assets by site/class.
• PM by status/trigger/criticality.
• Open work by priority/status/site.
• Parts by storeroom/unit.
• Historical work by year/site.
• Attachments loaded/failed.

Investigate differences; do not simply adjust the expected total after the load.

Cutover and Reconciliation

The cutover plan should define:

• Source freeze/read-only timing.
• Delta extraction after the last trial.
• Load sequence and duration.
• PM schedule transition to prevent duplication/gaps.
• Open-work conversion and ownership.
• Integration activation.
• Validation owners and sign-off window.
• Contingency/rollback.
• User communication and support.

Prioritize sample checks for critical assets, statutory tasks and high-value parts. Record known data limitations visibly. A controlled exception is safer than hidden uncertainty.

Post-Launch Governance

Migration ends; data governance continues.

• Approve who creates/moves/retires assets.
• Control code/job-plan changes.
• Monitor duplicate and incomplete records.
• Review PM ownership and stale tasks.
• Reconcile integrated master/transactions.
• Audit access and departed users.
• Track data-quality KPIs and correction backlog.
• Version naming/classification standards.

Make data quality part of normal management, not an annual cleanup project.

Common Failure Modes

• Letting the vendor decide business meaning.
• Importing every column/history because it exists.
• Treating free text as reliable structured cause data.
• Loading retired assets as active.
• Failing to reconcile parent/child relationships.
• Running old and new systems in parallel indefinitely.
• Ignoring PM next-date cutover.
• Migrating shared/inactive accounts.
• Discovering attachment/privacy issues at cutover.
• Declaring “data complete” without user task testing.

FAQs

What CMMS data should be migrated?

The current masters and open work needed to operate, valid PM/job plans, required parts and history with legal or decision value. Scope is context-specific.

How much work history should be moved?

Use retention, quality and decision criteria. Migrate useful reliable history; archive the rest accessibly where appropriate.

Who cleans the data?

Business owners decide truth; the project/data team profiles, transforms and coordinates. Responsibilities should be explicit.

Can migration be automated?

Formatting, validation and deterministic mapping can. Duplicate identity, hierarchy, criticality and obsolete-task decisions need accountable judgment.

How is migration tested?

Structural checks, business-user sampling, end-to-end workflow testing and before/after reconciliation.

What happens to the old CMMS?

Plan read-only/archive, retention, access, security and decommissioning. Avoid uncontrolled indefinite operation.