ERP migration

Migrate from Acumatica to Epicor Prophet 21

Field-level mapping, validation, and rollback between Acumatica and Epicor Prophet 21. We move data and schema; workflows are rebuilt natively in Epicor Prophet 21.

Acumatica logo

Acumatica

Source

Epicor Prophet 21

Destination

Epicor Prophet 21 logo

Compatibility

73%

11 of 15

objects map 1:1 between Acumatica and Epicor Prophet 21.

Complexity

BStandard

Timeline

8-12 weeks

Rollback included Accuracy guarantee Field-level validation

Try the reverse

Epicor Prophet 21
Acumatica

Overview

What this migration involves

Moving from Acumatica to Epicor ERP is a platform migration that requires resolving Acumatica's multi-tenant CompanyID isolation, its UDF extension field pattern (stored under a 'custom' namespace in the REST API), and its separate Note and NoteDoc table structure. Epicor ERP organizes data around Company, Site, Warehouse, Customer, Supplier, Part, and Project entities with a different foreign-key model than Acumatica's normalized schema. We sequence the migration by extracting Acumatica records filtered by the scoped TenantID, mapping Acumatica Business Accounts to Epicor Customers and Vendors to Suppliers, resolving warehouse and site assignments, and importing BOM and routing data for manufacturing customers into Epicor's product configuration tables. Workflows, notification sets, and custom screens built on Acumatica's Customization Project framework do not migrate; we deliver a written inventory of these for the customer's implementation team to rebuild in Epicor.

Field-level fidelity

Every standard and custom field arrives verified.

Schema-aware mapping

AI proposes the map; you confirm before any record moves.

Relationships preserved

Parent–child, lookups, and ownership stay linked.

Full activity history

Calls, emails, meetings — with original timestamps.

Attachments & notes

Documents, uploads, and inline notes move with the record.

Why teams make this switch

Two sides of the same decision

Leaving

Acumatica logo

Acumatica

What's pushing teams away

  • A steep learning curve and complex initial setup frustrate new users, with the report designer drawing particular criticism for its unintuitive interface.
  • Missing features force reliance on customizations or add-ons — a 2023 survey shows nearly a quarter of reviewers cite feature gaps as a pain point.
  • Implementation timelines stretch to 6-12 months for complex deployments, creating a significant resource commitment before any productivity return.
  • The difficult and overwhelming setup experience leads some companies to seek alternatives that offer faster time-to-value.
  • Integration with e-commerce and third-party platforms requires custom development effort that many SMBs underestimate during vendor selection.

Choosing

Epicor Prophet 21 logo

Epicor Prophet 21

What's pulling them in

  • Industry-specific design for wholesale distributors, not a general-purpose ERP repurposed for distribution — distributors choose P21 because it matches their replenishment, kitting, and counter-sale workflows out of the box.
  • Strong inventory control with automated replenishment, lot and serial tracking, and multi-warehouse management appeals to distributors with complex stock requirements and tight margin pressure.
  • Responsive customer support cited across G2 and Gartner reviews, with Epicor's 90% retention rate reflecting long-term customer satisfaction in a market where switching costs are high.
  • Cloud deployment on Microsoft Azure provides the flexibility to scale user counts and warehouse locations without on-premise infrastructure investment.
  • The Software Development Kit lets distributors personalize P21 to their specific business processes without modifying the application source code, preserving upgrade paths.

Object mapping

How Acumatica objects map to Epicor Prophet 21

Each row shows how a Acumatica 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.

Acumatica

Business Account (Customer)

maps to

Epicor Prophet 21

Customer

1:1
Fully supported

Acumatica Business Accounts with Customer marked as primary map to Epicor Customer. The Acumatica CustomerClass and CreditTerms map to Epicor CustomerType and PaymentTerms. Address records in Acumatica (Location table) map to Epicor CustomerPriceHdr/CustomerShipTo addresses. We preserve the primary contact name and email as Customer.AllowShipTo changes to no flag. Multi-entity Acumatica customers with separate CompanyIDs may map to separate Epicor companies or to divisions within one Epicor company depending on the customer's chosen organizational structure.

Acumatica

Business Account (Vendor)

maps to

Epicor Prophet 21

Supplier

1:1
Fully supported

