Exporting Your RMDB or EDGEBI Data to Excel for EDGEBIC

Exporting RMDB data to Excel is the whole first step of an EDGEBIC migration: you send each entity out to Excel or CSV, map the columns once in an import mask, and re-run that saved mask in a single click every time after. In EDGEBIC by User Solutions, the connection between your old system and your new one is a file, not a live link, so the export is deliberately simple. There is no required format, because the mask adapts to your columns. RMDB stays untouched by the export, so nothing you do here puts your working system at risk.

The migration starts with an export, not a connector

There is no native connector between Resource Manager DB and EDGEBIC, and that is by design. Every product in the User Solutions line has always exchanged data through Excel, CSV, and database import-export masks, and EDGEBIC continues that approach. So the first move in any migration is the one you already know how to do: export your data to a spreadsheet.

That framing matters because it removes the two scariest parts of a migration. There is no integration project to build, and there is no risk to RMDB, because an export only reads. RMDB, the proven classic of the line, keeps running exactly as it did while you carry a copy of its data into EDGEBIC. The full upgrade path this fits into is on the RMDB to EDGEBIC guide.

What to export, and in what shape

Export each entity to its own file. A typical set is five spreadsheets:

• Products or items. Your item master: codes, descriptions, units of measure, costs.
• Work centers. Machine names, capacities, rates, and instance counts.
• Routings. Product, operation sequence, work center, setup time, and run time per unit.
• Orders. Your open sales orders, so the schedule has demand to place.
• Customers. The customer list your orders reference.

You send these out in whatever layout RMDB already produces. There is no template to conform to and no mandatory header names. The point of the import mask is that it maps your columns to EDGEBIC's fields, so the spreadsheet stays in your shape and the mapping does the translation.

The mask maps your columns once

An import mask is a stored column mapping. You build one per entity by telling EDGEBIC which of your columns feeds which of its fields: this column is the product code, that column is the run time, this one is the work center name. The mapping is the real work of the whole import, and you do it a single time.

Then you save the mask. From that point on, importing the same entity is one click, because the mask already knows your layout. The general mechanics of building and saving a mask are covered in EDGEBIC import masks explained. Routings get a little extra help: the two-pass routing import reads every row before it wires step sequences, so operations come in correctly connected no matter how your export ordered the rows.

Why the saved mask is the feature that matters

A migration is almost never a single clean import. The honest rhythm looks like this: you import an entity, spot-check it, find a data problem, fix it back in RMDB, re-export, and re-import. You go around that loop several times per entity before you trust the result.

If every re-import meant re-mapping columns, that loop would be exhausting. Because the mask is saved, it is not. You built the mapping once, so every re-export after a data fix re-imports in a click. This is what makes an iterative, careful migration affordable rather than a chore. It is also what makes a parallel run practical: during the overlap, when master data or orders change in RMDB, you re-export the affected entity and re-run its mask to refresh EDGEBIC, with no re-mapping and no double data entry.

A worked example

A shop is moving off RMDB and wants its item master, work centers, routings, and open orders in EDGEBIC.

1. Export five files. The planner sends items.xlsx, workcenters.xlsx, routings.xlsx, orders.xlsx, and customers.xlsx out of RMDB in their existing layouts.
2. Map five masks. In EDGEBIC they build one mask per file, mapping columns to fields. This is an afternoon of work, done once.
3. Import in order. They import products and work centers first, then routings and orders, so the references resolve.
4. Spot-check and fix. A dozen routings have a work center name misspelled. The planner corrects them in RMDB, re-exports routings.xlsx, and re-runs the routing mask in one click.
5. Refresh during the parallel run. Over the next few weeks, whenever orders change in RMDB, they re-export orders.xlsx and re-run the orders mask to keep EDGEBIC current.

The five masks were mapped once. Every re-import after that, whether to fix data or to refresh, was a click.

Order matters when you import

Export order does not matter, but import order does. Load the things that others reference first: products and work centers before routings and orders, and customers before the orders that name them. Routings link to products and work centers by name, and orders link to products and customers by name, so the references need to exist before the file that points at them lands. The dependency order is covered in the order to import your data into EDGEBIC.

Watch for blank cells and name drift

Two things trip up a first export-import cycle, and both are easy to prevent.

First, blank cells. Depending on how a mask is set up, a blank in a mapped column can clear the target field rather than leave it alone. Before a large import, check how your mask handles empty cells so a blank does not wipe a value you meant to keep.

Second, name drift. Because routings and orders link to products and work centers by name, a name spelled one way in one file and another way in another breaks the link. Keep names identical across files. Cleaning these up before you import is its own short discipline, covered in cleaning your data before importing to EDGEBIC.

The export is safe, repeatable, and reversible

The reason to start a migration with the export is that it is the lowest-risk step there is. Reading data out of RMDB changes nothing in RMDB. Importing into EDGEBIC changes nothing in the plant, because EDGEBIC is not yet the system of record. And because the masks are saved, the whole cycle repeats in a click, so you can iterate until the data is right without penalty. This is the same low-stakes footing that makes running RMDB and EDGEBIC side by side the recommended way to adopt the platform.

The takeaway

Exporting RMDB or EDGEBI data to Excel is the simple, safe first step of the move to EDGEBIC. Send each entity out in its existing layout, map its columns once in an import mask, and re-run that saved mask in one click every time after. Import products and work centers before routings and orders, watch for blank cells and mismatched names, and iterate freely because the export reads only and the mask is saved. See the platform in full on the EDGEBIC overview, read the whole path on the RMDB to EDGEBIC guide, and when you build the masks themselves, start with EDGEBIC import masks explained.