The Definitive Guide to Migrating to Epicor ERP

Epicor Software Corporation was founded in 1972 and is headquartered in Austin, Texas; the modern company is the result of a 2011 merger of Epicor and Activant Solutions, followed by a series of vertical acquisitions ¹. The flagship product is Kinetic (cloud manufacturing ERP, formerly Epicor 10), with Prophet 21 for wholesale distribution, BisTrack for building-materials, Eclipse for electrical/plumbing distribution, and iScala for international/multi-entity finance.

The typical Epicor customer is a $50M–$1B mid-market manufacturer or distributor with 50 to 5,000 users, real shop-floor or warehouse complexity, and a need for a vertical-tailored ERP without a Tier-1 implementation budget. Compared with Oracle NetSuite, Epicor positions on industry depth — discrete manufacturing, finite scheduling, MES — at a lower license point ³. Compared with Dynamics 365 Business Central or SAP S/4HANA, it positions on Prophet 21's distribution heritage and on customisation latitude through BPMs and UD fields.

The shapes of migration that actually land on Epicor tend to fall into four patterns. First, legacy Epicor consolidation — Vantage, Vista, Epicor 9, on-prem Epicor 10 customers moving to Kinetic in the cloud as Epicor phases out on-premises support. Second, NetSuite-or-SAP exits, driven by sticker shock on multi-entity manufacturers — one Reddit thread documents a $700K NetSuite quote against an Epicor Kinetic evaluation for a 2-country, FDA-regulated manufacturer ³.

Third, QuickBooks-or-spreadsheet outgrowing at the $20M–$100M revenue threshold where MRP, BOM and multi-warehouse inventory finally need real ERP. Fourth, competitor-ERP replacement — ECi M1, Infor SyteLine, Sage 100, IFS — usually triggered by an acquisition or an end-of-life announcement. Each shape has a different difficulty profile: a Vantage-to-Kinetic move is mostly a database upgrade with custom-code rewrites, while a NetSuite-to-Prophet 21 swing is a full re-implementation of the chart of accounts and inventory model.

What makes migrating *to* Epicor harder than the category average is the vertical product matrix. Kinetic, Prophet 21, BisTrack and Eclipse share branding but not data models — choose the wrong destination edition and the mapping spreadsheet is wasted. The underlying database is SQL Server on modern Kinetic and Prophet 21 SaaS, but legacy on-prem Prophet 21 and Vantage installs still run Progress OpenEdge, and Archon and Encompass migrations regularly find both engines in a single tenant.

What makes it easier than the average is the Data Management Tool (DMT) — Epicor's first-party bulk-import utility that ships with 60+ prebuilt templates and routes every row through the same Business Object layer the UI uses ⁴. BPMs fire, validation runs, integrity is enforced — at the cost of throughput. Customisations preserve a decade of on-prem work but none of it auto-converts; it is rebuilt against Kinetic frameworks.

DMT is the import path that Epicor itself uses — and the price you pay is that every row pays for every BPM you wrote.

Epicor's data model is built around a relational schema of more than 1,300 services and roughly 20,000 operations, each backed by a Business Object (BO) that owns a primary table and its child tables. Kinetic groups BOs into modules — Erp, Ice, Mfg — and every import path, whether DMT or the UI, calls the BO update operations rather than writing to the database directly. That means upserts always run through validation, BPMs and security.

Before mapping a source field, you need to know which BO owns the destination table, what columns it requires, and which combination of keys uniquely identifies a row. The table below summarises the BOs you will touch in any Kinetic or Prophet 21 migration.

Every BO row carries a Company column. Epicor's multi-company architecture means a single tenant can host multiple companies with separate ChartIDs, currencies and operational books — and DMT imports must specify the target Company on every row, or the load lands in whichever company the DMT user's default is set to.

Upsert keys vary by BO. Customer keys on CustID (or the system-assigned CustNum integer); Part keys on PartNum; GLAccount keys on the composite of ChartID + Account; OrderHed keys on Company + OrderNum. DMT templates declare the key columns explicitly — the *Add* mode rejects duplicates, *Update* requires the row to exist, and *Add-or-Update* attempts both ⁴. Keys are fixed by the BO and cannot be reassigned at runtime.