Acumatica Vendors map to Epicor Supplier. AP settings, payment terms, and tax registration IDs transfer to Epicor Supplier rows. Vendor addresses map to Epicor SupplierPriceHdr/ShipVia addresses. If the Acumatica Business Account serves as both Customer and Vendor, we create separate Customer and Supplier records in Epicor linked by the same name.

Acumatica

Inventory Item (Stock/Non-Stock)

maps to

Epicor Prophet 21

Part

1:1
Fully supported

Acumatica Inventory Items map to Epicor Part records. Stock items carry warehouse-specific AvailabilityQty data that maps to PartWhse OnHandQty by Site and Warehouse. Non-stock items map to Part with TypeCode = Non-Stock. Units of Measure from Acumatica map to Epicor's UOMClass and UOM conversions. The Acumatica ItemClass determines the Epicor Part Class group. AvailabilityQty is derived at migration time by aggregating warehouse-level stock records.

Acumatica

Bill of Materials

maps to

Epicor Prophet 21

JobMtl (BOM)

lossy
Fully supported

Acumatica BOMs defined on Inventory Items map to Epicor JobMtl and PartMtl (depending on whether the customer uses make-to-stock or make-to-order). We extract the BOM structure with line quantities, scrap factors, and bill sequence, then create Epicor PartMtl records linked to the parent Part. If Acumatica maintains multiple BOM revisions, we migrate the most recent active revision and flag revision history for manual handoff.

Acumatica

Routing / Production Operator

maps to

Epicor Prophet 21

PartOpSeq and JobOper

lossy
Fully supported

Acumatica production routings map to Epicor PartOpSeq (for standard routing definitions) and JobOper (for job-specific operations). Work centers from Acumatica map to Epicor Workstations and ResourceGroups. If Acumatica uses Project-based production with tasks, those map to Epicor JobHead with project-linked job numbering.

Acumatica

Chart of Accounts

maps to

Epicor Prophet 21

GL Account

1:1
Fully supported

Acumatica GL Accounts map to Epicor GLAccount with account class, type, subaccount mask, and active/inactive status preserved. Subaccount segmentation from Acumatica maps to Epicor's segment structure if the customer uses multi-segment account codes. We preserve the account hierarchy and map the AccountClass to Epicor's Category field for reporting grouping.

Acumatica

Project

maps to

Epicor Prophet 21

Project

1:1
Fully supported

Acumatica Projects map to Epicor Project with budgets, tasks, and change orders preserved. Project attributes and user-defined fields migrate to Epicor Project-level UD fields. If the Acumatica project uses Project-based billing or revenue recognition, we map those settings to Epicor Project and ProjectPhase billing rules. Project hierarchies with sub-projects map to Epicor ProjectPhase records.

Acumatica

Sales Order

maps to

Epicor Prophet 21

OrderHed and OrderDtl

1:1
Fully supported

Acumatica Sales Orders map to Epicor OrderHed (header) and OrderDtl (lines). Document status (on hold, pending fulfillment, completed) preserves to allow reactivation in Epicor. Line items carry item, quantity, warehouse assignment, and tax category. Tax calculation settings on customer and inventory item combine to produce the Epicor tax liability on import. Open versus closed status governs whether we import the full history or only open documents.

Acumatica

Purchase Order

maps to

Epicor Prophet 21

POHeader and PODetail

1:1
Fully supported

Acumatica Purchase Orders map to Epicor POHeader and PODetail. Vendor, line items, receipts, and amendments are extracted as related records. Receipts and amendments in Acumatica use separate schemas and migrate as separate linked records in Epicor with appropriate PO line references. Closed PO history migrates if the customer requires it; otherwise we migrate open POs only.

Acumatica

AR Invoice

maps to

Epicor Prophet 21

ARInvoice

1:1
Fully supported

Open AR invoices from Acumatica carry payment schedules, terms, and aging data. We map customer invoices to Epicor AR Invoice with the aging bucket assignments preserved. Historical invoices referencing balance tables require careful sequencing to maintain GL impact. Closed AR history can be migrated as a reference record without posting impact if the customer requires an audit trail.

Acumatica

AP Invoice

maps to

Epicor Prophet 21

APInvoice

1:1
Fully supported

Open AP invoices from Acumatica map to Epicor AP Invoice with vendor, invoice number, date, and amount. Terms and payment schedules transfer. GL batch references from Acumatica map to Epicor GL Journal entries for reconciliation. We flag any prepayment or credit memo records that require separate handling in Epicor's prepayment workflow.

Acumatica

