Migrating SYSPRO Bills of Materials and Routings to a New ERP

Migrating bills of materials (BOMs) and routings from SYSPRO to a new ERP is the hardest part of a manufacturing data migration. Financial data maps field-to-field. Customer and supplier records translate predictably. BOM structures carry multi-level parent-component hierarchies, operation-level scrap, alternate routes, and Engineering Change Control (ECC) revision histories — all encoded in SYSPRO-specific conventions that no target ERP reproduces directly.

When you move this data to Epicor Kinetic, Dynamics 365 Business Central, or SAP Business One, you are decomposing SYSPRO's SQL schema and reassembling it to fit the revision control and routing logic of a different system. A single mapping error in a BOM structure can cascade into wrong MRP outputs, broken production orders, and incorrect cost roll-ups the moment your new system goes live.

This guide covers what SYSPRO actually stores, how to extract it, the structural mismatches you will hit when loading into common target ERPs, how to handle ECC revisions and active WIP jobs, and the edge cases that decide whether your manufacturing data arrives intact.

For the tables behind every other SYSPRO module, see the SYSPRO SQL table map for migration.

What Does SYSPRO Store in Its BOM and Routing Data?

SYSPRO manages BOMs and routings together through its Structures and Routings program. You use it "to define your bills of materials (i.e. the elements required in a sequence of manufacturing operations, as well as the structural relationships between parent and component parts)" (help.syspro.com, SYSPRO 7 Update 1). The data spans several SQL Server tables in SYSPRO's per-company database.

The verified tables relevant to a BOM and routing migration:

Table	What it holds
BomOperations	Bill of materials operations (routing steps) (help.syspro.com)
BomWorkCentre	Work centres (help.syspro.com)
BomArcStructure	"BOM Archived Structures", added in SYSPRO 8 2018 (help.syspro.com)
BomArcOperations	Archived BOM operations, added in SYSPRO 8 2018 (help.syspro.com)
InvMaster	Inventory master (stock codes) (help.syspro.com)
WipMaster	Work-in-progress job headers (help.syspro.com)
WipJobAllMat	Materials allocated to a production job (help.syspro.com)
WipJobAllLab	Labour (operations) allocated to a production job (help.syspro.com)

The live component (structure) table is not in the list above, because we could not confirm its name in SYSPRO's public documentation. Confirm it in your own company database before you write extraction queries. SYSPRO's database guide says "Each SYSPRO 8 company database contains approximately 1000 tables" (help.syspro.com), so scope the BOM extract to named tables rather than dumping the whole database.

SYSPRO's help notes that "bills can be up to 15 levels deep". It also documents phantom parts, kit type items, and notional parts that carry co-products (help.syspro.com, SYSPRO 7 Update 1).

Custom fields in SYSPRO are stored in plus tables. Each one "typically has the same name as its primary associated table with a '+' character as a suffix", and SYSPRO advises square brackets around the name, for example [ArCustomer+] (help.syspro.com). If your engineering team uses custom form fields to track material grades, tooling codes, or revision notes, join the base tables to their plus tables during extraction. These fields will not appear in standard report exports.

How to Extract BOM and Routing Data from SYSPRO

There is no single "export BOM" button that yields a format ready for a new ERP. You have four technical paths, each with distinct constraints.

Direct SQL Server Access

A one-off, read-only SQL extract is the route we recommend for BOM and routing data. By reading the company database, you can reach every table — including plus tables — and join operations to work centres and parent stock codes.

SYSPRO's own best-practice guide warns: "Connecting to the SYSPRO databases directly using SQL drivers is not advised" (help.syspro.com). That warning is about live integrations. For a migration extract, work against a restored copy of the database using a read-only login with db_datareader permissions. Production is untouched, and you can run the recursive queries needed to flatten multi-level BOMs.

Business Activity Queries (BAQs)

BAQs are SQL views created within the company database. Any SQL user with db_datareader permissions can retrieve data through these views (help.syspro.com). BAQs are useful if your SYSPRO administrator has already built views that combine BOM and routing data, but they offer no advantage over direct SQL for a dedicated migration.

SYSPRO OData Service

The SYSPRO OData Service is read-only and "lets you connect securely to SYSPRO data without direct SQL access" (help.syspro.com). It "is the only mechanism available when applications need access to SYSPRO data in the Syspro Cloud ERP environment" (help.syspro.com). SYSPRO limits it "to 5000 rows under the Microsoft best practice guidelines for performance and fair use", with paging via $top and $skip (help.syspro.com). A large set of routing steps and components therefore takes many paged calls. Use OData where SQL is not possible.

e.net Business Objects

SYSPRO's e.net business objects return XML for individual records or filtered sets. They suit integration, not bulk extraction. The BOMQRY object is a BOM Costing Query (help.syspro.com). It returns BOM costs, not a structure export, so its best use in a migration is checking the cost roll-up in your target ERP.

For a full comparison of extraction methods, see How to Export Data from SYSPRO: Methods, API Limits & Portability.

