Migrating From an Abandoned MRP Scheduling Module to EDGEBIC

Migrating from an abandoned MRP scheduling module to EDGEBIC means moving the master data the ERP holds correctly plus the shadow spreadsheet that carries the real plan into a finite capacity engine that produces runnable dates. EDGEBIC by User Solutions is the next-generation successor to RMDB, EDGEBI, and RMX, and it fills the exact gap the MRP module left: scheduling that respects what each work center can actually do. The migration is less about ripping out the ERP and more about giving the plan a home the floor will trust.

Why the MRP module got abandoned

Almost every abandoned MRP scheduling module fails for the same reason: it assumes infinite capacity. It backschedules from due dates and cheerfully plans three jobs onto one machine in the same shift, because it never checks whether the machine can run them. The plan prints, the floor glances at it, sees dates that cannot happen, and goes back to the spreadsheet. This is the difference between finite and infinite capacity, and it is the single most common reason an ERP scheduling module ends up as shelfware.

So the situation you are actually in is a split: the ERP holds the master data (items, work centers, routings, open orders), and a spreadsheet holds the real, hand-adjusted schedule. The migration has to bring both.

What the ERP still gets right

Do not throw out the ERP. Its scheduling module failed, but its master data is usually sound. The ERP knows what you make, the bill of material, the routing sequence, and the open order book. That is genuine, structured data you can export.

Pull it out through the ERP's standard reports into Excel or CSV, and bring it into EDGEBIC through the built-in import masks. There is no native certified connector, and you do not need one: a mapped Excel or CSV mask, configured once per data type, moves items, work centers, routings, and orders reliably. This is the same export-then-import path any migration uses.

What the spreadsheet is really carrying

The spreadsheet is where the abandoned module's failure got patched by hand. When you look closely, the planner logic in it is almost always three things the MRP module could not express:

Real times. Actual run time per piece and setup time per operation, not the ERP's stale standards. The planner learned these on the floor and typed them into cells.

The true routing. The real operation sequence, including which alternate machines can substitute when the primary is busy. The ERP routing is often simplified; the spreadsheet holds the working version.

The constraint. Which work center is the bottleneck, so the planner sequences around it. The MRP module treated every resource as infinite, so it never knew.

All three are first-class in EDGEBIC. The migration is the interview that extracts them from the spreadsheet and the planner's head into the routing and work center master data, exactly as a spreadsheet-scheduler migration does.

Putting the two sources together

The move combines a data export and an interview.

Note the last row: shift calendars are set up inside EDGEBIC, not imported. That suits this migration because your working hours are simple and you enter them once.

The reconciliation to watch is between the ERP's routing times and the spreadsheet's. Where they disagree, the spreadsheet is usually right, because it was corrected by someone watching the floor. Use the ERP for structure and the spreadsheet for reality.

Prove it is runnable, then let the floor decide

The floor abandoned the last module because its dates were fiction. The only way EDGEBIC avoids the same fate is by producing dates that hold. So prove it before you roll it out.

Pick one busy cell, schedule it in EDGEBIC, and reconcile the plan against what your best planner produces in the spreadsheet for the same jobs. When the EDGEBIC dates match the planner's judgment and then hold on the floor, trust follows. This one-cell pilot is the entire argument, because a finite capacity plan that runs is self-evidently different from an infinite capacity plan that does not. EDGEBIC also flags the constraint work center explicitly, which the spreadsheet planner had to hold in their head.

The honest scope

Two boundaries to set. First, EDGEBIC is a scheduling engine, not a replacement for your ERP's transactional core: it schedules, and it exchanges data with the ERP through masks, so you keep the ERP for what it does well. Second, the effort here is the interview that extracts spreadsheet logic into master data, not the import itself. Budget real hours with the planner who owns the spreadsheet, because that logic is the asset you are preserving.

The takeaway

To migrate from an abandoned MRP scheduling module to EDGEBIC, export the ERP master data through Excel or CSV masks, interview the spreadsheet to recover the real times, routings, alternates, and constraint, configure shifts in the application, and prove runnable dates on one cell before the floor commits. The MRP module failed because it assumed infinite capacity; EDGEBIC succeeds because it does not. See the platform on the EDGEBIC overview, read the upgrade path on the RMDB to EDGEBIC guide, and compare notes with migrating from a spreadsheet scheduler to EDGEBIC.