Employee

maps to

Epicor Prophet 21

Employee

1:1
Fully supported

Acumatica Employee records include compensation history, department assignments, and timecard data. Employment status, job titles, and earning codes preserve. Effective-dated rows (such as compensation changes) migrate as separate records with the effective date carried forward. We map the Acumatica Department to Epicor Class for labor reporting.

Acumatica

Warehouse/Location

maps to

Epicor Prophet 21

Site and Warehouse

1:many
Fully supported

Acumatica Warehouse records with bin structures map to Epicor Plant (Site) and Warehouse. Each Acumatica warehouse with bins becomes an Epicor Site with one or more Warehouses containing Bin records. Warehouse assignments on inventory items map to PartWhse records linking Part to Site and Warehouse.

Acumatica

Custom Field (UDF)

maps to

Epicor Prophet 21

User-Defined Field

lossy
Fully supported

Acumatica UDFs on any entity (Business Account, Vendor, Inventory Item, Project, etc.) use the extension DAC pattern and appear under a 'custom' namespace in the REST API. We discover all UDF definitions via the entity schema endpoint before building field mappings. Each UDF maps to an Epicor UD field on the equivalent entity, with Acumatica CustomStringField, CustomDateField, and CustomNumberField types mapped to Epicor string, date, and number UD field types.

Acumatica

Note and NoteDoc

maps to

Epicor Prophet 21

Document Management / Linked Note

1:1
Fully supported

Acumatica Note text and file attachments stored in the separate Note and NoteDoc tables are not first-class API entities. We extract note content, entity reference (EntityID plus EntityType), and NoteDoc binary files separately, then re-link them in Epicor using the DocReference table or embedded note fields on the target entity depending on Epicor's configuration.

Gotchas + challenges

What specifically takes care here

Platform-specific issues from each side, plus the pair-specific challenges that don't show up on either platform's page on its own.

Acumatica logo

Acumatica gotchas

High

API user licenses cap concurrent sessions and request throughput

High

Multi-tenant filtering requires CompanyID awareness

Medium

Custom fields require separate discovery before field mapping

Medium

Notes and attachments use a separate linked table structure

Low

Implementation timelines frequently run 3–9 months end-to-end

Epicor Prophet 21 logo

Epicor Prophet 21 gotchas

High

Third-party bolt-on integrations complicate migration scope

High

Dirty data without standardized processes compounds migration risk

Medium

SDK customizations and BPMs may not survive platform upgrades

Medium

Report-based export only for non-technical users

Low

Per-user pricing model requires accurate user count before migration planning

Pair-specific challenges

  • Acumatica multi-tenant CompanyID filtering must be enforced at extraction

    Acumatica's multi-tenancy places a CompanyID (TenantID) column on every table and uses a CompanyMask bitmask for shared records. If extraction queries do not scope to the correct tenant, records from the wrong company load into Epicor or foreign-key errors occur on cross-tenant references. We require the tenant ID during scoping and apply it as a filter on every extraction query. For Acumatica configurations with inter-company transactions, we extract each company separately and provision corresponding Epicor companies before importing.

  • Acumatica UDFs require explicit schema discovery before field mapping

    User-defined fields in Acumatica are not visible in the standard API entity list. They appear under a 'custom' namespace with CustomStringField, CustomDateField, or CustomNumberField type patterns. A common mistake during migration is treating UDFs as standard fields and mapping them as siblings instead of as named properties within the correct entity block, causing silent field loss. We query the entity schema endpoint for every migrated object to discover all UDF definitions before building the field map.

  • Epicor BOM and routing migration requires separate transform from inventory items

    Epicor separates Part master data from manufacturing definitions (BOMs, routings, work centers). Acumatica stores BOMs as linked records on Inventory Items, which can include multiple active and revision versions. We extract the BOM structure separately from the Part master, map the active revision to PartMtl in Epicor, and flag revision history for the customer's implementation team to configure in Epicor's revision control. Migrations that attempt to merge BOM and Part imports cause constraint violations because PartMtl references a PartID that may not yet exist.

  • Notes and NoteDoc tables lack first-class API representation in Acumatica

    Acumatica Note records (text, entity reference, NoteID) and NoteDoc records (binary file storage link) use a separate linked table structure that is not exposed as first-class API entities. We must extract Note text, EntityID, EntityType, and NoteDoc binaries independently and then re-link them in Epicor using DocReference or embedded notes. If Epicor's document management is not configured at migration time, we fall back to embedding note text in a custom note field and storing files as record attachments, which requires a separate post-migration cleanup step.

  • Epicor company and site provisioning must precede transactional imports

    Epicor organizes data hierarchically: Company contains Plant (Site) contains Warehouse contains Bin. Acumatica's multi-tenant CompanyID does not map directly to Epicor Company; the customer must decide whether each Acumatica company becomes a separate Epicor Company, a Plant within one Epicor Company, or a Division under a Plant. We cannot import transactional records (Orders, POs, Inventory transactions) until the Epicor organizational hierarchy is configured because PartWhse, Customer, and Supplier records all require a Site reference. This creates a hard sequencing dependency that extends project timelines for multi-company Acumatica deployments.