Mapping SYSPRO Data to Target ERP Architectures

Once you have extracted the operations, work centres, components and stock codes, you must transform the data into the schema of your new ERP. Every system models manufacturing data differently, and SYSPRO's combined structures-and-routings approach does not translate directly to any of them.

SYSPRO to Epicor Kinetic

Epicor Kinetic has its own part revision and engineering change workflow, and BOM data must load through it rather than around it. Plan the revision mapping with your Epicor implementation partner before you build the load. For the object-by-object mapping, see the SYSPRO to Epicor Kinetic migration page.

SYSPRO to Dynamics 365 Business Central

Business Central keeps the production BOM (the material structure) and the routing (the operation sequence) as separate records. You attach a certified routing to a production item "by filling in the Routing No. field" on the item card (learn.microsoft.com). SYSPRO maintains both in one program.

To tie a component to the operation that consumes it, Business Central uses routing link codes. On a production BOM line, "In the Routing Link Code field, enter a code to connect the component to a specific operation" (learn.microsoft.com). During transformation, generate routing link codes and assign them to both the BOM lines and the routing lines. Without them, forward flushing posts consumption when the production order is released, and backward flushing posts it when the order is finished. With them, posting happens per operation (learn.microsoft.com).

Business Central "also supports assembly BOMs" for assembly done by basic resources that "aren't machine or work centers" (learn.microsoft.com). Map each SYSPRO BOM type — phantom parts, kit type items, notional parts — to the correct Business Central equivalent.

For the pair mapping, see the SYSPRO to Dynamics 365 Business Central migration page.

SYSPRO to SAP Business One

SAP Business One models production differently again, so SYSPRO's operations and component lines need explicit remapping before load. Agree the target structure with your SAP Business One partner first. For the pair mapping, see the SYSPRO to SAP Business One migration page.

How Do You Handle SYSPRO's ECC Revisions During Migration?

SYSPRO's Engineering Change Control (ECC) module governs product design changes. SYSPRO says ECC-controlled items "can only be changed through an approved ECO", and that changes are tracked "at the stock code, revision, or release level, with support for both major design changes and minor cosmetic updates" (syspro.com). In Structures and Routings, you choose the revision and release of an ECC-controlled stock item to view or copy its structure (help.syspro.com, SYSPRO 7 Update 1).

This creates two migration challenges:

1. Every target ERP has a different revision model. Business Central, for example, uses production BOM versions whose validity is set by a starting date. A new version gets the status New and becomes usable once set to Certified (learn.microsoft.com). That does not map 1:1 to SYSPRO's revision and release pair.

2. Archived ECC revisions may live outside the live tables. SYSPRO describes ECC as storing "complete histories of product structures, routings, and jobs with manual or automatic archiving when changes are approved" (syspro.com). If your business needs historical revision traceability — for ISO compliance, defect investigation, or regulated manufacturing — you need the current revision from SQL and the archived data for earlier revisions.

What Import Sequence Do BOM and Routing Records Require?

The load order for manufacturing master data is non-negotiable. Every target ERP enforces referential integrity: you cannot create a BOM line that references a component that does not exist, or an operation that references a work centre that has not been loaded.

The correct sequence for any target ERP:

1. Item master / stock codes — all parent items and components must exist before any BOM record
2. Work centres / machine centres — required before routing operations can reference them
3. Routings / operations — the operation sequence, linked to work centres
4. BOM structures / component lines — material assignments, linked to parent items and (in some ERPs) to specific operations via routing link codes
5. Open WIP jobs — only after the master data they reference is in place

Skipping a step or loading out of order creates cascading failures. A component stock code that was not migrated silently breaks every BOM that includes it, which in turn blocks production order creation in the new system.

Lot-traceable and serialised components need their own pass. Their lot and serial history migrates separately from the BOM, and the item settings must match before the first production order runs. See SYSPRO lot and serial traceability migration.

Handling Work in Progress (WIP) Jobs During Cutover

Migrating active manufacturing jobs is the highest-risk element of an ERP transition. In SYSPRO, WIP data lives in WipMaster (job headers), WipJobAllMat (materials allocated to a job), and WipJobAllLab (labour/operations allocated to a job).

When cutting over to a new ERP, you face a choice: migrate mid-flight jobs, or drain the WIP.

We strongly advise draining WIP. Complete as many open jobs as possible in SYSPRO, close them out, and migrate only the finished goods inventory and raw material balances. Migrating an active job requires extracting the exact partial-completion state from WipJobAllMat and WipJobAllLab, translating that state into the target ERP's WIP model, and posting adjustment journals to align the general ledger.

Recreating a part-finished job in Business Central or Epicor without duplicate material issues or GL imbalances is hard. Plan cutover for a Monday go-live, never a Friday. The bulk load runs in the days before, while SYSPRO stays live. SYSPRO freezes before Monday's working day starts, and the final delta covers changed records only, in about 30 minutes. New jobs then start in the new system on Monday morning. For how to treat closed jobs, see SYSPRO WIP and job history: migrate or archive.

