Migrating From Microsoft Project to EDGEBIC

Migrating from Microsoft Project to EDGEBIC is mostly an act of de-duplication: many plan files collapse into a few routings plus one order per job. In EDGEBIC by User Solutions a routing lives once on the product, and every manufacturing order references it, so the file-per-job structure that project scheduling encourages disappears. The concepts map across more cleanly than people expect, and the reshaping happens in Excel before anything is imported.

Two tools, two questions

A project scheduler answers "given this network of tasks and these dependencies, when does the work finish?" That is the right question for work that happens once, such as a construction phase or a new product introduction.

A production scheduler answers a different question: "given these machines, these shifts, and everything already committed, when can this order run?" The difference is finite capacity. Available hours are computed from shift hours, minus holidays and downtime, times the number of identical machine instances, minus what is already allocated, and the plan does not exceed them.

Shops usually notice the gap in one of two ways. Either a routing change means editing every open plan file, or the plan promises hours the plant does not have because two jobs were leveled in separate files that never saw each other.

What maps across

The last two rows are the migration. Everything else is a column mapping.

The reshaping in Excel

Export the task data to a spreadsheet and build four sheets from it. These correspond to four of the eight import masks.

1. Products. The distinct end items your plans produce. One row each.

2. Routing steps, grouped by end product. This is where the de-duplication happens. Sort the exported tasks by name and resource and the repetition becomes obvious: the same handful of step patterns recurring with different durations. Identify the distinct routings and write each one once.

The important conversion here is hours. A plan file holds the duration for that job's quantity; a routing step holds hours that scale with order quantity, plus a setup time that does not. Divide deliberately rather than copying the totals, and if your source data is in minutes, the import mask has a conversion factor field so you do not have to convert the file by hand.

3. Open jobs. One row per plan file: product, quantity, and date. Job number, customer, due date and priority are available too.

4. Resources as work centers. Name and identifier, plus the capacity settings a plan file has no place for: how many identical instances the work center holds, and the behavior flags covered in migrating capacity and utilization settings.

One import rule to respect while preparing sheet two: all steps for a single end product must arrive in one file, because a re-import replaces that product's routing entirely per run. Group the export by end product and confirm each appears exactly once.

What has no project equivalent

Three things you gain are worth configuring deliberately rather than looking for a source column to map.

Machine instances. A work center can hold several identical units. Three mills means three jobs in parallel and roughly triple the daily hours, computed by the engine rather than modeled by hand as three separate resources.

One-job-per-day behavior. For a furnace or an oven where a changeover consumes the day, a work center can be told to take one job per instance per day rather than backfilling the remaining hours. There is no natural way to express that in a task network.

The constraint machine. Flagging the bottleneck lets the plan be built around the machine that actually governs your output, rather than treating every resource as equally interesting.

Sequence-dependent changeover, machine pools and operator certifications are further layers, and all of them are deliberately post-cutover work as described in what EDGEBIC cannot import.

What you deliberately leave behind

Do not try to carry across your current computed dates. The new plan is produced by scheduling your migrated inputs against real capacity, which is the point of the move, so validation compares the two plans rather than copying one into the other. The same applies to task-level percent-complete estimates: recorded work in EDGEBIC is hours and pieces per operation per day, so open jobs come across through the Actuals mask as described in migrating open jobs and actuals.

You also leave behind the plan files themselves. Keep them read-only for history, and resist maintaining them in parallel, which doubles the work and guarantees drift.

Validate on load, then on dates

Once the four sheets are in, schedule a set of jobs you know well and check the work center load before you check any date. A machine showing impossible hours usually means an instance count defaulted to one, or per-job durations were imported as per-unit hours. Both are visible in load immediately and invisible in a date until much later. The discipline is the same one in validating a migrated schedule.

The takeaway

Migrating from Microsoft Project to EDGEBIC means exporting your task data to Excel and reshaping it into products, routings grouped by end product, open jobs and work centers, which collapses one-plan-file-per-job into one routing per product plus one order per job. Convert durations into setup plus per-unit hours, add the capacity settings a project plan has no field for, leave your old computed dates behind, and check load before dates. See the platform on the EDGEBIC overview, the upgrade path on the RMDB to EDGEBIC guide, and pair this with migrating from a spreadsheet scheduler and the order to import your data into EDGEBIC.