Validating a Migrated Schedule Against RMDB

Validate a migrated schedule by verifying capacity first, then comparing EDGEBIC's dates against RMDB job by job, and treating every difference as a modeling detail to reconcile rather than a failure. In EDGEBIC by User Solutions, most dates should match, and the differences that remain are the useful part: each points at something modeled differently that you fix at the source. Validation is not about identical dates to the minute. It is about understanding why any difference exists.

Validation is the whole point of a parallel run

Running EDGEBIC alongside RMDB is not just caution, it is a test with an answer key. RMDB has scheduled these jobs, so its dates are a reference you already trust. Comparing EDGEBIC's dates against them tells you whether the migrated model behaves the way the proven one does, and where it does not, exactly what is different.

So validation is the reason the parallel run exists. You are not only checking that EDGEBIC works; you are aligning the two systems' view of the shop until they agree, so that when EDGEBIC eventually owns the schedule, it owns a model you have already validated against a system you trust. This is the discipline behind running RMDB and EDGEBIC side by side.

Verify capacity before you compare a single date

The first rule of validation is that capacity comes before dates. Effective capacity is shift hours times instances times efficiency, so any one of those being off shifts every date that touches the affected work center. Compare dates before confirming capacity and you flood the comparison with differences that all trace to one gap, a missing holiday, a wrong instance count, and you cannot see the real signal underneath.

So confirm EDGEBIC's available hours per work center match what RMDB assumed, work center by work center, before you read any dates. This collapses the noise. Once capacity matches, the differences that remain are specific and few, which is exactly what you want to reason about. This is the same capacity check that anchors migrating your work center and shift definitions to EDGEBIC, and it rests on finite versus infinite capacity scheduling.

Compare dates job by job

With capacity confirmed, line up EDGEBIC's dates against RMDB's for the same jobs in the cell. Most should match. For each that does not, ask what is different, and expect one of a short list of causes:

• A calendar detail. A shift or holiday defined slightly differently between the systems.
• A work center attribute. An instance count or efficiency factor that did not carry across exactly.
• A routing time. A setup or run time that changed, or a queue or move time modeled differently.
• A deliberate new behavior. EDGEBIC applying something RMDB did not, such as a sequence-dependent setup matrix or Theory of Constraints anchoring on a flagged bottleneck.

The first three are gaps to close. The fourth is an improvement to recognize. Telling them apart is the substance of validation.

Differences are information, not failure

When EDGEBIC schedules a job differently than RMDB, resist reading it as a fault. During validation a difference is exactly what you are looking for, because it points at something modeled differently, and reconciling it improves your model in both directions.

You reconcile by correcting the input and re-running, which is one click because the mask is saved. A difference you cannot explain, though, is a signal to keep digging, not something to accept. The failure mode to guard against is a plausible-looking date that is quietly wrong, so an unexplained difference is a flag to investigate before you trust the schedule.

A worked example

A shop validates its migrated CNC cell against RMDB.

1. Capacity first. The planner compares EDGEBIC's weekly hours per work center against RMDB. The mill matches. The grinder is short, which traces to a missing holiday; they add it and the grinder matches too.
2. Compare dates. With capacity aligned, they line up dates for 40 jobs. Thirty-four match exactly.
3. Reconcile the six. Four trace to a shift calendar off by an hour; corrected and re-run, they converge. Two remain different, and both trace to EDGEBIC applying a setup matrix that groups like colors, cutting a changeover RMDB did not model.
4. Classify. The four calendar differences were gaps, now closed. The two setup differences are improvements, now understood.
5. Trust. Nothing is left unexplained. The planner stops double-checking, and the cell is validated.

The dozens of differences a naive comparison would have shown never appeared, because capacity was reconciled first.

Trust comes from explained differences

The signal that a migrated schedule is validated is not a numeric tolerance. It is that every remaining difference is explained. EDGEBIC and RMDB do not have to produce identical dates to the minute; you have to understand why any difference exists.

Early on, differences trace to modeling details you reconcile, and the two systems converge. As they do, the planners stop finding unexplained differences and stop double-checking every date. That behavior change is the trust signal, and it is what tells you a cell is ready to widen, the rule at the heart of a phased migration plan to EDGEBIC. A remaining difference that traces to a deliberate improvement, like the setup matrix, is not a problem, so widen when nothing is left unexplained, not when a number hits a threshold. Costs need their own pass, because they feed the quote estimate rather than the plan: validating migrated cost data checks the imported material costs and labor rates against a hand calculation before sales quotes anyone.

Common pitfalls

• Comparing dates before capacity. The most common mistake, and the one that floods you with false differences. Capacity first, always.
• Chasing a tolerance instead of an explanation. Identical dates are not the goal; explained differences are.
• Accepting an unexplained difference. A date you cannot account for is a flag to investigate, not a rounding error to wave through.
• Missing name drift. A routing pointing at a mismatched work center name schedules oddly. Confirm names match, per cleaning your data before importing to EDGEBIC.

The takeaway

Validate a migrated schedule by verifying capacity first, then comparing EDGEBIC's dates against RMDB job by job and explaining every difference. Reconcile calendar, work center, and routing gaps at the source, and recognize deliberate new behaviors like setup matrices as improvements. Trust comes from explained differences, not identical dates, so widen when nothing is left unexplained. See the platform in full on the EDGEBIC overview, read the whole path on the RMDB to EDGEBIC guide, and fold validation into a phased migration plan to EDGEBIC.