ERP migration
Field-level mapping, validation, and rollback between eBIZ SMARTZ Business ERP and Epicor Prophet 21. We move data and schema; workflows are rebuilt natively in Epicor Prophet 21.
eBIZ SMARTZ Business ERP
Source
Epicor Prophet 21
Destination
Compatibility
9 of 12
objects map 1:1 between eBIZ SMARTZ Business ERP and Epicor Prophet 21.
Complexity
BStandard
Timeline
6-10 weeks
Overview
Moving from eBIZ SMARTZ Business ERP to Epicor ERP is a cross-platform consolidation that requires mapping eBIZ SMARTZ's consolidated database model onto Epicor Kinetic's segment-based chart of accounts and multi-site organizational structure. eBIZ SMARTZ organizes data around a 360-degree customer view with multi-level cost centers, multi-level approval voucher posting, and a consolidated general ledger spanning operating locations; Epicor Kinetic uses a Site/Plant hierarchy with ERP-specific segment definitions for GL accounts, configure-to-order BOMs, and MES labor tracking. We extract customer master data, order and invoice history, payment records, vendor data, chart-of-accounts entries, and historical journal sequences, then load through Epicor's REST API with BaqAPI lookups for parent-record resolution. Multi-level cost center categories require mapping to Epicor's cost category structure and Site assignments. Workflows, multi-level approval chains, and voucher cancellation logic do not migrate as configuration; we deliver a written inventory of every active approval rule and workflow for the customer's Epicor administrator to rebuild in Epicor Data Analytics or Kinetic Workflow.
Every standard and custom field arrives verified.
AI proposes the map; you confirm before any record moves.
Parent–child, lookups, and ownership stay linked.
Calls, emails, meetings — with original timestamps.
Documents, uploads, and inline notes move with the record.
Why teams make this switch
Leaving
What's pushing teams away
Choosing
What's pulling them in
Object mapping
Each row shows how a eBIZ SMARTZ Business ERP object lands in Epicor Prophet 21, including any object-level transformations, lookup resolution, or schema-design dependencies.
Typical mapping — final map is confirmed during the sample migration step.
eBIZ SMARTZ Business ERP
Customer
Epicor Prophet 21
Customer
1:1eBIZ SMARTZ Customer master records (including consolidated order history and payment records) map to Epicor Kinetic Customer table. The HubSpot 360-degree consolidated view is decomposed: Customer.CustID and Customer.Name map directly; the consolidated order-to-invoice-to-payment history is distributed across SalesOrder, InvcHead, and CashHead with Customer.CustNum as the foreign key. Customer Tax Management fields from eBIZ SMARTZ map to Customer.TaxRegion and Customer.TaxConnectEnabled. We use the Epicor REST API CustomerSvc to upsert by CustID as the dedupe key.
eBIZ SMARTZ Business ERP
Order
Epicor Prophet 21
SalesOrder
1:1eBIZ SMARTZ Order records (with their transactional linkages to invoices and customer accounts across all operating locations) map to Epicor Kinetic OrderHed and OrderDtl. OrderHed carries CustomerNum, OrderNum, and Plant; OrderDtl carries LineNum, PartNum,SellingQuantity, UnitPrice, and Tax attributes. The eBIZ order-to-cash cycle linkage is preserved by importing OrderHed first (to establish OrderNum), then OrderDtl (linked by OrderNum), and finally resolving the open invoice status against InvcHead post-import.
eBIZ SMARTZ Business ERP
Invoice
Epicor Prophet 21
InvcHead / InvcDtl
1:1eBIZ SMARTZ Invoice records map to Epicor Kinetic InvcHead and InvcDtl. Each invoice's reference to its originating order (OrderHed.OrderNum) is preserved as InvcHead.OrderNum so the order-to-cash linkage is queryable via BaqAPI post-migration. Customer Tax Management data from eBIZ SMARTZ maps to InvcHead.TaxRegionCode and InvcHead.LockRate. Invoice receipt status (Knock off in eBIZ SMARTZ) is mapped to InvcHead.InvoiceAmt and InvcHead.Doc invoice balances. We skip eBIZ SMARTZ advance and deposit records as a separate phase because they require AR Credit Memo handling in Epicor.
eBIZ SMARTZ Business ERP
Payment
Epicor Prophet 21
CashHead
1:1eBIZ SMARTZ Payment records (linked to invoices and customer accounts) map to Epicor Kinetic CashHead and CashDtl. CashHead.GroupID and CashHead.TranDate carry the payment date; CashDtl links to InvcHead via InvoiceNum and InvoiceLine to complete the cash application. eBIZ SMARTZ's Inter Bank Transfer and Bank Reconciliation data map to CashHead.BankAcctID and CashHead.TranNum. Bank reconciliation flags from eBIZ SMARTZ are stored in custom fields on CashHead pending the customer's Epicor admin confirmation of the bank reconciliation workflow.
eBIZ SMARTZ Business ERP
Vendor
Epicor Prophet 21
Vendor
1:1eBIZ SMARTZ Vendor Management data (Vendor Opening Balances, Vendor Tax Management, Purchase Invoices, and Invoice Payments) map to Epicor Kinetic Vendor. Vendor.VendorID and Vendor.Name map directly from eBIZ SMARTZ's vendor master. eBIZ SMARTZ's advance and refund deposit records for vendors map to Vendor.CreditPct and AP adjustments in the VendorPayment table. Vendor tax management fields map to Vendor.TaxRegionCode and Vendor.TaxConnectEnabled.
eBIZ SMARTZ Business ERP
Purchase Invoice
Epicor Prophet 21
APInvoice
1:1eBIZ SMARTZ Purchase Invoices (Expense, Services, and Material categories) map to Epicor Kinetic APInvoiceHed and APInvoiceDtl. The invoice knock-off logic for AP (paying purchase invoices against vendor payments) maps to APInvoiceHed.InvoiceAmt and the linked VendorPayments in Epicor. eBIZ SMARTZ Vendor Opening Balances map to APInvoiceHed.DocinvoiceAmt as an opening AP balance rather than a standard invoice.
eBIZ SMARTZ Business ERP
Master Data - Chart of Accounts
Epicor Prophet 21
GL Account
lossyeBIZ SMARTZ's Multi-Level Chart of Account (corporate to division to operating location) maps to Epicor Kinetic's segment-based GL account structure. We first extract the full account code hierarchy from eBIZ SMARTZ, then configure Epicor Kinetic's COA segments to match the source hierarchy: the first segment maps to the corporate-level account, subsequent segments to division and operating location. AccountType and Balance fields (Debit/Credit) map to GLAccount.ActiveFlg and GLAccount.Summarized. This is a configuration step that requires Epicor admin sign-off before GL data loads.
eBIZ SMARTZ Business ERP
Financial Records - General Ledger
Epicor Prophet 21
GLJrnGrp / GLJrnLine
1:1eBIZ SMARTZ General Ledger transactions (Cash Transactions, Bank Transactions, General Transactions, Debit and Credit Notes, Voucher Posting and Cancellation) map to Epicor Kinetic GLJrnGrp (journal group) and GLJrnLine (journal lines). Voucher posting sequence is preserved by setting GLJrnGrp.JournalNum and GLJrnLine.FiscalPeriod and FiscalYear to match the eBIZ SMARTZ posting date and fiscal period. eBIZ SMARTZ Multi-Level Approval status is stored as a custom GLJrnGrp.ApprovalStatus field because Epicor Kinetic approvals are handled at the configuration level. Voucher Cancellation records in eBIZ SMARTZ are stored as negative-offset GLJrnLine entries with a CancellationRef field, not as deletions.
eBIZ SMARTZ Business ERP
Cost-Center Management
Epicor Prophet 21
CostCategory / Site
lossyeBIZ SMARTZ's Multi-Level Cost Center Categories, Multi-Level Cost Centers, and Project-linked cost centers map to Epicor Kinetic CostCategory (the cost center entity) and Site (for site-level cost attribution). We map each eBIZ SMARTZ cost center level to an Epicor Kinetic cost set, and then assign CostCategory codes to Site entities where the operating location is also an Epicor Plant or Warehouse. Project-linked cost centers map to Epicor Project with Project.CostRuthType set to E ( Earned Value). This mapping requires the customer's Epicor admin to confirm the number of Kinetic cost sets and their fiscal period assignment.
eBIZ SMARTZ Business ERP
Operating Location
Epicor Prophet 21
Site / Plant
1:manyeBIZ SMARTZ Corporate Headquarters, Division, and Operating Location structures are decomposed into Epicor Kinetic Site records (for organizational hierarchy) and Plant and Warehouse entities (for operational hierarchy). eBIZ SMARTZ's cascading consolidation model (local forecast to financials) maps to Epicor's multi-site reporting structure, where each Site aggregates its Plant-level data. We use Site.SiteID and Site.Name from the operating location name, and map the division-level entity to an Epicor Business Unit or Region entity configured in the customer's Epicor chart of accounts segment.
eBIZ SMARTZ Business ERP
Employee
Epicor Prophet 21
Employee (Labor)
1:1eBIZ SMARTZ Employee records (HR module data with organizational structures, historical compensation, and benefits) map to Epicor Kinetic Employee. Employee.Num, Name, and Department map to Epicor Kinetic EmpBasic.EmployeeNum and EmpBasic.Name. eBIZ SMARTZ organizational structure maps to Epicor Kinetic EmpBasic.Dept and the LaborDtl table for historical time and attendance records if the customer migrated their HR module alongside the ERP. Benefits and compensation history are stored in custom fields on EmpBasic pending the customer's Epicor HRIS integration decision.
eBIZ SMARTZ Business ERP
Budget
Epicor Prophet 21
BudgetGrp / BudgetDtl
1:1eBIZ SMARTZ Multiple Budgets per period, Verification Mode, Transaction Blocking, and Budget Comparison map to Epicor Kinetic BudgetGrp and BudgetDtl. Budget Comparison variances stored as eBIZ SMARTZ budget reports are preserved as BudgetDtl values with BudgetDtl.BudgetHedID set to the source budget version. eBIZ SMARTZ Transaction Blocking status (which prevents posting to blocked budget lines) maps to a BudgetDtl.BlockedFlg custom field because Epicor Kinetic's standard budget blocking is handled via workflow configuration rather than a flag.
| eBIZ SMARTZ Business ERP | Epicor Prophet 21 | Compatibility | |
|---|---|---|---|
| Customer | Customer1:1 | Fully supported | |
| Order | SalesOrder1:1 | Fully supported | |
| Invoice | InvcHead / InvcDtl1:1 | Fully supported | |
| Payment | CashHead1:1 | Fully supported | |
| Vendor | Vendor1:1 | Fully supported | |
| Purchase Invoice | APInvoice1:1 | Fully supported | |
| Master Data - Chart of Accounts | GL Accountlossy | Fully supported | |
| Financial Records - General Ledger | GLJrnGrp / GLJrnLine1:1 | Fully supported | |
| Cost-Center Management | CostCategory / Sitelossy | Fully supported | |
| Operating Location | Site / Plant1:many | Fully supported | |
| Employee | Employee (Labor)1:1 | Fully supported | |
| Budget | BudgetGrp / BudgetDtl1:1 | Fully supported |
Gotchas + challenges
Platform-specific issues from each side, plus the pair-specific challenges that don't show up on either platform's page on its own.
eBIZ SMARTZ Business ERP gotchas
No public API documentation for self-service extraction
Two distinct products carry similar branding
User-Defined Workflows are configuration data, not transactional records
Custom fields and RepSmith report definitions vary by implementation
Epicor Prophet 21 gotchas
Third-party bolt-on integrations complicate migration scope
Dirty data without standardized processes compounds migration risk
SDK customizations and BPMs may not survive platform upgrades
Report-based export only for non-technical users
Per-user pricing model requires accurate user count before migration planning
Pair-specific challenges
Migration approach
Discovery and source environment audit
We audit the eBIZ SMARTZ database across all active modules: Customer master data and tax configurations, Order and Invoice transactional history, Payment and cash application records, Vendor master and AP invoice data, Chart of accounts and account code hierarchy, GL journal entry sequence and fiscal period assignments, Cost center categories and project-linked cost center structures, Operating location entities and consolidation hierarchy, Employee records and organizational structures, and Budget versions with verification mode settings. We produce a written migration scope that identifies the record counts per entity, the complexity of the chart of accounts hierarchy, the number of active approval chains, and the volume of historical journal entries to sequence. We pair this with an Epicor edition assessment (Epicor Kinetic Essentials for SMB, Epicor Advanced MES for mid-market manufacturing, or Epicor Enterprise for multi-site operations) and confirm whether the customer is moving to Epicor Cloud or on-premises.
Epicor Kinetic schema design and COA segment configuration
We design the destination schema in Epicor Kinetic. This includes configuring the Chart of Accounts segment structure to match the eBIZ SMARTZ multi-level account hierarchy (Natural Account, Department, Division, and Operating Location segments mapped to eBIZ SMARTZ's corporate-to-division-to-location levels), provisioning the Site and Plant hierarchy to mirror the eBIZ SMARTZ operating location structure, defining CostCategory codes and assigning them to Kinetic cost sets, creating UD tables and UD Column Map entries for every eBIZ SMARTZ custom field identified during discovery, and configuring the GL fiscal calendar to match eBIZ SMARTZ's fiscal periods and verification modes. Schema design is validated in the customer's Epicor test environment before any data loads begin.
Data cleansing and de-duplication
We run a data quality assessment across the eBIZ SMARTZ source data before migration. This includes identifying duplicate Customer and Vendor records (common in multi-location deployments where the same entity is entered at corporate and at each operating location), resolving Customer-Vendor conflicts where a counterparty appears in both the eBIZ SMARTZ AR and AP modules, standardizing account codes to match Epicor Kinetic's segment format, cleaning GL journal entries that reference accounts not yet created in the destination COA, and flagging any eBIZ SMARTZ budget versions that reference closed fiscal periods. We deliver a data quality report with record counts before and after cleansing, and the customer approves the cleansed dataset before migration begins.
Sandbox migration and reconciliation
We run a full migration into the customer's Epicor Kinetic sandbox using production-equivalent data volumes. The customer's Epicor administrator and finance team reconcile record counts (Customers in, Vendors in, Open Orders in, Invoices in, GL journal lines in, Cost Centers mapped), spot-check 25-50 randomly selected records against the eBIZ SMARTZ source, and validate that the chart of accounts segment mapping produces the correct GL account codes. Approval chain inventory is reviewed against the documented workflow map. Any mapping corrections or COA segment adjustments happen in the sandbox phase, not in production. The customer signs off the sandbox migration before we proceed to production.
Production migration in dependency order
We run production migration in the following record-dependency order: GL Chart of Accounts and fiscal calendar (to establish account codes before any journal entries), Sites and Plants (to establish operating location entities before any transactional data), CostCategory and cost sets (before any journal entries or cost postings), Customers and Vendors (in parallel, to establish AR and AP counterparties), open Sales Orders (OrderHed before OrderDtl), open Purchase Orders, Invoices and Credit Memos (AR and AP, with order references resolved), Payments and cash application records (CashHead and CashDtl linked to invoices), Employee records (Labor and HR), GL journal entries in fiscal period sequence (GLJrnGrp and GLJrnLine with cancellation references resolved), Budget versions, and finally UD custom field data linked to each entity. Each phase emits a row-count reconciliation report before the next phase begins.
Cutover, validation, and workflow rebuild handoff
We freeze eBIZ SMARTZ write access during the cutover window, run a final delta migration of any records created or modified since the last data pull, then enable Epicor Kinetic as the system of record. We deliver the Multi-Level Approval inventory document, the chart of accounts segment map, and the eBIZ SMARTZ budget version reconciliation report to the customer's Epicor administrator for workflow rebuild. We do not rebuild approval chains, voucher verification workflows, or budget blocking rules as Epicor Kinetic Workflow configuration inside the migration scope; those are handled by the customer's Epicor implementation partner or administrator post-migration. We support a one-week hypercare window where we resolve any record reconciliation issues raised by the customer's finance and operations teams.
Platform deep dives
eBIZ SMARTZ Business ERP
Source
Strengths
Weaknesses
Epicor Prophet 21
Destination
Strengths
Weaknesses
Complexity grading
Standard ERP migration. 2 of 8 objects need a mapping; the rest are 1:1.
Overall complexity
Standard migration
Derived from compatibility, mapping clarity, API constraints, and data volume across eBIZ SMARTZ Business ERP and Epicor Prophet 21.
Object compatibility
2 of 8 objects need a mapping; the rest are 1:1.
Field mapping clarity
Field mapping is derived from defaults — final spec confirmed during the sample migration.
Timeline complexity
8-object category — typical timelines run 2–7 days end-to-end.
API constraints
eBIZ SMARTZ Business ERP: Not publicly documented.
Data volume sensitivity
eBIZ SMARTZ Business ERP doesn't expose a bulk API — REST + parallelization used for high-volume runs.
Estimator
Rule-based pricing — no per-record fees, no manual quotes. Migrations over 2M records are scoped individually.
Step 1
Pick a category, then your source and destination platforms.
Category
FAQ
Answers to the questions buyers ask most during eBIZ SMARTZ Business ERP to Epicor Prophet 21 migration scoping. Not seeing yours? Book a call.
Walk through your eBIZ SMARTZ Business ERP to Epicor Prophet 21 migration with a real engineer — 30 minutes, free, written quote within 24 hours.
Book a free 30 minute consultationAdjacent paths
Other ways to leave eBIZ SMARTZ Business ERP
Other ways to arrive at Epicor Prophet 21
Ready when you are
Tell us record counts and timeline. We'll come back with a written quote inside 1 business day — no commitment, no sales pitch.