Migrating to EDGEBIC is a data project with a short technical core and a longer human one. The technical core is straightforward: eight entity types import through saved masks, a handful of configuration areas are built by hand, and the schedule is validated against jobs you already understand. The longer part is deciding what to bring, what to leave, and how the plant learns to trust a plan that respects capacity limits their old system did not enforce.
This guide maps the whole path, whether you are coming from RMDB, from EDGEBI, from a homegrown spreadsheet, or from a magnet board on a wall. EDGEBIC by User Solutions is the current generation of a scheduling lineage that dates to 1991, so for existing customers this is an upgrade with a known shape rather than a leap.
Start by Knowing What You Have
Before you clean or import anything, assess. A data-quality audit before migrating is a read-only pass that scores your data's readiness and produces a findings list, so you learn the size of the job before you commit to a date. It is the difference between a plan and a hope.
The audit tells you where you sit on the one axis that matters: do complete routings exist, with a work center and a setup and run time on every step. A finite capacity engine cannot schedule without them. Everything else is recoverable.
Then decide what is actually in scope. What you do not need to migrate is usually the most valuable hour of the whole project, because most shops carry a decade of dead part numbers, closed jobs, and customers who left. Migrating them costs time twice: once to move, once to work around.
Finally, name the people. Who you need on your migration team is short, typically a planner who owns the data, someone who can pull exports, and a supervisor who represents the floor.
What Carries Forward, and What Does Not
The honest inventory matters more here than anywhere else, because a surprise at cutover is expensive.
What carries forward from RMDB to EDGEBIC, and what is new is the reference, and the RMDB to EDGEBIC feature-parity map is the detail. Existing EDGEBI users have their own version in what EDGEBI users gain in EDGEBIC. Because vocabulary changed along with the engine, the RMDB to EDGEBIC terminology crosswalk is worth reading before anyone starts arguing about what a word means.
The hard boundary: eight entity types import. Product, Workcenter, Customer, SalesOrder, BOR, Actuals, PlantHoliday, and Shift. Everything outside that is hand-built, and what EDGEBIC cannot import, and how to handle it covers the practical handling. Note that PlantHoliday and Shift are two of the eight, so migrating your work center and shift definitions can be an import. Typing a few shift patterns by hand is a legitimate choice when you only have a few, not a requirement.
The features that are genuinely hand-built each have a migration post of their own, because each is a small project:
- Migrating work center groups, including the per-member factor
- Migrating operators and skills, with certifications and rosters
- Migrating your setup matrix, which has an export but no import
- Migrating quotes and quote history
- Migrating your tools and fixtures
- Migrating alternate work center routings
- Migrating capacity and utilization settings
Preparing and Loading the Data
With scope settled, the sequence is mechanical.
Prepare your EDGEBIC install before migrating so there is somewhere for the data to land. Then export your RMDB or EDGEBI data to Excel, and clean it before importing, guided by the audit findings rather than by instinct.
Order matters, because records reference each other. The order to import your data into EDGEBIC is the sequence to follow: foundation entities first, routings next, demand last. Getting this wrong produces a routing import full of failed rows pointing at work centers that do not exist yet.
Routings are the centerpiece, and moving your RMDB routings into EDGEBIC covers the specifics, including the behavior that catches people out: a BOR re-import replaces that product's entire routing per run, so all of one product's steps must arrive in one file. Migrating your item and customer master and migrating open jobs and their actuals complete the load.
Before you do any of it for real, rehearse the migration load on a copy. A rehearsal converts unknown risk into a list of known fixes, and it is the cheapest hour in the project.
Coming From Somewhere Other Than RMDB
Not every migration is an upgrade. Four common origins have their own path:
- Migrating from a homegrown spreadsheet scheduler, where the routing knowledge exists but lives in formulas and one person's head
- Migrating from a whiteboard or magnet board, where nothing is written down and the first job is capturing it
- Migrating from an abandoned MRP scheduling module, where the data exists but nobody trusts the dates
- Migrating from Microsoft Project, where the plan is task-shaped rather than resource-shaped
There is also a growth path within the User Solutions line: from Excel and RMX to EDGEBIC covers moving up when a spreadsheet-based tool stops being enough.
Piloting, Cutting Over, and Proving It
Do not go live everywhere at once. Plan an EDGEBIC pilot on one cell so a small, well-understood area proves the model before the whole plant depends on it. A pilot surfaces data problems on a scale you can actually fix.
Then choose a shape. A phased migration plan and a week-by-week migration timeline give you two ways to structure the same work, and the EDGEBIC migration checklist is the thing you actually tick off. Keep a rollback and safety plan so that reverting is a decision you have already thought through rather than an emergency.
Running RMDB and EDGEBIC side by side during the transition is the pattern that makes all of this safe. It also gives you the comparison you need for validating a migrated schedule against RMDB. Costing carries its own check: validating migrated cost data, remembering that EDGEBIC costs labor and material only.
When the plan is trusted, complete the cutover. Then the part people forget: training your team on the EDGEBIC engine. Planners coming from an infinite-capacity tool need to unlearn one habit above all, which is treating a date as a promise rather than as the output of a capacity model. Finally, your first 30 days after cutover covers the settling period, where actuals start arriving and the schedule begins to reflect the floor rather than the plan.
What the Work Actually Costs
It helps to know where the hours go, because the intuition most people bring is wrong in both directions. They over-estimate the software work and under-estimate the data work.
The import masks are quick. Building a mask means picking an entity type and dragging your file's column headings onto EDGEBIC's fields. A first mask takes perhaps half an hour while you learn the screen, and later ones take minutes. Four masks cover most shops. This is not the hard part, and treating it as the hard part is how projects get planned wrong.
The routing data is the project. If your routings are complete, the load is nearly mechanical. If they are not, you are not doing a migration, you are doing an industrial engineering exercise with a migration attached, and the honest timeline reflects that. The audit exists to tell you which of those two projects you are on before you commit to a date.
The hand-built configuration is small but real. Groups, operators, the setup matrix, and tooling are typing, not analysis, and a shop with twenty machines and fifteen operators finishes them in an afternoon. They only hurt when they are discovered during cutover week rather than scheduled in advance.
Training is the tail. Loading the data is finished on a known day. Getting planners to read a capacity-respecting date as information rather than as an obstacle takes a few weeks of live use, and it is why the first 30 days are treated as part of the migration rather than as afterwards.
The One Thing That Decides the Outcome
Every migration that goes badly goes badly for the same reason: routing data that was good enough for a system which did not enforce capacity turns out to be too thin for one that does. A blank setup time was invisible when a planner filled the gap by habit. A routing that stopped at the last operation anyone cared about was fine when nothing downstream was being planned. Neither is invisible to a finite capacity engine, which schedules exactly what it is told and nothing more.
The characteristic symptom is a schedule that looks almost right, with a handful of jobs landing on dates nobody can explain. Traced back, those dates are nearly always a real input: a machine modeled with one shift when it runs two, a setup time entered in minutes into a field expecting hours, a work center that exists in the ERP as two cost centers and in the plant as one machine. None of those are software defects, and all of them are findable in an hour once you know to look.
That is why the audit comes first and the pilot comes before the cutover. Neither step is bureaucracy. They are how you find, on your own schedule and at a size you can handle, the specific fields that were quietly wrong all along, and how you build the habit of asking why a date moved instead of assuming the schedule is broken.
Where This Fits
Once you are live, the rest of the platform is the destination rather than the journey. The complete EDGEBIC guide maps everything, the scheduling engine guide explains how the plan is built, the ERP integration guide covers keeping data current afterwards, and the troubleshooting guide answers the "why does the schedule look wrong" questions that arrive in the first month.
For the product-level comparison, see the RMDB to EDGEBIC page and the EDGEBIC overview. If you want a read on your own data before committing to a date, contact US with an export and ask for the audit view. It is the cheapest way to find out how big your migration really is.
For a mid-size shop with reasonable routing data, the realistic range is two to six weeks of part-time work, not a full-time project. The pattern that works is a phased one: audit the data, clean the gaps that block scheduling, import in dependency order, pilot on one cell, then cut over. The heaviest single task is building the import masks, which is a one-time job measured in hours. Shops with thin or missing routing data should plan longer, because the routings have to exist before anything can be scheduled.
The data you would expect carries forward through the import masks: products, work centers, customers, sales orders and jobs, routings, actuals, plant holidays, and shifts. Those eight entity types are exactly what the masks cover. Your scheduling logic does not carry forward as configuration, because EDGEBIC's engine is a different generation, and several things that were hand-managed in RMDB are now real features. The practical carry-forward is your master data and your operating knowledge, not your settings.
Departments, work center groups and their members, operators with their skills, certifications, rosters, and time off, the sequence-dependent setup matrix, and quotes and scenarios are all hand-built. None of them have import masks. This is not a large amount of typing for most shops, but it is real work that belongs in the plan rather than in a surprise during cutover week.
No. Running the old system and EDGEBIC side by side through the transition is the recommended pattern, not a fallback. It gives you a live comparison to validate against, it means a rollback is a decision rather than a crisis, and it lets the floor learn the new schedule before it depends on it. The side-by-side period ends when the new schedule is consistently the one people follow.
Expert Q&A: Deep Dive
Q: Our routing data in the old system is patchy and everyone knows it. Do we clean it first or import it and fix it in EDGEBIC?
A: Audit first, clean the blocking gaps, then import, and do not try to clean everything. The finite capacity engine cannot schedule a product with no routing, no work center on a step, or no setup and run times, so those gaps are hard blockers and they have to be fixed before the data is useful. Everything else is a preference. The efficient method is to sort products by volume and fix the busiest hundred by hand, because those drive most of the schedule, then run exception filters across the whole set for the specific defects that block scheduling. That gives you verified data where it matters and a screened set everywhere else. Importing known-bad data and fixing it in place is slower, because you end up debugging a strange schedule date backwards to a missing time value instead of catching it in a spreadsheet filter. The migration is also the one moment when everyone accepts that data cleanup is the job, which is worth using.
Q: How do we know the new schedule is right, rather than just different from the old one?
A: You validate against reality, not against the old system's output, and you do it on jobs you personally know. Pick a handful of jobs whose real behavior you can recite: how long the setup takes, which machine actually runs them, when they usually ship. If EDGEBIC's plan matches those, the model is sound and the unfamiliar jobs are trustworthy by the same model. Where it disagrees with the old schedule, ask why rather than assuming a defect, because in most cases the difference traces to a real constraint the old system did not enforce, such as a machine that only has one shift or a setup time nobody had entered. That is the schedule doing its job. A running side-by-side comparison for a few weeks makes this concrete: the disagreements become a short list of specific inputs to check, and once that list empties, the plan has earned trust with the floor as well as with you.
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 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.
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.