IBM Maximo Data Init (MAS 9): Method and Data Load Order

Data init, data migration, upgrade: what are we talking about?

The three terms often overlap in project plans, but they do not describe the same work:

• Data init: initial load of base and reference data into a new Maximo (new implementation, new site, new organization).
• Data migration: transfer of data from an existing system (legacy CMMS, spreadsheets, ERP, another Maximo instance), with extraction, transformation and cleansing. See the guide running a Maximo data migration project.
• Version upgrade: moving from Maximo 7.6 to MAS 9, which generally keeps the existing database. See upgrading from Maximo 7.6 to MAS 9.

In all three cases, the load itself obeys the same constraints: dependency order, the business rules Maximo applies to every record, and volume.

Define the scope before the first file

Most data init delays do not come from the load, but from a fuzzy scope. Before producing any file, freeze:

1. The list of objects to load and their volumes (10,000 locations are not handled like 2 million inventory balances).
2. The target model: organizations, sites, location hierarchy (systems), classification structure, value lists (ALN and synonym domains), added attributes.
3. The business owner of each data set: they validate the files and settle duplicates.
4. The environments and the number of rehearsals (mock loads) before production.
5. The success criterion: how many rows expected, how many loaded, what rejection rate is acceptable (ideally zero, with a signed list of exceptions).

The Maximo data load order

Maximo validates each record on insert: an asset that references a missing location, an unknown item or a value outside the list is rejected. The order below, from most referenced to most dependent, applies to most Manage implementations. The names in parentheses are the standard object structures used by the MIF and the REST API.

Hierarchies are loaded in several passes: first all nodes without a parent, then level by level, or in a single file sorted by depth. An unsorted file produces "parent does not exist" rejections that disappear when you replay it, which hides the real errors.

The special case of users in MAS 9

In IBM Maximo Application Suite, user identity is managed by the suite (MAS Core) and synchronized to Manage. Loading user records directly into Manage tables is therefore not enough: the user must exist on the suite side (administration console, administration API or LDAP / SAML directory), then receive their Manage attributes (security groups, default site, associated person). Plan this batch separately, with the security team.

Which tool to load with?

Four families of tools coexist on MAS 9:

• The MIF (Maximo Integration Framework): object structures and enterprise services, import of flat or XML files through the data import application. See the MIF guide.
• The REST API (/maximo/api/os/…): JSON calls authenticated by API key, suited to large volumes and automation. See the REST API guide.
• MxLoader: a community Excel workbook that calls the API; convenient for modest volumes. See MxLoader and its alternatives.
• An industrialized load tool such as MAS9, which adds pre-load validation, resume after interruption without duplicates, per-environment tracking and proof of arrival.

The choice depends less on the technology than on volume, the number of environments and the need for traceability. On a project with several hundred thousand rows and three environments, the ability to replay and prove becomes decisive.

Validate before loading

A rejection during the load costs ten times more than an error caught in the file. Check each file against the configuration of the target environment, not of a reference environment, because value lists and attributes often differ between DEV and PROD:

• columns known to the object structure and required attributes filled in;
• maximum lengths and types (dates, numbers, decimal separator);
• values belonging to the lists (statuses, types, priorities, units);
• references to parents and linked objects present in the target or in a file already loaded;
• duplicates within the file itself (same key twice).

Then run a test batch of a few dozen real rows to measure throughput and detect the business rules that only Maximo applies (automation scripts, conditions).

Mock loads and cutover

Each rehearsal must follow the production runbook exactly: same files, same order, same checks. Measure the duration of each step: it determines the cutover window. Plan for resume: a network outage or a restart in the middle of a 500,000-row load must neither lose rows nor create duplicates. The AddChange action (create or update depending on the key) makes a file safely repeatable.

After each load, reconcile: expected, loaded and rejected row counts, and read-back of a sample in Maximo. The guide data migration quality control details the method.

Data init checklist

1. Scope, volumes and business owners frozen.
2. Target model configured and identical on all environments (or differences listed).
3. Files produced in dependency order, hierarchies sorted.
4. Each file checked against the target environment.
5. Test batch, then full load tracked row by row.
6. Rejections fixed and replayed, with no duplicates.
7. Numeric reconciliation and signed business validation.
8. Runbook and durations measured for the production cutover.

Frequently asked questions