Every Ellipse-to-Maximo migration I’ve been near has hit the same wall, and it’s never the one the project plan anticipated. The plan accounts for data mapping, field-by-field. It accounts for user training. It accounts for integration replumbing. What it doesn’t account for is that Ellipse and Maximo disagree, fundamentally, about what an “asset” is and where it lives in a hierarchy.

The result is a migration that passes every unit test — every field maps, every record transfers, every validation checks out — and produces a Maximo instance where the maintenance planners can’t find anything and the reports are wrong.

How Ellipse thinks about assets

Ellipse (originally Mincom, later ABB, now Hitachi Energy) was built for mining. Its data model reflects how mining operations actually think about their equipment: a piece of plant exists as an entry in the equipment register, identified by an equipment reference number. That equipment has a position — where it’s currently installed — and a class that determines its maintenance strategy.

The key concept in Ellipse is that the equipment register is the master. The equipment exists as an entity regardless of where it’s installed. A crusher motor is crusher motor MOT-4521 whether it’s installed in Crusher 1, Crusher 2, or sitting in the warehouse as a spare. Its maintenance history follows the motor, not the position.

Position is a secondary attribute. You can query “what’s installed at position CR01-DRV-MOT” to find what motor is currently there, but the history of that motor — its failure records, its maintenance completions, its condition data — lives on the equipment record, not on the position.

How Maximo thinks about assets

Maximo has two core entities: Locations and Assets. Locations represent functional positions in a hierarchy — Site → Building → Floor → Room, or in mining terms, Site → Processing Area → Circuit → Equipment Position. Assets represent physical things that can be installed at a location.

The catch is that Maximo’s hierarchy is location-driven. The location hierarchy is the primary navigation structure. Reports, work orders, and failure analysis are typically run against the location hierarchy. An asset installed at a location inherits context from that location, and when the asset moves, its visibility in the hierarchy changes.

In Ellipse, you navigate the equipment register. In Maximo, you navigate the location tree. This sounds like a UI difference. It’s actually a data model difference that breaks three things during migration.

What breaks

1. Rotable spares lose their identity

In Ellipse, a rotable spare — a motor, a gearbox, a pump — maintains a continuous history as it moves between positions. Motor MOT-4521 has a single maintenance history covering every position it’s occupied. This is critical for condition monitoring and warranty tracking.

In Maximo, when an asset is moved from one location to another, the history stays with the asset record — in theory. In practice, many Maximo implementations are configured to track work orders against locations rather than assets. When MOT-4521 is deinstalled from Location CR01-DRV-MOT and installed at CR02-DRV-MOT, the work orders raised against the old location don’t automatically appear when someone queries the asset’s history. The history is fragmented across locations unless the implementation specifically tracks asset-level work orders and the users consistently select the asset (not just the location) when raising work orders.

2. The hierarchy depth doesn’t match

Ellipse’s equipment register is relatively flat. Equipment sits in a register with a position reference and a class. There’s no enforced hierarchy depth — a pump is a pump, whether it’s a main process pump or a sump pump.

Maximo’s location hierarchy is deep by design. A typical mining implementation has 5–7 levels: Site → Area → System → Sub-system → Position → Sub-position. Every piece of equipment needs to be slotted into this hierarchy. Equipment that was a flat register entry in Ellipse now needs a location path, and creating that path for thousands of assets is a manual exercise that requires process knowledge the migration team often doesn’t have.

The shortcut — dumping everything into a shallow hierarchy — creates a Maximo instance that works but is unusable for hierarchical reporting. Failure analysis by area, system-level reliability metrics, and parent-child rollup reports all depend on the hierarchy being correctly structured.

3. Equipment class vs. classification

Ellipse’s equipment class is a first-class concept that drives maintenance strategy. Class CR (Crusher) has different scheduled maintenance tasks than class CV (Conveyor). The class-to-maintenance-strategy link is direct.

Maximo uses Classification (taxonomy) and Job Plans for a similar purpose, but the link is indirect. You classify an asset, then associate the classification with a job plan through a PM record. The mapping from Ellipse’s class-based maintenance to Maximo’s classification-to-PM chain requires rebuilding every maintenance schedule, not just transferring data.

What this means for the data pipeline

If you’re building a data warehouse that needs to survive this migration — or worse, needs to present a unified view across the transition — you have a mapping problem that goes beyond field-level transformation.

Equipment identity continuity. You need a mapping table that links Ellipse equipment reference numbers to Maximo asset numbers, and that table needs to be maintained as assets are created, merged, or retired during the transition. Without it, your analytics lose continuity across the migration date.

Hierarchy reconciliation. If your reports use location hierarchy for drill-down (area → system → equipment), the hierarchy structure will change during migration. Build your reports against a logical hierarchy in the data warehouse, not against the source system’s native hierarchy. Populate it from Ellipse before migration and from Maximo after.

Dual-source period. Every migration has a period where both systems are running. During that period, some assets are in Ellipse and some are in Maximo. Your pipeline needs to ingest from both, deduplicate, and present a single view. Plan for this to last longer than the project plan says — I’ve never seen one finish on time.

The migration is a data mapping exercise on paper. In practice, it’s a negotiation between two different models of what an asset is. The data engineer who understands both models is the one who keeps the analytics running through the transition.