IBM Maximo Data Migration: Running the Project End to End

The seven phases of a data migration project

Mapping: the real heart of the project

The mapping matrix links the source model to the Maximo model, object by object. For each target attribute, it states the source, the transformation rule and the default value:

• Keys: which column becomes ASSETNUM, LOCATION, ITEMNUM; do you keep legacy codes or renumber?
• Value lists: a lookup table between source statuses, types and priorities and the values of the Maximo domains.
• Hierarchies: how to rebuild parents (locations, assets) and systems.
• Organization and site: which Maximo site receives each source record.
• Added attributes: data with no standard equivalent, to be created in the configuration before the load.

Version the matrix: each mock load changes it, and production must use the validated version, not the last one modified.

Cleansing the source data

The sources of a fifteen-year-old CMMS invariably contain duplicates, abandoned codes and free-text fields used for purposes other than intended. Handle these cases before the load, in the files, and never in Maximo after the fact:

• duplicate items (the same part under several references) and assets;
• orphan locations or loops in the hierarchy;
• inconsistent units of measure and currencies;
• impossible dates, mixed formats, different decimal separators (comma and period);
• special characters and line breaks in descriptions, which break CSV files.

The decimal separator often trips up projects in countries that use the comma: a cost of 12,50 read as text, or a semicolon delimiter declared incorrectly, shifts every column. Check the format before sending, not after.

Mock loads

A mock load replays the entire migration, in dependency order (see the load order), on an environment configured like production. It serves three purposes: finding mapping errors, measuring durations and rehearsing the runbook. After each one:

1. classify rejections by cause (configuration, mapping, source data, business rule);
2. fix at the source or in the matrix, never by hand in Maximo;
3. record durations per object to size the cutover window.

Two rehearsals are a minimum; three are common when the volume exceeds a few hundred thousand rows.

Preparing the cutover

Cutover is a timed operation: freeze entry in the old system, final extraction, transformation, load, checks, opening to users. To make it safe:

• write a minute-by-minute runbook based on the last mock load;
• prepare a recovery plan if the load is interrupted: resume at the exact row, with no duplicates, rather than starting over;
• decide the go / no-go criterion in advance (rejection rate, critical objects complete);
• keep the old system read-only during the stabilization period.

Reconcile and prove

A data migration is only finished when you can demonstrate, with figures, that the expected data is in Maximo: rows extracted, rows validated, rows loaded, rows rejected with their reason. The guide quality control and reconciliation details the checks to run object by object.

The most common pitfalls

• Configuring during the load: every attribute or value list added late invalidates the previous rehearsals.
• Fixing in Maximo rather than at the source: the fix is lost on the next load.
• Testing on an environment different from the target: value lists diverge between DEV and PROD.
• Underestimating throughput: a single load of 500,000 assets can take hours; measure it during the rehearsals.
• Not knowing how to resume: a network outage in the middle of a file without a reliable resume mechanism leads to either gaps or duplicates.

Frequently asked questions