Running RMDB and EDGEBIC Side by Side During the Transition

The safest way to adopt EDGEBIC is a parallel run: keep RMDB as your system of record while EDGEBIC schedules one cell, then expand as trust grows. In EDGEBIC by User Solutions, this works with no special infrastructure, because EDGEBIC imports its data from Excel or CSV. You export from Resource Manager DB and import into EDGEBIC on whatever cadence suits you. RMDB stays fully supported and unchanged, the plant keeps running on the schedule it trusts, and EDGEBIC proves itself on a small, controlled area before it owns anything.

Why a parallel run is the right default

Replacing a scheduling system in one move is a bet: if the new system models a capacity detail differently, the first anyone hears of it is a missed shipment. Very few shops can afford that risk on a schedule that currently works.

A parallel run removes the bet. RMDB, the proven classic of the line, stays in charge of the whole plant. EDGEBIC runs alongside it on one cell or product family. The plant never depends on EDGEBIC being right until you have watched it be right for weeks. Adoption becomes a series of small, reversible steps instead of a single cutover, which is exactly how a cautious operation should take on a new tool. This phased approach is built into the RMDB to EDGEBIC upgrade path.

It needs no special plumbing

The reason a parallel run is practical, not just prudent, is that EDGEBIC does not need to be wired into RMDB. The connection between the two is a file.

EDGEBIC reads the same kind of Excel and CSV exports RMDB has always produced. You export the products, work centers, routings, and orders for the pilot cell, and import them into EDGEBIC through saved import masks. There is no live link to build, no middleware, no integration project. When you want EDGEBIC to reflect the latest RMDB data, you re-run the masks. The mechanics of that import are in moving your RMDB routings into EDGEBIC and EDGEBIC import masks explained.

Keeping EDGEBIC current without double entry

During the overlap, RMDB stays the place you enter and maintain data. EDGEBIC is refreshed from it, not maintained in parallel by hand.

The refresh is the import mask. When orders or master data change in RMDB, export the affected entity and re-run the matching EDGEBIC mask, which remembers your column mapping so the refresh is one click. There is no double data entry: RMDB is the single source you maintain, and the mask is the pipe that carries a copy into EDGEBIC. You choose the cadence per entity: orders might refresh daily, while master data that rarely moves refreshes only when it changes.

A worked example

A shop wants EDGEBIC but cannot risk its working schedule. Management approves a parallel run on the CNC cell: three machines, about 40 active jobs.

1. RMDB stays in charge. The whole plant, including the CNC cell, keeps running on RMDB's schedule. Nothing operators do changes.
2. Stand up the EDGEBIC cell. The planner exports the CNC cell's products, work centers, routings, and open orders from RMDB, and imports them into EDGEBIC through four saved masks.
3. Schedule and compare. EDGEBIC schedules the cell. The planner lines up EDGEBIC's dates against RMDB's for the same jobs. Most match. Two differ.
4. Reconcile. The two differences trace to a shift calendar detail modeled slightly differently in EDGEBIC. The planner corrects the calendar, re-runs, and the dates converge.
5. Repeat, then widen. After several cycles with no surprises, management approves adding a second cell. RMDB is still the system of record; EDGEBIC's footprint just grew.

At no point was the plant's live schedule at risk, and every difference became a modeling insight rather than a production incident.

Differences are information, not failure

When EDGEBIC schedules the pilot cell differently than RMDB, resist reading it as a fault. During a parallel run, a difference is exactly what you are looking for, because it points at something modeled differently: a capacity number, a calendar rule, a routing time, a holiday. Reconciling it improves your model in both directions and is how the pilot builds real confidence.

This is why the comparison step matters. You are not just 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.

What the overlap actually costs

A common worry about running two systems is that it doubles the work. In practice it does not, because the two systems are not maintained independently. RMDB is where you enter and keep data, and EDGEBIC is refreshed from it through saved masks. The only genuinely new effort during the overlap is the comparison itself: a planner spending a few minutes each cycle checking EDGEBIC's dates for the pilot cell against RMDB's.

That comparison is not overhead; it is the whole value of the parallel run. Every difference it surfaces is a modeling detail reconciled, and every cycle with no differences is confidence earned. So the cost of the overlap is minutes of comparison per cycle, and the return is a validated model and a team that trusts the new system before it owns anything. Weighed against the risk of a blind cutover, that is a small price, which is why the parallel run is the recommended path rather than an optional nicety.

No forced cutover

There is no deadline in this process. RMDB stays fully supported for as long as you want it, so the parallel run lasts exactly as long as your team needs. You widen the pilot cell by cell only when the planners trust the results, and you complete the transition when EDGEBIC owns the schedule and RMDB has nothing left to prove. The timeline is yours, not a vendor's.

The takeaway

Running RMDB and EDGEBIC side by side is the low-risk way to adopt the next generation. RMDB stays the system of record while EDGEBIC proves itself on one cell, the connection is a file rather than a live link so there is no plumbing to build, and saved import masks keep EDGEBIC current with no double entry. Differences during the run are modeling insights, not failures, and there is no forced cutover, so you move at your own pace. Read the full path on the RMDB to EDGEBIC guide, see the platform in full on the EDGEBIC overview, and when you scope the pilot, start with planning an EDGEBIC pilot on one cell.