Custom fields are added as UD fields on standard tables via the Data Dictionary, or as separate UD Tables for entirely new entities. UD field types include character, decimal, integer, date, datetime, boolean and combo-box (bound to UserCodes — Epicor's picklist mechanism). There is no hard cap on UD fields per table, but practical limits emerge from form-customisation and BAQ join complexity.

Relationships in Epicor are foreign keys in the underlying SQL Server (or Progress OpenEdge on legacy on-prem). Parent/child wiring on UD tables uses the Key1–Key5 columns mapped to the parent's natural key ⁵⁵. There is no native cascade-delete on UD tables — deletion is enforced by BPMs or by the parent BO. Standard tables ship integrity rules: deleting an OrderHed cascades to OrderDtl and OrderRel via the BO, not via SQL.

Customisations beyond UD fields live in BPMs (Business Process Methods) — server-side C# code attached to BO operations as pre-, post- or in-transaction directives — and in Personalizations (per-user form layouts) and Customizations (shared form code). None of these is data; all of them affect how data writes behave during import, which is why a DMT load against a heavily-BPMed tenant runs slower than the raw row count would suggest.

The single best predictor of a clean Epicor migration is whether the chart of accounts, part master and customer/vendor master have been cleansed *before* DMT is opened. Data Ladder, Panorama and Epicor's own Implementation Guide all converge on the same point — cleansing after import is more expensive than cleansing before, because every dirty row that lands triggers BPM execution, validation logging and downstream report distortion.

Cleanse the part master, the chart of accounts and the customer master before DMT — every dirty row that lands costs you twice.

Treat the source export as raw material that needs to be shaped to Epicor's expected formats — Part numbers padded to the new schema's length, GL account segments concatenated to ChartID + Account, UoM codes converted to Epicor UoM Class members, currencies expressed in Epicor's Currency Master codes, dates rewritten as MM/DD/YYYY for DMT (which uses regional settings).

Source-side prep

• Cleanse and dedup customer, vendor and part masters in the source before extract — Data Ladder and similar tooling are designed for ERP-bound dedup and catch case-only and whitespace duplicates that survive a naive SQL export.
• Lock the chart of accounts for the cutover fiscal period — adding a segment after the GL has been loaded into Epicor means rebuilding ChartID and re-keying every prior journal.
• Reconcile open AR and AP to the penny in the source before extract — Epicor's reconciliation reports (AR Aging, AP Aging, GL Trial Balance) will surface every variance after load, but fixing it in the source is faster than journal-entry corrections in the target.
• Decide what is historical versus what is open — most teams import open transactions only (open AR, open AP, open POs, open sales orders, on-hand inventory) and archive history to a read-only warehouse or UD tables ⁸⁶⁸⁷.
• Stamp a stable external ID on every record before extract — the source primary key carried into a Character30 UD field gives you a reconciliation anchor that survives Epicor reassignment of CustNum, VendorNum and OrderNum.

Destination-side prep

• Stand up a Pilot environment — Kinetic SaaS customers get a Pilot tenant alongside Production; on-prem customers clone the production database to a Test server and update SysAgent paths so background jobs fire against the test environment ³⁶.
• Provision users and security groups first, including License Configuration, before loading data — owner and audit columns fall back to the DMT user if the referenced employee or user is missing.
• Build the Chart of Accounts and segment structure in Epicor before loading any GL or sub-ledger data — Epicor supports up to 20 segments per ChartID with controlled-value lists per segment ¹¹⁹.
• Create UD fields, UD tables and UserCodes before importing rows that depend on them — DMT silently ignores values for UD fields that have not been added to the Data Dictionary.
• Configure UoM Classes and conversion factors before loading the Part Master — every Part has an Inventory UoM (IUM), Purchasing UoM (PUM) and Sales UoM (SUM), and conversions are owned by the UoM Class, not the Part ¹¹⁷.
• Define Plants, Warehouses, Bins, and Site relationships before any inventory transactions land — PartTran rows reject if the referenced Plant or Warehouse does not exist.

People prep

Cutover only works if Finance, Operations and IT cooperate. Lock down a source-system freeze window — typically 48 to 96 hours over a weekend bracketing month-end — and communicate it to every group that touches the ERP. Train Finance on Journal Entry, GL Account Maintenance and Period Close, and train Operations on Part Entry, Job Entry and Sales Order Entry before go-live.

A clean Vantage-to-Kinetic upgrade runs 6–9 months elapsed; a NetSuite-to-Prophet 21 swing runs 9–15 months; a Vantage-to-Kinetic with 20+ customisations runs 12–18 months and $200K–$500K in conversion alone.

Epicor's canonical load path is the Data Management Tool (DMT). Third-party tools like Archon, Encompass and MindHARBOR sit alongside DMT and add staging, transformation and Progress-OpenEdge extraction layers.

DMT — Data Management Tool

DMT is a Windows desktop client that ships with more than 60 prebuilt CSV and Excel import templates — Customer, Part, BOM, GL Account, AR Invoice, AP Invoice, Sales Order, Inventory Transaction, UD Table and more ⁴. The launch path is Start → Epicor → DMT; the template builder is Template Builder within the same client. Templates accept .csv and .xlsx; columns mirror BO operation parameters one-to-one, with the key columns marked as required.

DMT runs in *Add*, *Update* or *Add-or-Update* mode per template invocation. Each row makes one BO call, so a 100,000-row Customer import is 100,000 sequential operations — throughput is in the 5–30 rows per second range depending on BPMs and network latency. A separate DMT Historical Data license unlocks higher-volume loads on tables like PartTran ⁸⁶.

DMT also supports BAQ Exports from the command line — DMT.exe -User=… -Export -BAQ=MyBAQ -Target=… produces a DMT-importable CSV from any Business Activity Query, which is the canonical pattern for extracting from a source Epicor environment.

Third-party staging tools

Archon Data Store extracts from SQL Server and Progress OpenEdge with full schema preservation, normalises across Vantage / Vista / E9 / E10, and re-links file-share attachments. MindHARBOR focuses on Prophet 21 SaaS transitions and ships a checklist covering custom SQL, integrations, reporting and scheduled automation — categories DMT does not cover. Encompass and Six S Partners run the official Epicor Data Extraction Tool for Avanté, DataFlo, Enterprise, Scala, iScala and Manage 2000¹¹³.

Mapping is where every Epicor migration earns its scars. The schema decisions you make in your mapping spreadsheet determine whether the Trial Balance ties out on day two, whether MRP produces sensible suggestions on day five, and whether Finance trusts the data through the first month-end close.

Work in dependency order: Currencies and UoM Classes first, then Chart of Accounts, then Customers and Vendors, then Parts and BOMs, then open AR/AP, then open Sales Orders / POs / Jobs, then GL opening balances, then on-hand inventory via PartTran. Each layer depends on the prior layer's foreign keys resolving.

Chart of accounts and GL opening balances

Epicor's Chart of Accounts is segmented under a ChartID with up to 20 segments — typical structures are Natural Account + Department + Division + Project ¹¹⁹. Each segment has a Maintenance program with controlled values, and the composite GLAccount row is the cross-product the system allows for posting. Build the ChartID and segment values before loading any GL data; loading then becomes a DMT GLAccount Import keyed on ChartID + Account.

GL opening balances are not a single import — they are a Period 1 cutover Journal Entry posted on the conversion date. The standard pattern: freeze the source on the last business day of the prior period, close the period in the source, export the closing Trial Balance, build a Journal Entry in Epicor that mirrors the TB exactly, post it as Beginning Balance type, and reconcile the Epicor TB against the source TB to the penny ¹¹⁵.

Use the AR Subledger, AP Subledger and Inventory Valuation reports as the authoritative reconciliation source, not the GL trial balance alone — subledger-to-GL mismatches are the most common cutover defect.

Customers, vendors, parts

Inventory, BOMs and units of measure

Inventory in Epicor is the union of PartWhse (warehouse-level on-hand and bin), PartBin (bin-level detail) and PartTran (every movement). On-hand at cutover loads via an Inventory Quantity Adjustment PartTran with TranType=ADJ-QTY, or via the Cycle Count Entry process for tighter controls. Lot-tracked and serial-tracked parts require LotNum and SerialNum columns; activate tracking on the Part record before loading transactions.

Units of measure are owned by UoM Class — for example a Length UoM Class contains member UoMs (inch, foot, metre) with conversion factors between them. A Part picks an Inventory UoM (IUM), Purchasing UoM (PUM) and Sales UoM (SUM) from one or more classes, and the system auto-converts on transactions ¹¹⁷. For metals, textiles and high-value inventory, the Advanced UoM module supports dual-unit transactions ¹²².

BOMs (Bills of Material) load against the ECO (Engineering Change Order) group of tables — ECORev (revision header), ECOMtl (material lines), ECOOpr (operations). DMT ships a multi-level BOM template that walks parent-child relationships; rev approval is a separate operation and is required before MRP will consider the BOM ⁵⁴. Resource Groups, Operations and Operation Resources must exist before the BOM lines reference them.

Multi-currency and historical exchange rates

Epicor stores every monetary value in both document currency and base currency (Base, Rpt1, Rpt2, Rpt3 columns). The Daily Exchange Rate table holds rates by date; loading historical AR/AP at original rates requires rate rows to exist on the document date or the load reverts to the current rate. Build the daily rate table from source history before loading open AR/AP, and post FX revaluation at cutover as a Journal Entry per Book ¹¹⁶.

Fiscal calendar and period close

The Fiscal Calendar in Epicor supports calendar-year, 4-4-5, 4-5-4 and 13-period structures, with up to 12 or 13 periods plus an adjustment period. Build the calendar for the current fiscal year *and* the prior year before posting any historical data; period close in Epicor closes all sub-ledgers and locks posting, and you cannot post to a closed period without re-opening it. For the cutover period, leave it open until the Trial Balance ties out and Finance signs off.

Files, attachments and audit trail

Attachments in Epicor link to records via the XFileRef table — every Customer, Vendor, Part and OrderHed can carry attachments referenced by file path or document-management handle. Kinetic SaaS routes attachments through Epicor ECM (formerly DocStar); on-prem installs point at a file share.

The practical cap on a single attachment is around 175 MB in Kinetic cloud — anything larger errors out after a long spin ¹⁰⁵. Bulk attachment migration runs through the ECM Batch Import tab, fed by a CSV of file paths and target XFileRef keys ⁹⁷.

Audit trail in Epicor is opt-in. Change Log is enabled per table via a Data Directive and captures column-level changes with username and timestamp into the ChgLog table ⁹⁸. The standard CreatedBy, CreatedOn, ChangedBy and ChangedOn columns are system-managed — DMT stamps them with the current user and current time.

To preserve the legacy audit trail, populate two UD fields per object — *Legacy Created By* (Character30) and *Legacy Created Date* (Datetime) — from the source export, and instruct Finance to rely on those columns for historical reports.

Customisations themselves migrate via Solution Workbench exports — package BPMs, Customizations, BAQs, Dashboards, Reports and UD definitions into a Solution file, then import on the target tenant. On a cloud move from on-prem Epicor 10 to Kinetic SaaS, expect to rebuild rather than migrate code-heavy BPMs that called external assemblies or directly hit the database — Kinetic cloud's runtime restrictions block both.

Validation is the bridge between DMT finishing and users being allowed in. Epicor's own upgrade tooling ships Reconciliation Reporting with 13 prebuilt reports — AP Aging, AR Aging, GL Opening Balance, GL Debit/Credit, Trial Balance, Check Register, AP Received Not Invoiced, Open POs, Material Transactions, Quote Detail, Sales Order Backlog and Scheduled Shipments — that compare source against destination and flag variance rows. Use these as the spine of your reconciliation plan, supplemented by BAQs against the source extract.

Build a reconciliation queries spreadsheet that compares source and destination on each of these counts. Anything outside a 0.5% variance gets investigated before users get login access.

• GL Trial Balance by company, by book, by period — must tie to the source TB to the penny on the cutover date.
• AR Aging total by Customer and bucket — sum of open ARInvHed rows by 0-30/31-60/61-90/90+ ageing buckets.
• AP Aging total by Vendor and bucket — open APInvHed minus paid amount on each row.
• Inventory Valuation by Part, Warehouse and costing method — PartWhse on-hand × cost should match source closing valuation.
• Open Sales Order backlog — count and dollar amount on OrderHed where order not fully shipped.
• Open PO backlog — count and dollar amount on POHeader where PO not fully received.
• Active BOM count by Part — number of approved revisions with at least one material line.
• User and security assignment — every active user has the same Security Group set as the source role.

On top of reconciliation, run a manual spot-check protocol: pick 30 random records across BOs and verify each field against the source UI. Pick five high-value Customers and trace the full association graph — addresses, contacts, open orders, open invoices. Pick five Parts and trace the BOM, on-hand by warehouse, cost roll-up. If a discrepancy shows up in three or more of the 30, halt the load and re-import via DMT *Update* mode keyed on the natural key.

Rollback in Epicor is not a button. There is no native bulk-undo for a DMT load, no equivalent to a CRM's import-batch delete. The practical fallbacks are three: (1) keep a clean SQL Server backup taken seconds before the load, and restore in place if catastrophe strikes; (2) stamp every imported row with an Import Batch ID UD field so a follow-on DMT *Delete* template can remove them; (3) on Kinetic SaaS, dry-run every load in Pilot before Production.

Cutover sequencing: (1) source goes read-only and the team is notified; (2) a final delta export captures everything changed during the test-load window; (3) the delta is loaded via DMT Update templates in dependency order; (4) the GL beginning-balance JE is posted to the cutover period; (5) Reconciliation Reporting runs and Finance signs off on TB, AR/AP Aging and Inventory Valuation; (6) users get access plus 72-hour hyper-care; (7) source decommission is scheduled 90 to 180 days out.

Epicor runs a tiered Channel Partner and ISV programme — partners are certified by vertical (manufacturing, distribution, building materials, automotive aftermarket) and by product (Kinetic, Prophet 21, BisTrack, Eclipse, iScala). The right partner for any migration is the one with named projects in your vertical and your source system, not the largest partner overall ¹³⁵¹³⁸.

Epicor itself runs Professional Services for cloud migrations and ships Analyzer, Packager/Transfer, Data Upgrade and Reconciliation Reporting as part of the Cirrus upgrade programme¹¹³. For specialist data work outside core configuration — UD fields, integrations, archived attachments — channel firms like Encompass Solutions, Six S Partners, MindHARBOR (Prophet 21), EC Solutions, Estes Group, LST Consultancy and DCKAP are commonly named¹¹³. Archon Data Store specialises in legacy Epicor extraction including Vantage, Vista, E9 and Progress OpenEdge.

On the ETL and iPaaS side, Fivetran, Airbyte, Workato, MuleSoft, Boomi and Stitch all have Epicor connectors of varying maturity. Their role in a migration is rarely the migration itself — it is the staging layer into a warehouse, the transformation layer that resolves UoM and ChartID conversions, and the ongoing-sync layer afterwards. For warehouse-first teams, Airbyte or Fivetran into Snowflake then DMT-from-warehouse is a common pattern.

Managed-migration cost ranges vary widely with edition and scope. A Vantage-to-Kinetic upgrade with light customisation lands in the £45,000–£100,000 / $50,000–$120,000 range; a NetSuite-to-Kinetic move with multi-entity finance, BOMs and 18 months of history starts around $250,000 — one documented oil-and-gas case ran 900 hours and $350,000 for 1.1M historical records. A heavy on-prem Epicor 10 to Kinetic move with 20+ customisations crosses $500,000 once conversion ($200K–$500K) and integration rebuilding ($50K–$200K) are added.

For teams that want to outsource the migration end-to-end, FlitStack specialises in ERP data migrations including Epicor and handles the field mapping, GL opening-balance posting, UoM and BOM conversion, open-AR/AP load, and reconciliation work described in Sections 5 and 7 of this guide. Pricing is fixed-fee, based on record count and source platform, with separate line items for historical-data depth and integration rebuilds so the scope is transparent before signature.

This is one of several legitimate paths — the right choice for any given team depends on whether they want an Epicor Channel Partner, Epicor Professional Services, an iPaaS-first approach, or a specialist migration vendor. Explore FlitStack →