A Rollback and Safety Plan for Your EDGEBIC Migration
User Solutions TeamA rollback and safety plan for your EDGEBIC migration rests on one fact: the migration is additive and non-destructive, so your old system stays live and authoritative until EDGEBIC has earned trust. In EDGEBIC by User Solutions, data moves through repeatable import masks into a separate install, leaving your current system untouched. Rollback is not a restore from backup, because nothing was overwritten. It is simply continuing to schedule where you already do while EDGEBIC runs in parallel. The worst realistic outcome is a delay in switching, never a stranded plant.
The safest migration has nothing to undo
Most migration fear comes from the picture of a rip-and-replace: the old system is converted, the new one goes live, and if it breaks you are stuck. An EDGEBIC migration is not that shape. You export copies of your data and import them into a separate EDGEBIC install through built-in Excel and CSV masks. Your current system is never modified. Its live schedule keeps running exactly as before.
That single design choice is the foundation of the whole safety plan. Because there is no destructive step, there is no destructive step to undo. Rollback means keeping the old plan authoritative, which requires no action at all beyond a decision not to switch yet. This is the practical meaning of an upgrade that is continuity rather than replacement.
The three realistic failure points
A safety plan should name what can actually go wrong. For an EDGEBIC migration there are three, and none of them can strand the plant.
Bad imported data. A wrong instance count, a missing setup time, or a mismapped column produces a schedule that looks off. The guard is to validate load and dates on a small pilot before trusting anything, and to re-import corrected data, since the mask is repeatable and you can run it as many times as needed.
A capability gap. A way you scheduled in the old system that you have not yet reproduced in EDGEBIC. The guard is the parallel run: while the old system stays authoritative, the gap is an item to solve on your own timeline, not an outage.
People not trusting the new plan. Real and human. The guard is again the parallel run, because trust is built by watching EDGEBIC match the old plan over weeks, which a cutover date cannot manufacture.
Notice the pattern: two of the three guards are the parallel run, and the third is a repeatable re-import. Neither touches the old system.
The parallel-run safety period
Running the old system and EDGEBIC side by side is the core of the plan, and it works because both schedule the same orders while only one is authoritative.
| Element | During parallel run |
|---|---|
| Old system | Fully installed, supported, and authoritative |
| EDGEBIC | Separate install, scheduling the same orders for comparison |
| Shop floor | Follows the old system's plan, unchanged |
| Data flow | Copies exported and imported into EDGEBIC, repeatable |
| Authority | Old plan, until you decide to switch |
The detailed mechanics of this are covered in running RMDB and EDGEBIC side by side. For the safety plan specifically, the point is that the shop floor never depends on EDGEBIC during this period. It is a comparison exercise, not a live handover.
What to test before you trust the switch
The parallel run is only useful if you deliberately test the events that matter. Do not just let it idle. Put EDGEBIC through the situations your plant actually faces and confirm it produces a plan your planners agree with.
- A machine goes down: mark it and reschedule, and check the new plan is sound.
- A hot order arrives: insert it and confirm the engine respects due dates and capacity.
- A routing change: edit it and reschedule.
- A normal reschedule with actuals: confirm completed work stays put and only future work moves.
Each of these is a chance for a capability gap to surface while the old system still carries the load. The parallel period ends when EDGEBIC handles all of them to your satisfaction, not when a calendar date arrives. This is the same event-driven readiness thinking behind validating a migrated schedule against RMDB.
The cutover decision, and how to reverse it
When you switch which plan is authoritative, you are making a decision, not performing a conversion. That matters for reversibility. If, after switching, something surfaces that you want more time on, you switch authority back to the old system, which is still installed and supported. There is no data to migrate back, because the old system was never modified and its schedule never stopped.
Keep the old system live for an agreed period after cutover, not just up to it. A few weeks of the old system running quietly in reserve costs nothing and gives you a genuine fallback for anything the parallel run did not surface. Retire it only when EDGEBIC has run the plant through real events without needing it. The full sequence is laid out in completing the cutover to EDGEBIC.
The takeaway
A rollback and safety plan for your EDGEBIC migration is built on the migration being additive: your old system stays installed, supported, and authoritative while EDGEBIC runs in parallel on copies of your data. The three real failure points, bad data, a capability gap, and low trust, are all guarded by the parallel run and a repeatable re-import, none of which touch the old system. Rollback is a decision to keep the old plan authoritative, not a restore, so the worst case is a delayed switch, never a stranded plant. See the platform on the EDGEBIC overview, read the upgrade path on the RMDB to EDGEBIC guide, and set up the safety period with running RMDB and EDGEBIC side by side.
Expert Q&A: Deep Dive
Q: Management will not approve the move without a clear answer to what happens if it goes wrong on cutover day. What do we tell them?
A: Tell them there is no cliff to fall off, because the design has no destructive step. The old system is not uninstalled, converted, or modified during the migration; it keeps running and stays fully supported. EDGEBIC is a separate install fed by copies of your data through repeatable import masks. So on cutover day, going wrong does not mean a stranded plant, it means you keep scheduling in the old system exactly as you did yesterday while you sort out the EDGEBIC issue. There is nothing to restore from backup because nothing was overwritten. If the EDGEBIC data needs a fix, you correct the source spreadsheet and re-import, which you can do as many times as needed. The worst realistic outcome is a delay in switching, not a loss of the ability to schedule. That is the difference between an additive upgrade and a rip-and-replace, and it is why the old system staying live is the whole safety plan.
Q: What are the actual failure points during migration, and how do we protect against each one?
A: There are three realistic failure points, and each has a simple guard. The first is bad imported data, a wrong instance count or a missing setup time, which shows up as a schedule that looks off; you protect against it by validating load and dates on a pilot cell before trusting anything, and by re-importing corrected data since the mask is repeatable. The second is a capability gap, a way you scheduled in the old system that you have not yet reproduced in EDGEBIC; you protect against it by keeping the old system authoritative during parallel run so the gap is an item to solve, not an outage. The third is people not trusting the new plan, which is real and protected against by the parallel run itself, because seeing EDGEBIC match the old plan over weeks builds the trust that a cutover date cannot manufacture. None of the three can strand the plant, because the old system is always there to schedule against.
Frequently Asked Questions
Ready to Transform Your Production Scheduling?
User Solutions has been helping manufacturers optimize their production schedules for over 35 years. One-time license, 5-day implementation.
User Solutions Team
Manufacturing Software Experts
User Solutions has been developing production planning and scheduling software for manufacturers since 1991. Our team combines 35+ years of manufacturing software expertise with deep industry knowledge to help factories optimize their operations.
Share this article
Related Articles
Migrating to EDGEBIC: The Complete Guide
The full path from RMDB, EDGEBI, a spreadsheet, or a whiteboard to EDGEBIC: what carries forward, what is hand-built, the import order, and how to validate the first schedule.
Migrating Your Tools and Fixtures to EDGEBIC
Tools and fixtures are not one of the eight import masks, so you build the list by hand. Here is what to enter, the quantity rule that ruins schedules when it is wrong, and where tools belong in the migration sequence.
Rehearsing Your EDGEBIC Migration Load
The data load is a repeatable operation, not a one-shot event. Every entity type is safe to re-import, and a reset takes you back to an empty plant, so plan to load your data three times before go-live.