MAS 8.x end-of-support hit April 30, 2026. If you started your migration on time, you're probably somewhere between "mostly done" and "this is harder than we thought." If you haven't started, you already know you're behind.

I've been involved in MAS migrations across government, defense, pharma, utilities, and transit. The technology works. The failures are almost never about the platform itself. They come from the same places every time — and most of them were avoidable if someone had scoped the real work before the project kicked off.

Here's where MAS 9.x migrations actually fail.

The Data Quality Trap

Every Maximo environment accumulates data quality debt. It's not a question of whether yours has it — it's a question of how much and how long it's been compounding.

Orphaned asset records from equipment that was decommissioned years ago but never removed from the hierarchy. PM schedules pointing at locations that got renumbered in a reorganization. Duplicate location records from a merger that nobody fully consolidated. Classification structures that made sense in 2016 and have been worked around ever since.

In a stable environment, this debt is tolerable. The people who use the system know the workarounds. They know which location records are real and which are ghosts. They know that PM-4417 fires but doesn't need to be executed because the asset it references was scrapped three years ago.

A migration strips all of that tribal knowledge away. Every record gets pulled into the new environment at face value. The workarounds don't migrate — just the bad data they were working around. Suddenly your new MAS 9.x instance is full of orphaned references, broken PM schedules, and location hierarchies that don't reflect the actual plant.

The fix isn't complicated, but it has to be scoped and scheduled as real work inside the migration plan. Data cleansing before migration. Validation rules during migration. Verification after migration. If your migration plan doesn't have those three phases explicitly called out with owners and timelines, you're going to move the mess to a more expensive platform and wonder why things feel worse than before.

Customization Translation Is Not a Lift-and-Shift

This is the one that catches teams who've done Maximo upgrades before and assume a MAS migration is the same thing. It isn't.

MAS 9.x is a different deployment architecture. Automation scripts that worked in 7.6.1.x or MAS 8.x may behave differently or break entirely. Custom applications built on the classic Maximo UI framework need rework for the updated front end. Report customizations that referenced specific database views or table structures need to be validated against the new schema.

The right approach is inventory first. Before you start the migration, catalog every customization in your environment: automation scripts, custom apps, modified workflows, integration endpoints, report customizations, and any configuration that deviates from out-of-the-box. For each one, you need a disposition: does it carry forward as-is, does it need rewriting, or should you kill it?

That third option — kill it — is underused. Every migration is an opportunity to shed customizations that were built to solve problems that no longer exist, or that were never the right solution in the first place. But you can only make that call if you've inventoried everything and assessed each item against your actual operational requirements. Most teams skip the inventory, assume everything will carry over, and then spend months in staging chasing down failures that could have been resolved in a planning spreadsheet.

The Integration Graveyard

Integrations are the silent killer of migration timelines. They're discovered late because they're often owned by teams outside the Maximo program — IT infrastructure, third-party vendors, middleware teams — and nobody thought to include them in the migration scope.

The problem is architectural. MAS 9.x runs in a containerized environment. Integrations that were built to talk to specific on-prem endpoints, or that assumed a particular network topology, or that depend on middleware configurations tied to the old deployment — all of those need to be re-evaluated.

Third-party connectors add another layer. If your Maximo environment integrates with a CMMS, an ERP, a GIS, a building automation system, or any other enterprise platform, every one of those connections needs to be validated against the MAS 9.x deployment topology. Some vendors have updated their connectors. Some haven't. Some will tell you they have when they actually haven't tested against the specific MAS version you're deploying.

The fix is the same as customizations: inventory everything, assess each integration, and build the re-validation work into the migration plan with time and resources allocated. The integration inventory is the one most often missing from migration plans, and it's the one most likely to blow up your timeline in month four when something upstream breaks and nobody can explain why.

Governance: The Missing Operating Model

This is the failure mode that doesn't show up until after go-live — and by then, the migration project is over and the team has moved on.

Most organizations migrate the system but don't migrate the operating model. They move Maximo to MAS 9.x and assume the existing support processes still apply. They don't.

Who owns configuration management in the new containerized environment? Who approves changes to automation scripts or custom apps? What's the change control process for the deployment pipeline? Who validates that a data load didn't introduce the same quality problems you just spent six months cleaning up?

If those questions don't have clear answers with named owners before go-live, the new environment will drift the same way the old one did. The only difference is that it'll drift faster, because the team is less familiar with the new platform and there are fewer people who know where the guardrails should be.

The migration is the best opportunity you'll get to stand up a governance framework. The environment is fresh, the data is clean (if you did the cleansing work), and the team is paying attention. Build the operating model during the migration, not after it. If you want a framework for how that governance layer should work, the IMPACT System is built for exactly this.

What Actually Works

I've been doing this for 20+ years. Here's what I tell every organization starting a MAS migration:

Assess before you migrate. Understand your current environment's actual state — not what the documentation says, not what the last project team assumed, but what's actually there. Every customization, every integration, every data quality problem.

Inventory every customization and make a disposition decision for each one. Carry forward, rewrite, or kill. No exceptions, no "we'll figure it out later."

Clean data before you move it. Data cleansing is cheaper and safer in the source environment. Don't migrate garbage and try to fix it on the other side.

Build governance into the migration plan. Don't bolt it on after go-live. Define change control, configuration management ownership, and validation frameworks while the team is still assembled and paying attention.

Don't skip post-migration verification. Structured validation against real operational scenarios. Data integrity, workflow execution, integration round-trips, and user acceptance. "The login page loads" is not a go-live criterion.

If you need a Principal Maximo SME to help you plan and execute this the right way, that's what I do.