Migration approach

Six steps for a successful Acumatica to Epicor Prophet 21 data migration

  1. Discovery and organizational design

    We audit the Acumatica source environment across license tier (Essentials through Enterprise), active modules (Financials, Distribution, Manufacturing, CRM), CompanyID list and inter-company transaction volume, UDF definitions on all migrated entities, BOM and routing presence on Inventory Items, Project hierarchies and change order volume, and open versus closed document counts for Orders, POs, and invoices. We pair this with an Epicor organizational design session: one Epicor Company per Acumatica Company, or consolidation under one Company with Plants per tenant. The discovery output is a written migration scope, organizational hierarchy map, and a UDF inventory for every source entity.

  2. Epicor company and site provisioning

    Before any data import, we provision the Epicor Company, Plant (Site), and Warehouse hierarchy in the destination environment. This is a prerequisite for all subsequent record imports because PartWhse records, Customer address assignments, and Supplier shipping records require a valid Site reference. We coordinate with the customer's Epicor administrator or implementation partner to configure the organizational structure using Epicor Data Management tools or direct database provisioning. This step cannot run in parallel with data extraction from Acumatica because the destination key structure must be stable before we begin inserting records.

  3. GL chart and account mapping

    We extract the Acumatica Chart of Accounts with account class, type, subaccount mask, and active/inactive status. We map each Acumatica account to an Epicor GLAccount, preserving subaccount segmentation if the customer uses multi-segment codes. GL account validation rules and posting definitions in Acumatica map to Epicor Account segments and book codes. This phase runs before any transactional imports because every AR/AP/GL entry references account numbers.

  4. Master data migration in dependency order

    We run master data migration in strict dependency order: GL Accounts first (all transaction references depend on them), then Part Classes, then Parts (Stock and Non-Stock with PartWhse per Site), then PartMtl and PartOpSeq for BOM and routing, then Customers and Suppliers with address records, then Employees, then Projects with phase and budget structures. Each phase emits a row-count reconciliation report and a random-record spot-check against the Acumatica source before the next phase begins. Custom fields migrate during each phase as named properties within the entity payload.

  5. Transactional record migration

    With master data stable and foreign keys resolved, we migrate open Sales Orders, Purchase Orders, AR invoices, and AP invoices. We preserve document status to allow reactivation in Epicor. Closed transaction history migrates if scoped, using a lower-priority batch with separate reconciliation reporting. Activity history (if scoped) migrates via Epicor's REST API with batch chunking and parent-record lookup resolution.

  6. Sandbox migration and production validation

    We run a full migration into an Epicor Sandbox environment using production-like data volume. The customer's operations team reconciles record counts (Customers in, Suppliers in, Parts in, open Orders in, open POs in), spot-checks fifty random records against the Acumatica source, and signs off the schema and mapping before production migration begins. Any BOM mapping corrections, site assignments, or UDF type mismatches surface here and are resolved before production cutover.

  7. Production cutover and workflow handoff

    We freeze Acumatica writes during cutover, run a final delta migration of any records modified during the migration window, then enable Epicor as the system of record. We deliver a written inventory of Acumatica workflows, notification sets, and customization projects (screen-level customizations, extension projects, and custom reports) that require rebuild in Epicor using its Business Event Manager, Report Designer, and Customization Framework. We do not rebuild these as part of the migration scope. We support a one-week hypercare window to resolve reconciliation issues raised during the first production week.

Platform deep dives

Context on both ends of the pair

Acumatica logo

Acumatica

Source

