Both systems are up. Prove the data survived before you turn one off.

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.

The people who ran the migration have a conflict of interest in finding their own errors, and implementation vendors rarely spell out what didn’t come across. That leaves you with confidence resting on someone’s assurance instead of on evidence.

The moment matters as much as the method. Validate works while the on-prem source is still alive to compare against. Once that window closes and the old system goes dark, the comparison gets harder, and so does proving that what runs your business made it through.

Row counts matching is not the same as metric definitions surviving.

And you don’t take our word for it either. Every test is inspectable: the definition we pinned, the value we got on each side, the difference between them. Nothing is a black box. The result reads two ways, a confidence and integrity score for leadership, and the test-level detail underneath it, where you open a pillar, then a test, then the exact numbers that produced the verdict.

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. One for leadership, one for the people who act on the detail.
5. Be honest about the edges. What’s been directly checked against your pre-migration numbers, what’s profiled but not compared, and what sits outside scope and belongs to your migration team. No false all-clear.

This is the actual shape of a Validate report, run on synthetic data to illustrate it, not a real customer engagement. Two reads on one page: a score for leadership up top, the findings that produced it underneath.

The tables loaded clean. Row counts sat within a tenth of a percent, the kind of match a load-success report calls done. Validate kept going and found the production totals drifting half a percent, small enough to miss and large enough to move a KPI. That is the gap between data that loaded and data you can run a plant on.

A self-serve version of Validate is in development. It will check a single fact table against a capped sample of your own data, roughly 1,000 rows, so you can see the before/after comparison run against your own numbers instead of a synthetic example.

It will be scoped narrower than a full Validate engagement on purpose: one table, one comparison, enough to show you the mechanism firsthand. If it surfaces something worth chasing, the path from there is a full Validate engagement across every operational fact table.

Validate is a verdict from a moment: the day both systems were up and in sync, the data survived, here is the proof. That verdict is true when it’s rendered. It does not stay true on its own.

Definitions drift. Someone changes a reason code, a default, an integration, and six weeks later a number quietly means something else. OIM Vigil is how a point-in-time verdict becomes a standing state, the same checks run on a schedule so drift is caught before anyone acts on it.