Edge Cases That Break SYSPRO BOM Migrations

These are the patterns we see repeatedly across manufacturing ERP migrations.

Dual run-time fields

SYSPRO's help says: "There are two fields for the run time in the BomOperations table: RunTimeEnt This indicates the run time entered in the Unit run time field here. RunTime This is the RunTimeEnt converted to the stocking unit of measure." If the parent unit of measure on the BOM is stocking, the two values are the same (help.syspro.com, SYSPRO 7 Update 1). Your target ERP needs whichever aligns with its own unit-of-measure convention. Get this wrong and every cost roll-up will be off.

Alternate routes

SYSPRO supports alternate routes per stock code when the Alternate routings setup option is enabled. "Sales Order entry always uses route 0. Therefore to sell Kit type items, route 0 must be used" (help.syspro.com, SYSPRO 7 Update 1). Target ERPs handle alternates differently. Business Central's routing versions are selected by starting date, not by route number (learn.microsoft.com). Map route 0 as the primary and decide, route by route, what each alternate becomes in the target.

Progressive scrap

When the Progressive scrap setup option is enabled, SYSPRO holds a scrap percentage and scrap quantity per operation. When a job is created, "any material allocation associated with this operation is inflated according to the scrap quantity entered" (help.syspro.com, SYSPRO 7 Update 1). Business Central has scrap on both sides: the BOM line scrap percentage is for components scrapped during production, and "The scrap percentage on routing lines represents scrapped output before you put it in inventory" (learn.microsoft.com). If your target has no operation-level equivalent, collapse the scrap into the component-level percentage and test the cost result.

Phantom parts and co-products

SYSPRO supports phantom parts and notional parts with co-products attached. You cannot add an operation to a phantom part, and co-products are attached "to a notional part on the current route" (help.syspro.com, SYSPRO 7 Update 1). Business Central supports phantom production BOMs, which "let you group components for structural or organizational purposes without creating a separate production order for the subassembly" (learn.microsoft.com). Validate every non-standard BOM type individually.

Structure on/off dates

SYSPRO has a Structure on/off dates setup option, which gives each component a structure on date and a structure off date (help.syspro.com, SYSPRO 7 Update 1). Decide during scoping whether expired components should migrate (for historical completeness) or be excluded (for a clean start). Either choice is valid, but it must be deliberate.

Custom form fields

Engineering data in plus tables does not travel with the standard tables. Find every plus table attached to your BOM, stock code and work centre tables before you freeze the field mapping.

Validation: Cost Roll-ups, Record Counts, and Referential Integrity

Validating a BOM migration requires multi-stage checks, not a single "it imported successfully" confirmation.

1. Record-count parity. The total number of active parent items in SYSPRO must match the total number of approved BOM headers in the target system. Count mismatches indicate dropped records.
2. Field-level validation. Verify that standard costs, run times, and setup times map exactly, accounting for unit-of-measure conversions — if SYSPRO tracks run time in hours but the target ERP defaults to minutes, a missed conversion silently corrupts every cost roll-up.
3. Referential integrity checks. Run scripts against the target system's API to confirm no BOM contains a component that does not exist in the item master, and no routing references a work centre that is inactive.
4. Cost roll-up comparison. Run the cost roll-up in the target ERP and compare it against SYSPRO's BOM costing output. If the rolled-up cost per parent item differs, trace the discrepancy to the specific operation or component that was mis-mapped.
5. Multi-level BOM explosion. Verify that BOM explosions in the target system produce identical component lists to SYSPRO for a representative sample of your most complex assemblies.

Do this during sample migrations, not after go-live.

How Long Does a BOM and Routing Migration Take?

Keep two clocks separate. The data migration — extracting, transforming, and loading BOM and routing records — is measured in days. Most ClonePartner data migrations complete within 1–5 business days, depending on data volume, complexity, and API rate limits. Datasets under 10,000 records can finish in under 24 hours.

The ERP implementation (selecting, configuring, testing, and rolling out the new system) is a separate effort measured in months. Your implementation partner or the vendor handles it. ClonePartner handles the data migration and does not implement ERPs.

If your SYSPRO licence expires before the new ERP is ready, extract the data before your expiry date (31 October 2026 outside the US, 31 December 2026 in the US) and load it once the target is configured.

Getting the Migration Right

BOM and routing data is the operational backbone of a manufacturing ERP. It drives MRP, costing, scheduling, and shop floor execution. Bad data here does not stay contained — it propagates into every downstream process.

The extraction is straightforward if you know which tables to pull. The transformation is where the work lives: mapping SYSPRO's combined structures-and-routings model into whatever model your target ERP uses. Validate aggressively during sample migrations. Run the cost comparisons. Check the BOM explosions. Verify the edge cases.

For the full data migration process across all entities, see The Ultimate ERP Data Migration Checklist.

ClonePartner charges one fixed price per project, starting at $500. No hourly billing, no per-record metering. The price scales with data volume, custom fields, attachment size, and the platforms involved.