What Changes in EDGEBIC When You Replace Your ERP

Replacing the ERP under a file-based scheduler is a re-mapping exercise, not a re-integration project: your work centers, instance counts, calendars, setup matrices, groups, skills, routings, jobs, and history all stay exactly where they are, and what you rebuild is the set of import masks that read the new system's column headings. Nothing was installed in the old ERP, so there is nothing to decommission, no connector license to repurchase, and no integration credential to retire.

EDGEBIC by User Solutions has followed customers through ERP replacements since 1991, and across 35+ years of scheduling for the US Navy, GE, BAE Systems, and Cummins, the pattern holds: the scheduler is the thing that keeps working while the system of record changes underneath it.

What survives untouched

Everything that encodes how your shop actually runs, which is most of the value in the model:

That list is exactly the set of fields covered in choosing the system of record for each scheduling field, and it is why the ownership map is worth writing down long before a migration is on the horizon. Everything EDGEBIC owns is immune to the change by construction.

What you rebuild

Four things, and none of them are large:

The masks. A new ERP produces different column headings, so each mask is rebuilt by dragging the new headings onto the same target fields. Products, work centers, routings, work orders, and optionally labor: five files, an afternoon.

The export mechanism. Saved reports, list exports, or database views on the new system. Whether a view is worth the effort over a CSV is covered in CSV versus database view export trade-offs.

The filter. Status codes will be named differently, so the rule that decides which work orders reach the plan has to be restated. The framework is in deciding which ERP work orders to import.

The unit conventions. The new system may quote times in minutes where the old one used hours, or per hundred where the old one was per piece. Each is a conversion factor on a column in the mask, applied before the value is stored, and the table of factors is in mapping your ERP's units of measure.

Identifier continuity is the whole risk

If one thing deserves a decision at project kickoff rather than at cutover, it is this.

Products and work centers match on the identifier, case-insensitively, so BRK-200 finds brk-200. A renumbered catalog therefore imports as a new catalog: every part Created rather than Updated, routings landing on new records, and open work orders splitting across two sets of products that describe the same physical parts.

Three ways through, in order of preference:

1. Carry the legacy number across. Most ERP implementations support a cross-reference or legacy part field. Export that field as the identifier until you deliberately switch.
2. Plan the identity change. Import the new catalog, re-import routings under the new identifiers, and let the old records go quiet as their jobs finish. Expect a high Created count on the first run and treat it as expected rather than alarming.
3. Never mix. The one genuinely bad option is some exports carrying old numbers and others carrying new ones. The resulting half-and-half state is harder to unpick than either clean version.

The same reasoning applies to work center names and to job numbers. The conventions that hold up over time are in keeping product masters in sync and keeping job numbers aligned between ERP and EDGEBIC.

Scheduling keeps running through cutover

This is worth saying plainly, because it is unusual.

The plan is computed locally from data already imported. During the days when the old ERP is frozen and the new one is not yet live, the shop still gets a schedule and a dispatch list. What you lose temporarily is the ability to bring in new demand, and you cover that by importing a final work order file before the freeze begins.

Nothing else stops. Operators keep logging hours, actuals keep landing on jobs, completed work is never moved by a reschedule, and the plan can be re-run daily against whatever the last known demand was.

A workable sequence

The dry run is the step people skip and then wish they had not. Building masks against a sample export a fortnight early turns cutover day into a repeat of something you have already done. The wider go-live shape is in an ERP and EDGEBIC go-live cutover plan, and the from-empty sequence is in migrating work centers and shifts to EDGEBIC.

Watch for changes in shape, not just headings

A new ERP often models the same data differently, and the mask alone will not tell you. Four to check specifically:

• Setup and run. Blended into one standard, or split onto separate operation rows. Both cases are handled in combined setup and run time and setup as its own operation row.
• Operation sequence. Alphanumeric codes, or numbering that restarts per department. Covered in importing ERP operation sequence numbers.
• Quantity. Original ordered versus open balance, which decides whether actuals or the ERP net your progress.
• Dates. Which of the several date columns is the commitment, addressed in customer due dates versus internal need dates.

Then it is a normal week again

Once the new masks are saved, the recurring routine is what it was: export, pick the mask, run, read the counts, schedule, export dates back. The engine underneath never noticed the change, and it keeps doing what it does: finite capacity across shifts and machine instances, work center groups, sequence-dependent setups, lot streaming with transfer batches, and mathematical optimization with a proven optimality gap. The EDGEBIC product overview maps the engine, the ERP integration architecture shows the import layer, and why EDGEBIC connects to every ERP the same way explains why the method does not care which system is on the other end.

If the two systems will overlap for a while, the parallel-running case has its own post: scheduling a shop that runs two ERPs.

Bring a sample from the new system

As soon as your implementation team can produce sample exports from the new ERP, bring them to a demo. Mapping them live tells you within half an hour whether the new system will hand you a cleaner routing than the old one, and where you will need a conversion factor.