The data load is a repeatable operation, not a one-shot event, because every entity type is safe to re-import and a reset takes you back to an empty plant. EDGEBIC by User Solutions is the next-generation successor to the RMDB, EDGEBI and RMX line, and moving onto it is a matter of running import masks rather than a wizard you get one attempt at. Which means the right number of times to load your plant before go-live is not one.
Why one shot is the wrong assumption
There is no migration wizard to sit through. There are saved masks, and you run them. That framing tends to make people either over-worry the first attempt or under-plan the whole phase, and both come from the same mistaken picture of a single irreversible event.
What actually happens is closer to a build: load, look, find the defect in the source file, fix it, load again. The loop is short. The only thing that makes it feel expensive is not knowing you are allowed to run it.
What makes a rehearsal safe
One property carries the whole idea. Re-importing the same file is safe for every entity type:
| Entity | Behavior on a second run |
|---|---|
| Master data | Comes back Reused, or Updated if you have enabled updates |
| Routings | Wiped and recreated identically |
| Actuals | Overwrite the same days with the same values, so nothing double-counts |
Nothing accumulates. Nothing needs undoing before you try again. A load you are unsure about is simply a load you run once more after fixing the file, which is exactly the property a rehearsal needs.
Getting back to an empty plant
Between rehearsals you want the plant blank rather than half-populated with the previous attempt. The Clear Data Tables utility does that in two modes.
Clear Selected Tables lets you tick specific areas, and each row expands to show what the clear cascades to. Use this mode routinely, and read the cascade rather than assuming it, because knowing exactly what a reset takes is the difference between a controlled rehearsal and a surprise.
Clear ALL Data is a full database wipe. The dialog enumerates what goes: schedules, actuals, orders, quotes, sales orders, products, routings, work centers, departments, shifts, holidays and per-user interface settings. You type CLEAR to confirm, and on success it offers to restart.
User accounts survive unless you additionally tick the option to clear users and the sign-in audit, in which case the administrator has to be re-created. So a rehearsal cycle does not normally cost you the security setup you built. The utility itself, including its guard rails and their limits, is covered in EDGEBIC clear data tables explained.
Take a backup before every clear. It is one click, it produces a timestamped file next to the database, it is safe even while the application is running, and a clear cannot be undone.
Where to rehearse
In a separate database, created from the data source screen, so the rehearsal never shares a file with anything you care about. That also lets a rehearsal survive while somebody else keeps working.
One warning about provider choice. The in-memory option looks like the natural home for practice work and is exactly the wrong choice: it is for testing and demonstrations only, and everything is lost on exit. A rehearsal you cannot come back to the next morning has not rehearsed the part that matters, which is reading the results carefully. If you also want a copy that outlives the migration for teaching people, that is a slightly different job and is set out in setting up a training copy of EDGEBIC.
A rehearsal has to reach the schedule
Imports change data and never produce a plan. So a rehearsal that ends at the import result dialog has proved that your files parse, and nothing more.
Run the scheduler. That is where the interesting failures live, and several of them look like import successes:
- An order for a product with no routing imports cleanly and then schedules as nothing.
- A work center created automatically from a routing file arrives with default settings and no shift attached, so it contributes capacity that is not there.
- A capacity model that is subtly wrong produces a plan that is plausible and off by days.
Capacity comes before dates in the checking order, because comparing a date against your current system is meaningless until the hours behind it agree. Then compare the plan, which is a comparison rather than a copy, as validating a migrated schedule against RMDB sets out.
The rule that only bites on the reload
One import behaves differently on a second run in a way that matters exactly here. A routing import wipes and recreates that end product's steps per run, so all of a product's steps must be in a single file. Split them across two files and the second run's wipe deletes the first run's steps.
During the first load a bad split can pass unnoticed because you are looking at everything at once. On the reload it produces a product whose routing is quietly missing its front half. Group your routing export by end product and confirm each product appears in exactly one file before the first rehearsal, not after the third. The wider ordering is in the order to import your data into EDGEBIC.
Three passes, three purposes
| Pass | Purpose | Output |
|---|---|---|
| First | Shape | A list of mapping, unit and mandatory-field defects |
| Second | Completeness and capacity | Corrected files loaded, hand-built configuration added, capacity agreed per work center |
| Third | Timing | A dress rehearsal on the real files, run by the person who will run it, timed |
Give each pass a different question and none of them feels like repetition. The second pass is also the natural place to add the configuration that has no mask behind it, because building it against a plant that already schedules lets you prove each piece changed the plan the way you expected. Feeding the first pass with files that are already clean shortens all three, which is the argument in a data-quality audit before migrating to EDGEBIC.
The takeaway
Plan the load as a loop rather than an event. Every entity type is safe to re-import, so a bad load costs a fix and a re-run rather than a recovery. Reset between passes with the clear utility, reading the cascade rather than assuming it, backing up first every time, and knowing that user accounts survive unless you deliberately clear them. Rehearse in a separate database and never in the in-memory provider. Run the scheduler each time, because a rehearsal that stops at the import dialog has tested your files rather than your plant. And settle the one-file-per-product routing rule before the first pass, since it only shows its teeth on the reload. See the platform on the EDGEBIC overview, the whole upgrade path on the RMDB to EDGEBIC guide, and pair this with preparing your EDGEBIC install before migrating.
Yes, for every entity type, and that is what makes a rehearsal possible. Master data comes back as Reused or Updated depending on your options, routing steps are wiped and recreated identically, and actuals overwrite the same days with the same values, so importing a file twice never double-counts. The safety is by design rather than by luck, and it means a load you are unsure about can simply be run again once the source file is fixed.
The Clear Data Tables utility, which has two modes. Clear Selected Tables lets you tick specific areas and expand each row to see what the clear cascades to, and Clear ALL Data is a full database wipe covering schedules, actuals, orders, quotes, sales orders, products, routings, work centers, departments, shifts, holidays and per-user interface settings. Either way you type CLEAR to confirm, and a full wipe offers a restart afterward. User accounts survive unless you also tick the option to clear users and the sign-in audit.
A separate one, created from the data source screen so the rehearsal never shares a file with anything you care about. There is one provider that looks like the obvious choice and is exactly wrong for this: the in-memory option is for testing and demonstrations only and loses everything on exit, so a rehearsal run there proves nothing you can come back to tomorrow. Take a backup before every reset regardless of which database you are in, since it is one click and a clear is not undoable.
Expert Q&A: Deep Dive
Q: Our project plan has one line that says load data. How many rehearsals is realistic, and what should each one be for?
A: Three is the number most plants land on, and giving each pass a different purpose is what stops them feeling like repetition. The first pass is about shape: run every mask once against real files and see what fails, which is almost always column mapping, units, or a mandatory field nobody thought about. Nothing is verified at this stage and that is fine, because the output you want is a list of defects in the source files. The second pass is about completeness and correctness: reload the corrected files, then set up the configuration that has no mask behind it, and compare capacity per work center against what your current system assumes before you look at a single date. The third pass is a timed dress rehearsal against the files you will actually use on the day, run start to finish by the person who will run it, so you learn how long the real thing takes and whether anything depends on somebody who will be on holiday. If your plan currently has one line for all of that, the honest revision is to split it into three shorter lines with a fix window between each, because the fixing is where the time goes and the loading itself is usually the quick part.
Q: What is the one thing people forget to include in a rehearsal?
A: Running the scheduler. Imports change data and never produce a plan, so a rehearsal that stops at the import result dialog has proved that your files parse and nothing else. That is a real result and it is the smaller half. The questions a migration actually needs answered are whether the capacity model is right and whether the resulting plan is defensible next to your current one, and neither of those exists until you schedule. It is also the step that surfaces the failures a clean import hides, because an order for a product with no routing imports perfectly and then schedules as nothing, and a work center created automatically from a routing file arrives with default settings and no shift attached, which shows up as capacity that is not there. Both look like import successes and both are scheduling problems, so the rehearsal has to run far enough to see them.
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.
Migrating From Microsoft Project to EDGEBIC
Project plans and production schedules answer different questions. Here is what maps across cleanly, the duplication you get to collapse, and how to reshape exported tasks into routings and orders.