What You Do Not Need to Migrate to EDGEBIC

Half of a smooth EDGEBIC migration is knowing what to leave behind: schedules regenerate, dormant items stay put, and closed history stays in RMDB, so you migrate only the master data and open demand. In EDGEBIC by User Solutions, a schedule is a computed output, not source data, so you never carry dates across. Trimming the scope this way makes the whole migration lighter, because cleaning and validation only have to cover the data that actually feeds a future schedule.

A migration moves inputs, not outputs

The instinct on a migration is to copy everything across, but a scheduling model does not need everything. It needs the inputs to a schedule, and it produces the schedule itself. So the useful question is not "how do we move all our data," but "what does EDGEBIC actually need to compute a plan."

The answer splits the database into two piles. One pile feeds a future schedule and moves. The other does not and stays where it is. Getting that split right is what makes a migration lighter than it first sounds, and it is why the scope in every phased plan is narrower than a full copy. The whole path is on the RMDB to EDGEBIC guide.

What moves: master data and open demand

Two categories move, because both feed the schedule.

The master data that defines how you make things. Products, work centers, routings, calendars, and customers. This is the scheduled tree, and it is the foundation EDGEBIC places work against. Migrating it is covered in migrating your item and customer master to EDGEBIC and migrating your work center and shift definitions to EDGEBIC.

The open demand that needs placing. Jobs that have not finished: new orders that have not started, and the few long jobs still in progress at cutover. Handling those is covered in migrating open jobs and actuals to EDGEBIC.

That is the whole migration scope. Everything else is in the other pile.

What stays behind

Three categories do not move, and recognizing them is what keeps the model lean.

The schedule itself. A schedule is a computed result, not source data. EDGEBIC produces its own by placing your open orders against finite capacity using your migrated master data. Importing old dates would only hand EDGEBIC a stale answer it is about to recompute. When you validate, you compare the schedule EDGEBIC generates against the one RMDB generated, not a set of dates you carried over. This is why the schedule is never on an import list, and it rests on finite versus infinite capacity scheduling.

Dormant items. Parts that no active routing or open order references add noise without value. A dormant item does not appear in any plan, so importing it only makes cleaning and validation slower. Bring the scheduled tree and leave the dormant remainder in your system of record.

Closed job history. Completed jobs and their actuals stay in RMDB, which remains fully supported as your record of the past. EDGEBIC schedules forward, so a job that shipped last month does not affect any date it is about to compute. Keeping history where it already lives avoids importing records that add weight without changing a single future date.

Why leaving history behind is safe

It can feel risky not to bring history across, but it is not, because RMDB stays fully supported and keeps that history intact. Nothing is lost by leaving it there.

The reason history does not belong in the EDGEBIC model is that scheduling looks forward. A closed job does not affect any future date, so importing it adds weight without changing a plan. If you need to look up how a past job ran, you check RMDB, which is exactly the fallback role it plays after cutover, described in completing the cutover to EDGEBIC. Meanwhile EDGEBIC builds its own history going forward from the actuals the kiosk reports, so the record accumulates naturally. You keep the past where it lives and let EDGEBIC own the future.

A worked example

A shop scopes its migration and is surprised how little has to move.

1. The tempting scope. The full database: 6,000 items, years of closed jobs, the current schedule, all of it.
2. The actual scope. The 900 items in the scheduled tree, the work centers and routings that build them, the calendars, the 60 customers on open orders, and the open orders themselves.
3. Left behind. The 5,100 dormant items, every closed job, and the schedule, which EDGEBIC will regenerate.
4. The result. Cleaning covers 900 items instead of 6,000. Validation compares EDGEBIC's fresh schedule against RMDB's, with no stale dates in the way.

The migration got smaller and faster the moment the shop stopped trying to move outputs and history.

Common pitfalls

• Importing old schedule dates. The schedule regenerates. Carrying dates across just gives EDGEBIC a stale answer to overwrite.
• Migrating the whole catalog. Dormant items add noise. Bring the scheduled tree only.
• Dragging closed jobs across. History stays in RMDB. It does not change any future date.
• Confusing lean scope with lost data. RMDB stays supported and keeps everything you leave behind, so nothing is actually gone.

The takeaway

Knowing what you do not need to migrate to EDGEBIC is half of a smooth migration. Move the master data and the open demand, the inputs a schedule needs, and leave behind the schedule itself, which regenerates, the dormant items no plan references, and the closed history that stays in RMDB. The scope is the scheduled tree plus open orders, not a full copy, which makes cleaning and validation faster and the model leaner. RMDB stays supported, so leaving history behind loses nothing. See the platform in full on the EDGEBIC overview, read the whole path on the RMDB to EDGEBIC guide, and scope the move with an EDGEBIC migration checklist.