Strengths

  • Unlimited named-user licensing eliminates per-seat cost scaling as teams grow.
  • Modular architecture lets companies deploy Financials first and add Distribution, Manufacturing, or CRM incrementally.
  • Cloud-native with automatic updates removes infrastructure patching and version management from IT responsibilities.
  • Flexible customization framework (UDFs, extensions) supports vertical-specific workflows without forking core code.
  • Multi-tenant architecture with CompanyID isolation enables safe data segregation across subsidiaries.

Weaknesses

  • Steep learning curve and complex initial setup create significant onboarding friction.
  • Report Designer is widely cited as unintuitive and difficult to use for non-developers.
  • Feature gaps require customizations or third-party add-ons, adding implementation cost and complexity.
  • Implementation timelines frequently exceed initial estimates, especially for multi-module deployments.
  • API rate limits and concurrent session caps are tied to license tier, creating throughput constraints for bulk data operations.
Epicor Prophet 21 logo

Epicor Prophet 21

Destination

Strengths

  • Purpose-built for wholesale distribution with industry-specific replenishment, kitting, and counter-sale workflows out of the box.
  • Multi-warehouse management with bin locations, cross-docking, and real-time inventory visibility across all warehouse locations.
  • Automated replenishment engine with demand-based and min-max planning reduces stockouts and overstock carrying costs.
  • AI-infused reporting via Epicor Prism provides Gen AI-driven insights into ERP data without requiring a BI team.
  • Strong customer retention at 90% and a 50-year track record in the distribution vertical provides long-term vendor stability.

Weaknesses

  • High total cost of ownership — per-user pricing of $150-200/month plus $10K-$500K implementation creates significant budget commitment for small and mid-market distributors.
  • Customization via SDK requires technical expertise and introduces upgrade risk when custom code conflicts with new P21 releases.
  • Report generation performance is a known pain point — multiple users report system freezes during large or complex report exports.
  • Third-party bolt-on reliance for functionality that competitors include natively increases integration complexity and total solution cost.
  • Limited public API documentation — developers building custom integrations report difficulty finding P21 API authentication methods and endpoint specifications.

Complexity grading

How hard is this migration?

Standard ERP migration. 3 of 8 objects need a mapping; the rest are 1:1.

B

Overall complexity

Standard migration

Derived from compatibility, mapping clarity, API constraints, and data volume across Acumatica and Epicor Prophet 21.

  • Object compatibility

    B

    3 of 8 objects need a mapping; the rest are 1:1.

  • Field mapping clarity

    C

    Field mapping is derived from defaults — final spec confirmed during the sample migration.

  • Timeline complexity

    B

    8-object category — typical timelines run 2–7 days end-to-end.

  • API constraints

    B

    Acumatica: Licensed by tier — limits visible in License Monitoring Console (SM604000). Community reports suggest ~100 API calls/minute on standard licenses, with higher limits on Enterprise. Concurrent web service sessions are also license-restricted..

  • Data volume sensitivity

    B

    Acumatica doesn't expose a bulk API — REST + parallelization used for high-volume runs.

Estimator

Estimate your Acumatica to Epicor Prophet 21 migration cost

Rule-based pricing — no per-record fees, no manual quotes. Migrations over 2M records are scoped individually.

Step 1

What are you migrating?

Pick a category, then your source and destination platforms.

Category

FAQ

Frequently asked questions about Acumatica to Epicor Prophet 21 data migrations

Answers to the questions buyers ask most during Acumatica to Epicor Prophet 21 migration scoping. Not seeing yours? Book a call.

Can't find your answer?

Walk through your Acumatica to Epicor Prophet 21 migration with a real engineer — 30 minutes, free, written quote within 24 hours.

Book a free 30 minute consultation

Most migrations land between eight and twelve weeks for accounts under 15,000 Business Accounts, 8,000 Inventory Items, and no manufacturing data (BOMs, routings). Migrations with multi-site Epicor deployments, active BOM and routing tables, large project histories (over 500,000 project transaction records), or multi-company Acumatica configurations requiring separate Epicor company provisioning move to fourteen to twenty-two weeks because of Epicor organizational hierarchy configuration, BOM transform work, and parent-record dependency sequencing.

Adjacent paths

Related migrations to explore

Ready when you are

Move from Acumatica.
Land in Epicor Prophet 21, intact.

Tell us record counts and timeline. We'll come back with a written quote inside 1 business day — no commitment, no sales pitch.

Accuracy guarantee Rollback included Quote in 1 business day