Completing the Cutover to EDGEBIC

Complete the cutover to EDGEBIC on the trust signal, not a deadline: let short jobs drain on RMDB, import new work clean, and make EDGEBIC the system of record when it has earned it cell by cell. In EDGEBIC by User Solutions, the cutover is the quiet last step of a phased migration rather than a big-bang switch, because most of the plant is already scheduling in parallel by the time you reach it. RMDB stays fully supported afterward, so you keep it in reserve for as long as its reassurance is worth having.

The cutover is small because the phases did the work

In a phased migration, the day EDGEBIC becomes the system of record is anticlimactic, and that is the goal. By the time you reach it, EDGEBIC has been scheduling most of the plant in parallel, and its dates have earned trust one cell at a time. Making it the system of record is mostly a decision and a handoff, not a leap.

This is the opposite of a big-bang cutover, where every modeling difference surfaces at once as a production problem. Here, the risk was spent earlier, in the phases, so nothing large happens on the day. The whole arc that leads to this point is a phased migration plan to EDGEBIC, and it sits inside the RMDB to EDGEBIC guide.

What actually happens on the day

The cutover is a short sequence of confirmations, not a rebuild.

1. Confirm the last cell holds. The final cell's dates have been validated against RMDB and the planners have stopped double-checking. That trust signal is the green light.
2. Let short jobs finish on RMDB. In-flight jobs already scheduled on RMDB complete where they are. You do not migrate them.
3. Import current open orders clean. New jobs that have not started come into EDGEBIC as open orders, with no actuals to reconcile.
4. Carry the few long jobs across. The handful of long jobs that cannot wait come over with their progress, where EDGEBIC preserves completed work and schedules the rest forward. The mechanism is in migrating open jobs and actuals to EDGEBIC.
5. EDGEBIC becomes the plan. From this point, EDGEBIC is the schedule the plant works to, and the kiosk feeds actuals into every reschedule.

Drawing the cutover line at job boundaries means almost no partial state has to move, which is exactly what keeps the switch safe.

The trust signal, not a date

There is no forced cutover date, because RMDB and EDGEBI remain fully supported. You complete the transition on the trust signal for the last cell, the same behavioral signal that governed every phase: the planners stop finding unexplained differences and stop double-checking every date.

Chasing a fixed go-live date instead of that signal is how migrations get forced before they are ready. The phased approach exists precisely so you do not have to. When the last cell has earned trust the way every cell before it did, the cutover is simply the recognition that EDGEBIC now owns the schedule. Reading that signal is covered in validating a migrated schedule against RMDB.

Keep RMDB in reserve

Cutover does not mean switching RMDB off. It stays supported and available, and in the first weeks after cutover it is a safety net. If a question comes up about how a job was scheduled, you have the old system to check against, and its historical record is intact.

Over time, as EDGEBIC accumulates its own history and the team stops referring back, RMDB naturally falls out of daily use. There is no moment you are forced to retire it, so most shops simply let it go quiet rather than decommissioning it on a date. That is the point of the supported-in-parallel model: you are never pushed off something that worked before the replacement has fully earned its place, and you keep the fallback for as long as the reassurance is worth having.

What changes for the planners after cutover

Once EDGEBIC is the system of record, the daily workflow consolidates. The planner builds and edits routings as flow charts, schedules from the diagram, drags jobs on the interactive Gantt, and reads planned-versus-actual, all in one application rather than hopping between tools. Reschedules preserve completed work automatically, because the kiosk reports it, so a drag to reschedule moves only what has not happened yet.

The optimizer becomes part of the rhythm too: before publishing a plan, the planner can run it, review a side-by-side comparison, and accept or discard a proposed improvement. Nothing changes without the planner's decision, which keeps them in control the same way they always were. What turns that workflow into a habit is the month after the switch, covered in your first 30 days on EDGEBIC after cutover.

Common pitfalls

• Cutting over on a date instead of the trust signal. Forcing go-live before the last cell is solid carries an unresolved gap into production. Wait for the signal.
• Migrating too much WIP. Move as little partial work as possible; let short jobs finish on RMDB.
• Decommissioning RMDB immediately. Keep it in reserve. There is no reason to retire it on a schedule.
• Skipping the final capacity check. Confirm the last cell's capacity matches before you rely on its dates, per migrating your work center and shift definitions to EDGEBIC.

The takeaway

Completing the cutover to EDGEBIC is the quiet last step of a phased migration, not a big-bang switch. Confirm the last cell holds, let short jobs finish on RMDB, import new work clean, carry the few long jobs across with their progress, and make EDGEBIC the system of record on the trust signal rather than a deadline. Keep RMDB in reserve for as long as its reassurance is worth having, because it stays fully supported. See the platform in full on the EDGEBIC overview, read the whole path on the RMDB to EDGEBIC guide, and look back at running RMDB and EDGEBIC side by side for the parallel run that leads here.