ERP migration
Field-level mapping, validation, and rollback between Unit4 ERP and Epicor Prophet 21. We move data and schema; workflows are rebuilt natively in Epicor Prophet 21.
Unit4 ERP
Source
Epicor Prophet 21
Destination
Compatibility
10 of 16
objects map 1:1 between Unit4 ERP and Epicor Prophet 21.
Complexity
BStandard
Timeline
6-10 weeks
Overview
Moving from Unit4 ERP to Epicor ERP is a category shift from service-centric financials to manufacturing-first ERP. Unit4 targets professional services, nonprofits, and public sector with integrated project accounting, fund management, and HCM; Epicor Kinetic serves discrete, make-to-order, and mixed-mode manufacturers with deep shop-floor scheduling, MES, warehouse management, and configure-to-order. The migration requires flattening Unit4's multidimensional account structures (where cost centres and departments act as natural posting axes) into Epicor's flatter chart-of-accounts model, remapping project cost objects to Epicor Jobs and Operations, and resolving the Unit4 Grant/Fund accounting module to either Epicor Projects with funding tracking or a manual fund-administration handoff. We sequence all loads in foreign-key dependency order, validate against Unit4's mandatory-field rules, and reconcile opening balances before and after each phase. Workflows, automations, and report definitions do not migrate as code; we deliver a written inventory for the customer's admin team to rebuild in Epicor Kinetic.
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 Unit4 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.
Unit4 ERP
Customer
Epicor Prophet 21
Customer
1:1Unit4 Customer records with billing address, delivery address, payment terms, tax registration, and credit limits map directly to Epicor Customer. We use Unit4's CUSREF or customer code as the Epicor CustID dedupe key and resolve any split billing or multiple ship-to configurations against Epicor's ShipTo records. Customer-specific pricing matrices migrate to Epicor PriceLbr records if present.
Unit4 ERP
Supplier
Epicor Prophet 21
Vendor
1:1Unit4 Supplier master data including bank details, W-9/W-8 BEN status, and multi-address support transfers to Epicor Vendor. We map Unit4's tax registration and payment terms to Epicor VendorPP records, preserving remittance addresses and bank account details for ACH or wire payment configuration in Epicor.
Unit4 ERP
Chart of Accounts
Epicor Prophet 21
Account Master (COA)
lossyUnit4's multidimensional account structure uses cost centres and departments as natural posting axes alongside account codes. Epicor uses a flatter chart-of-accounts hierarchy where cost elements are modelled separately (as job cost codes, labour codes, and overhead allocation codes). We flatten Unit4's natural-account-plus-dimension combination into Epicor account segments, discussing whether to preserve the full account string or collapse into a simplified COA. This requires alignment on whether the customer wants cost-centre reporting in Epicor Projects/Jobs or as a separate reporting dimension.
Unit4 ERP
Cost Centre and Department
Epicor Prophet 21
Job Cost Code and Labour Code
lossyUnit4's cost centres and departments (which carry posting rules, budget controls, and HCM assignments) require transformation for Epicor. We discuss three options: mapping cost centres to Epicor Job Cost Codes (JobPart.CostCode) for manufacturing cost tracking, mapping to Department codes in Epicor Project/Billing for services cost tracking, or storing them as a reporting dimension in Epicor's FRx reporting layer. The choice depends on whether the customer's post-migration primary use case is manufacturing or project services.
Unit4 ERP
Item
Epicor Prophet 21
Part and Product
1:1Unit4 Items with GL mapping, cost price, sales price, stock control flags, and complex pricing matrices map to Epicor Part (for manufactured or stocked items) and Product (for non-stocked items). We resolve Unit4's stock-control flags against Epicor's Part Type (Stock, Make-to-Order, Phantom, Service) and preserve pricing tiers in Epicor PriceLbr. Unit4's BOM structures migrate to Epicor's Bill of Materials (EBOM or MBOM) if the customer is transitioning to manufacturing on Epicor.
Unit4 ERP
GL Account
Epicor Prophet 21
GL Account
1:1General Ledger accounts with account type, posting controls, and currency settings migrate directly from Unit4 to Epicor's GL Account master. Account codes and descriptions transfer as-is; posting controls (debit/credit rules, intercompany flags) are translated into Epicor's AcctType and JCDept fields. Currency settings map from Unit4's multi-currency configuration to Epicor's CurrencyMode.
Unit4 ERP
Open AP/AR
Epicor Prophet 21
AP Invoice / AR Invoice
1:1Outstanding AP and AR documents (invoices, credit memos, payment applications) carry forward as open records in Epicor. We map document headers and line items with due dates, amounts, currency, and tax lines preserved. In Epicor, open AP lands in APInvoiceHed and APInvoiceDtl; open AR lands in InvoiceHed and InvoiceDtl. Document references and payment terms transfer to support continued payment matching and ageing reporting.
Unit4 ERP
Journal Entries
Epicor Prophet 21
GL Journal Entry
1:1Posted journal entries with header, lines, and audit stamps transfer as locked records in Epicor. We preserve posting dates, source references, user stamps, and journal descriptions to maintain audit trails. Unit4's multi-dimensional postings (account plus cost-centre plus department) translate to Epicor's GLJrnDtl entries with the flattened account and the relevant cost-code or department reference resolved at migration time. A configured date-window (typically last two to three fiscal years) limits scope to avoid excessive migration load volumes.
Unit4 ERP
Historical Transactions
Epicor Prophet 21
GL Detail
lossyUnit4 stores years of journal history across relational tables. Full historical extraction requires SQL access or GCON4 MFL export. We scope the date range with the customer, typically migrating two to three fiscal years for audit continuity and optionally archiving older periods as a structured data package outside Epicor. Each loaded journal batch is reconciled against Unit4's trial balance before the next phase begins.
Unit4 ERP
Tax Code
Epicor Prophet 21
Tax Master
1:1Unit4 holds country-specific tax matrices with rates, jurisdictions, and posting rules across 30+ countries. We map these to Epicor TaxConnect or Epicor's internal TaxMaster records, preserving rate, tax type, and applicable transaction types. Jurisdiction combinations that do not map directly to Epicor's tax engine are flagged for manual review and configuration in the destination before the first live transaction.
Unit4 ERP
Fixed Asset
Epicor Prophet 21
Asset Master
1:1Asset master records include depreciation schedules, cost-centre assignments, insurance values, and asset classification. Unit4 and Epicor may use different depreciation methods (straight-line, declining balance, units-of-production); we align on a per-asset-class conversion approach, setting the Epicor depreciation method and book-life to match the Unit4 original values, and store the original depreciation history in a custom field for audit purposes.
Unit4 ERP
Bank/Cash Account
Epicor Prophet 21
Bank Account
1:1Bank account masters with currency, account type, bank code, and reconciliation settings migrate directly to Epicor's BankAcct table. Opening balances are mapped and reconciled in Epicor's cash-reconciliation module post-migration. Any intercompany bank accounts are flagged for manual setup in Epicor since intercompany configuration is destination-specific.
Unit4 ERP
Employee
Epicor Prophet 21
Employee / Worker
lossyUnit4 HCM holds employment history, compensation, job titles, and department assignments. Epicor does not include a native HCM module; we migrate Employee records as Epicor Employee records (for manufacturing labour and time-tracking use cases) and note that full HCM, payroll, and talent management data requires a separate HR system migration or retention in Unit4 if the customer runs a split-stack. We flag any effective-dated employment changes that require sequencing against Epicor's labour reporting structure.
Unit4 ERP
Project (with cost tracking)
Epicor Prophet 21
Job and Project
lossyUnit4 Projects with WBS elements, cost objects, billing rates, and resource assignments require transformation for Epicor's job cost model. We map Unit4 project hierarchies to Epicor Jobs (for manufacturing and work-order cost tracking) or Epicor Projects (for project-services billing and resource planning). The customer's choice between Job-based and Project-based cost tracking is made during scoping. Unit4's project-to-GL mappings and billing rate tables transfer to Epicor's Job and Project billing configurations. Multi-customer project splitting migrates to Epicor's Multi-Company Project structure if applicable.
Unit4 ERP
Grant (fund accounting)
Epicor Prophet 21
Project with Funding Tracking
lossyUnit4 Grant management with donor restrictions, fund balances, and statutory reporting for nonprofits and public-sector bodies maps partially to Epicor Projects with funding tracking. We map grant codes, funding allocations, and spend-vs-budget records to Epicor Project and ProjectPhase with a custom funding-tracking extension. Full fund-accounting compliance (restricted vs unrestricted fund classification, donor reporting by grant) requires post-migration configuration in Epicor or a fund-accounting add-on; we document the gap and deliver a written specification for the customer's admin to resolve.
Unit4 ERP
Document
Epicor Prophet 21
Document and Attachment
1:1Unit4 document attachments against transactions and master records are extracted via the document management API and re-associated in Epicor against the corresponding Customer, Vendor, Part, or Job record. File-size limits and format restrictions in Epicor's doc2 and Image thumbnail stores are discussed during scoping; extremely large files or non-standard formats may be stored in an external DMS with a link reference in Epicor.
| Unit4 ERP | Epicor Prophet 21 | Compatibility | |
|---|---|---|---|
| Customer | Customer1:1 | Fully supported | |
| Supplier | Vendor1:1 | Fully supported | |
| Chart of Accounts | Account Master (COA)lossy | Mapping required | |
| Cost Centre and Department | Job Cost Code and Labour Codelossy | Fully supported | |
| Item | Part and Product1:1 | Fully supported | |
| GL Account | GL Account1:1 | Fully supported | |
| Open AP/AR | AP Invoice / AR Invoice1:1 | Fully supported | |
| Journal Entries | GL Journal Entry1:1 | Fully supported | |
| Historical Transactions | GL Detaillossy | Mapping required | |
| Tax Code | Tax Master1:1 | Fully supported | |
| Fixed Asset | Asset Master1:1 | Fully supported | |
| Bank/Cash Account | Bank Account1:1 | Fully supported | |
| Employee | Employee / Workerlossy | Fully supported | |
| Project (with cost tracking) | Job and Projectlossy | Fully supported | |
| Grant (fund accounting) | Project with Funding Trackinglossy | Fully supported | |
| Document | Document and Attachment1: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.
Unit4 ERP gotchas
Forced Agresso-to-Cloud migration creates migration pressure
Object API is read-only by default
ERPx is cloud-only—on-premise deployments unavailable
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 assessment
We audit the Unit4 source environment across both ERPx (cloud) and ERP Continuous Release (on-premise) to identify which product line is in scope, what extraction method is available (Object API with read grants, GCON4 MFL, BIF, or Dataload7), and whether any hybrid cloud-on-premise split is underway. We extract object-level record counts, assess custom field configurations, and identify the dimensional-accounting structure (which cost centres, departments, and projects exist as posting axes). We pair this with a scoping call to confirm Epicor deployment model (cloud or on-premise), Epicor edition, and the customer's primary post-migration use case (manufacturing, distribution, or mixed-mode). The discovery output is a written migration scope and extraction plan.
Dimensional-accounting design and chart-of-accounts flattening
We design the Epicor chart-of-accounts structure based on the Unit4 dimensional-accounting analysis. This includes defining how Unit4's account-plus-cost-centre-plus-department combinations map to Epicor account segments and Job Cost Codes, choosing whether cost-centre reporting lives in Epicor Projects, Jobs, or a separate reporting dimension, and configuring the COA hierarchy in Epicor's GL Account Master. Epicor's account structure is deployed via Epicor REST API or Epicor Administration Console into a Sandbox environment for validation before any data loads.
Sandbox migration and reconciliation
We run a full migration into Epicor Kinetic Sandbox using production-like data volumes. The customer's finance and operations leads reconcile record counts (Customers in, Vendors in, GL accounts in, AP/AR open items in, Projects/Jobs in), spot-check 25-50 records against the Unit4 source, and validate that the chart-of-accounts flattening produces correct trial-balance results. The grant/fund-accounting handoff specification is reviewed if grant data is in scope. Any mapping corrections happen in the Sandbox phase, not in production.
Master data migration in dependency order
We run production migration in strict foreign-key dependency order: GL Account structure (first, since all transactions reference accounts), Customers, Vendors, Parts and Products, Tax Codes, Fixed Assets, Bank Accounts, then Employees and Workers. Each phase emits a row-count reconciliation report before the next phase begins. AP/AR open items follow master data, mapped to Epicor's APInvoiceHed/APInvoiceDtl and InvoiceHed/InvoiceDtl tables. Grant funding allocations and project cost structures load last since they reference all upstream master records.
Historical journal migration and trial-balance reconciliation
We migrate journal entries within the agreed date window (typically two to three fiscal years) using Unit4's extraction method (SQL, GCON4 MFL, or BIF output) transformed into Epicor GLJrnDtl format. Each journal batch is reconciled to Unit4's trial balance at the period level before the next batch loads. Epicor's GLPost check runs after each period to confirm that debits equal credits. Older historical periods outside the migration window are archived as a structured data package with an index for audit retrieval.
Cutover, validation, and automation inventory handoff
We freeze Unit4 writes during cutover, run a final delta migration of any records modified during the migration window, then confirm Epicor as the system of record. We reconcile open AP/AR ageing, project cost-to-date, and fixed-asset book values against Unit4's pre-migration reports. We deliver the Workflow, automation, and report-definition inventory document to the customer's admin team. We support a one-week post-cutover reconciliation window. We do not rebuild Unit4 workflows, automations, or report definitions as Epicor Kinetic equivalents; that work is handled by the customer's Epicor administrator or an implementation partner.
Platform deep dives
Unit4 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 Unit4 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
Unit4 ERP: Not publicly documented.
Data volume sensitivity
Unit4 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 Unit4 ERP to Epicor Prophet 21 migration scoping. Not seeing yours? Book a call.
Walk through your Unit4 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 Unit4 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.