OIM Validate

Proof that your plant runs the same on the other side.

You’re moving to the cloud whether you were ready or not, and someone on the migration team has told you it’s fine. Validate is the independent, evidence-based answer you can actually sign off on: the full picture of what survived the move, before you commit to cutover.

What it is

OIM Validate takes your source on-prem data and your target cloud data, maps both schemas together, and tells you, field by field, what survived the move: what’s missing, what’s net new, what changed, where null rates drifted, where a type changed underneath you. Then it goes one step further than any row-count check. It re-computes the metrics that actually run your plant on both sides and shows whether they agree.

It is built for one part of the business on purpose: manufacturing operations. Production, downtime, maintenance, quality, inventory. The tables that feed OEE, throughput, MTBF, scrap rate, and schedule attainment. That focus is the point. It makes the answer sharp where a general-purpose migration test stays vague.

OIM Validate is the full engagement. OIM Verify is the narrow spot-check that checks a defined handful of metrics; Validate checks the whole move across the operational fact types. If you started with Verify, what you spent on it carries forward here.

Why it matters

There is no independent, third-party migration validation tool designed for this buyer. The consultants running the migration have a conflict of interest in finding their own errors. Implementation vendors are not transparent about what doesn’t come with the package. The result is a sign-off that rests on someone’s assurance rather than on evidence.

The moment matters as much as the method. This is a gate, not a steady-state monitor. It belongs in the weeks before go-live, while the on-prem system is still alive to compare against. Once that window closes, the comparison is gone, and so is your chance to prove the data that runs your business survived intact. Your data. Your history. Your DNA. Worth confirming before it’s the only copy left.

How I’d approach it
  1. Map both schemas. Declare the operational tables that feed the five fact types and align them across source and target, including the custom columns you opt in to, so nothing in scope is assumed rather than checked.
  2. Profile field by field. Row counts, null-rate drift, type changes, value-distribution stability. What’s missing, what’s net new, what quietly changed shape in the move.
  3. Run the metric battery. Re-compute OEE, throughput, MTBF, scrap rate, schedule attainment on both sides and compare. The rows copying is table stakes; the metrics agreeing is the real test.
  4. Deliver two reads. A CFO-readable report with a confidence / integrity score for the sign-off decision, plus deep-dive dashboards by business unit for the people who have to act on the detail.
  5. Be honest about the edges. What’s certified, what’s profiled-but-not-certified, and what sits outside the scope and belongs to your migration team. No false all-clear.
The thinking behind it
No. 016 TECHNICAL DIVES

Your Data Is Dirty and That’s Fine.

Real operational data is messy, and pretending otherwise is how validation lies to you. What it actually means to confront the data as it is, and report on it honestly, rather than scoring the version you wish you had.

Read the Dispatch →