Data migration
Six ways a migration goes wrong. Here is the control for each.
Migration programmes are lost on decisions, not on technology. Bad source data does not improve by being moved, and a scope question nobody will sign defaults to migrating everything. Below is the register we work from on every programme, the ledger of what does not travel, and the five tests you watch us pass before go-live.
Failure-mode register
How a Maximo migration goes wrong
Six modes, each watched happening on a real programme, each with the control that stops it. The controls are what you are buying; the pipeline is the easy part.
- 01
Nobody says no, so everything travels
Records created by people who left, for a process that has changed twice, have no owner to ask. The control is a decision register: one row per object, the option chosen, the named owner, the date. Where a row is still open on the agreed date, everything migrates and we state that cost in writing before it happens.
- 02
Three sources of truth, all partly right
The legacy register, the planners spreadsheet and the labels on the plant each hold something the others do not. The control is a precedence rule agreed per field before mapping starts, rather than per record while loading.
- 03
Cleansing is expected to invent data
Rules can fix what is systematically wrong: format, case, unit of measure, a one-to-one code map. A manufacturer or serial number never recorded is a capture exercise with its own budget and its own owner, and it is named as one at assessment rather than discovered at run three.
- 04
The load is hand-built, so every run differs
Mapping and cleansing rules are code, run at full volume in a representative environment, with the reconciliation report generated by the pipeline. A reconciliation assembled in a spreadsheet after the load proves the spreadsheet.
- 05
Work created during the freeze is remembered, not planned
The control is a delta load with its own reconciliation, written into the runbook, plus a route for raising emergency work while the source is read only that every site is told about before the window opens.
- 06
History is migrated complete because complete sounds safe
The last tenth of work history usually costs more than the first nine tenths. The control is a retention obligation agreed per object with the person who carries it, and a cut-off date that the load schedule enforces.
Load ledger
What crosses into Maximo, and who signed for it
One row per object, each with a named owner. The list underneath is the part clients read twice.
| What moves | From | Direction | To | Signed by |
|---|---|---|---|---|
| Asset and location master | SAP PM | → | Maximo ASSET and LOCATIONS | Asset data owner |
| Job plans and PM schedules | Legacy CMMS | → | Maximo JOBPLAN and PM | Maintenance manager |
| Open and recent work orders | SAP PM | → | Maximo WORKORDER | Operations lead |
| Inventory items and balances | SAP MM | → | Maximo ITEM and INVENTORY | Supply chain lead |
| Attachments against live assets | Legacy document store | → | Maximo DOCLINKS | Compliance owner |
What deliberately does not travel
- Closed work history beyond the agreed retention cut-off, archived outside Maximo with a documented retrieval route
- Inventory for depots closed before the cut-off, with the balances evidenced in the archive rather than in search results
- Free-text fields no report and no user reads, proven by a query against the source rather than by opinion
- Legacy identifiers carried only out of habit. Where one is genuinely needed it is mapped to a named alternate ID field
If you read one thing on this page
A migration is not lost on the load. It is lost on the scope questions nobody will put their name to, because an unanswered question defaults to migrating everything.
Ask any supplier for the decision register before you ask for the plan. If there is no row per object, no named owner and no date, the scope has already been decided by default and the bill arrives on the first Monday.
Watched, not described
Five tests you sign off before go-live
Each is run in front of the people named against it. A test nobody watched is a claim.
- DM-1
A full-volume load into a representative environment
- Passes when
- The reconciliation report ties source counts and values to what landed, object by object, including the rows deliberately excluded.
- Witnessed by
- Your data lead and platform owner
- DM-2
The second dry run, against the same rules
- Passes when
- No rejection reason appears that was not already on the list from run one.
- Witnessed by
- Programme manager
- DM-3
The first search a planner does
- Passes when
- One result, the correct parent location, the active PM attached, and recent work history visible against it.
- Witnessed by
- Two named planners, on assets they have looked after for years
- DM-4
The freeze delta
- Passes when
- Work raised while the source was read only lands with its own reconciliation, tied to the emergency work log kept by the sites.
- Witnessed by
- Cutover manager
- DM-5
Rollback, rehearsed rather than written down
- Passes when
- The rollback completes inside the time in the runbook, so the call-by time is a measured number.
- Witnessed by
- The change authority named on the window
Boundaries
Three things we will not do
All three surface in scoping, so they are stated here rather than in the proposal.
We do not choose what stays behind
Each option is quantified and put in front of a named person with the consequence written next to it. The choice belongs to your business owner, because the retention obligation and the operational risk do. We can frame the question; we cannot be the answer.
We do not migrate what was never captured
Cleansing corrects form, not absence. Where criticality, manufacturer or serial number is missing across a population, capturing it is a separate workstream with its own budget, and it is named at assessment.
We do not change the platform in the same window
Migration reshapes data into the Maximo model; a database vendor conversion keeps the data and changes the platform. Where both are in scope they are sequenced so only one variable moves at a time.
Maximo data migration, frequently asked questions
- Which source systems do you migrate from?
- In production: SAP PM, Oracle eAM, Maximo 5.x, 6.x and 7.6.x, IFS, in-house ERP modules, CMMS tools and spreadsheets. The source system is rarely the hard part. Failure modes 1 and 6 are the hard part, and they are the same whatever the source.
- How do you handle bad source data?
- It is measured before anything is touched: rows, null rates, duplicates and orphans per object, with twenty real records printed for each problem. A planner recognises their own bad data instantly, and the programme stops discussing tooling and starts discussing scope.
- What does archiving instead of migrating involve?
- The records stay retrievable, and not inside Maximo: a read-only copy of the source, an export into a reporting store, or a documented extract held by the business, depending on the retention obligation. The retrieval route is written into the decision before it is signed. It never means deleting data because migrating it was inconvenient.
- How does the business keep running during cutover?
- An agreed freeze window, an announced route for raising emergency work while the source is read only, a delta load with its own reconciliation, and a rollback with a call-by time in the runbook. Failure mode 5 covers what happens when that is left to the night itself.
- Where does MaxIron Data Loader fit?
- Migration pipelines are built and run by us for the length of the programme. MaxIron Data Loader is what your own team uses afterwards, when a depot closes or a bulk PM revision is needed: different job, same rule that nothing commits before it validates.
- Is this the same as a database vendor conversion?
- No. A conversion preserves the data and changes the platform underneath it; a migration reshapes different data into the Maximo model. See database vendor conversion. Where both are in scope we sequence them so only one variable changes at a time.
Where migration sits in a programme
Work that depends on the data being settled first
Bring us one object, and the argument about it.
Pick the object your team disagrees about most, almost always inventory or work history, and send a real extract with the field names left as they are. We come back with a profile of what is in it, the scope options with the consequence of each, and the one decision we think has to be made first.
Bring this to the first call
- A real extract of one object, unedited, field names as they are
- Your source systems, and roughly how long each has been running
- The retention obligations you already know about
- Who can decide that something is archived rather than migrated
- The go-live date the business has already been told