ERP migration
Field-level mapping, validation, and rollback between BusinessCloud and Epicor Prophet 21. We move data and schema; workflows are rebuilt natively in Epicor Prophet 21.
BusinessCloud
Source
Epicor Prophet 21
Destination
Compatibility
13 of 14
objects map 1:1 between BusinessCloud and Epicor Prophet 21.
Complexity
CModerate
Timeline
6-10 weeks
Overview
Migrating from BusinessCloud to Epicor ERP requires solving two problems simultaneously: extracting data from a platform with no publicly documented bulk export endpoint, and mapping BusinessCloud's undocumented schema to Epicor's well-structured Kinetic data model. We address the first by requesting a full database export directly from BusinessCloud support and supplementing with API probing where available, then reverse-engineering the schema from the exported data before designing the Epicor target schema. We address the second by creating a migration staging layer that handles BusinessCloud's custom tables, user-defined fields, and regional code conventions (common in MENA-region deployments) and translates them to Epicor's standard Part, Customer, Vendor, and GL Account structures. Historical transactional history migrates into Epicor's production journal and financial audit trails. We do not migrate BusinessCloud workflows, automations, or report definitions as code; these require a written inventory for the customer's Epicor admin to rebuild using Kinetic business rules and App Studio.
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 BusinessCloud 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.
BusinessCloud
Customer
Epicor Prophet 21
Customer
1:1BusinessCloud Customer records map to Epicor Customer. BusinessCloud's regional fields (MENA address formats, tax registration numbers for VAT/GST in GCC countries) migrate to Epicor Customer standard address fields plus UD fields we create during schema provisioning. Arabic-language customer names migrate to Epicor's Name field with a secondary Latin-name UD field for English-language reporting. The customer account code from BusinessCloud becomes Epicor's Customer ID; we validate for uniqueness before import.
BusinessCloud
Vendor
Epicor Prophet 21
Supplier
1:1BusinessCloud Vendor records map to Epicor Supplier. GCC tax registration (VAT/TRN), payment terms specific to MENA markets, and multi-bank account details for international payments migrate to Epicor Supplier standard fields and UD fields. Supplier classifications (manufacturer, distributor, trader) from BusinessCloud map to Epicor Supplier Type if present, or to a custom Supplier Class UD field we create during provisioning.
BusinessCloud
Product
Epicor Prophet 21
Part
1:1BusinessCloud Product records map to Epicor Part. BusinessCloud fields including SKU, description, unit of measure, and cost price map directly to Epicor Part.PartNum, Part.Description, Part.IUM, and Part.StandardCost. Part Type (make, buy, or service) requires a mapping decision based on BusinessCloud's product classification. If BusinessCloud tracks lot numbers or serial numbers, these migrate to Epicor's PartLot and PartBin structures. We create UD fields for any BusinessCloud product attributes that have no Epicor standard equivalent.
BusinessCloud
Inventory
Epicor Prophet 21
PartPlant + WarehseBin
1:1BusinessCloud inventory quantities and warehouse assignments map to Epicor PartPlant (per-site quantity and ordering data) and WarehseBin (per-location quantities). The warehouse code mapping requires a reconciliation step because BusinessCloud warehouse naming conventions may differ from the Epicor site-warehouse structure. On-hand values migrate to Epicor's PartQtyOnHand table with a post-migration inventory valuation check against BusinessCloud's financial inventory value.
BusinessCloud
Chart of Accounts
Epicor Prophet 21
GL Account
1:1BusinessCloud GL Account structure migrates to Epicor's COA (Chart of Accounts). We preserve the BusinessCloud account code as the Epicor Account field and the account description as the Epicor Description field. If BusinessCloud uses a segment-structured account code (common in MENA financial reporting), we map each segment to an Epicor financial dimension segment. GCC companies with VAT/GST reporting requirements ensure the COA includes VAT input and output accounts matching Epicor's tax category configuration.
BusinessCloud
Purchase Order
Epicor Prophet 21
POHeader + PODetail
1:1BusinessCloud Purchase Orders migrate to Epicor POHeader and PODetail records. We migrate open POs and recently closed POs (within the retention window defined during scoping). PO line items map to PODetail with supplier part number cross-referenced via Epicor's PartXRef table. Tax amounts from BusinessCloud's VAT/GST calculations migrate to Epicor POHeader.TaxAmt as UD fields or into Epicor's tax integration if the customer activates Avalara or Vertex.
BusinessCloud
Sales Order
Epicor Prophet 21
OrderHed + OrderDtl
1:1BusinessCloud Sales Orders migrate to Epicor OrderHed and OrderDtl. Open orders, back orders, and recent completed orders (within the retention window) migrate. Line item pricing, discounts, and tax amounts carry forward as Epicor OrderDtl.DocUnitPrice, OrderDtl.DiscountPercent, and OrderDtl.TaxAmt. We resolve the Epicor Customer and ShipTo records by BusinessCloud customer code match before importing orders so that the foreign key constraint is satisfied.
BusinessCloud
Work Order / Production Order
Epicor Prophet 21
JobHead + JobMtl
1:1If BusinessCloud includes a production module, Work Orders migrate to Epicor JobHead and JobMtl. The Job structure (production sequences, material requirements, labor estimates) maps to Epicor's JobMtl (materials) and JobOper (operations) tables. We flag JobHead.Status as JobEngineered or JobReleased based on BusinessCloud's work order status mapping defined during scoping. If BusinessCloud tracks job cards or labor tickets, these migrate to Epicor LaborDtl records linked to the corresponding JobNum.
BusinessCloud
Bill of Materials
Epicor Prophet 21
ECOMtl + ECOJob
1:1BusinessCloud BOM records migrate to Epicor's engineering change order structure (ECOMtl for bill of materials lines). If BusinessCloud tracks multiple BOM revisions or version-controlled bills, each version migrates as a separate Epicor ECO revision. The top-level part number in BusinessCloud's BOM becomes the Epicor Part.PartNum; child components map to ECOMtl.MtlPartNum with quantity per assembly preserved.
BusinessCloud
Custom Table (BusinessCloud UD)
Epicor Prophet 21
UD Table (Epicor UD100, UD101, etc.)
lossyBusinessCloud custom tables have no documented naming conventions or field schemas. We reverse-engineer the schema from the exported database dump during the discovery phase, map each BusinessCloud custom table to an Epicor User-Defined table (UD100, UD101, UD102, etc.) matching the row data type, and create the corresponding Epicor UD field definitions with appropriate data types (character, number, date, checkbox). Lookup relationships between BusinessCloud custom tables and standard objects are resolved through foreign key columns in the export before Epicor UD table import.
BusinessCloud
Attachments and Documents
Epicor Prophet 21
DocStar / Attachment (ERP standard)
1:1BusinessCloud file attachments linked to Customers, Vendors, Products, or Orders migrate to Epicor's attachment structure (ERP standard or DocStar EDM if the customer licenses it). We extract file blobs from the database dump, restore the file name and MIME type, and link each attachment to the corresponding Epicor record by BusinessCloud's entity-reference ID. We flag attachments that cannot be re-linked because the parent record was not migrated.
BusinessCloud
Financial Transactions (GL Journal)
Epicor Prophet 21
GLJrnGrp + GLJrnDtl
1:1BusinessCloud GL journal entries migrate to Epicor GLJrnGrp (journal batch) and GLJrnDtl (journal line) records. We migrate the current fiscal year and the preceding fiscal year of transactional history based on the customer's reporting retention requirements. Epicor fiscal year setup must be completed before GL migration. Each BusinessCloud journal line debits and credits map to Epicor GLJrnDtl.DebitAmt and CreditAmt. Account segment mappings (from the COA migration) resolve the BusinessCloud account code to the Epicor COACode segment values.
BusinessCloud
AP / AR Transactions
Epicor Prophet 21
APTran + ARTran
1:1BusinessCloud Accounts Payable and Accounts Receivable transactions migrate to Epicor APTran and ARTran records. Open invoices, credit memos, and payments migrate with vendor/customer references preserved. ARTran.LinkOrderNum and APTran.LinkOrderNum tie the transaction to the migrated Sales Order or Purchase Order where applicable. Tax amounts from BusinessCloud's VAT calculations migrate to Epicor's tax integration tables or UD fields based on whether the customer activates Epicor's native tax module.
BusinessCloud
User / Owner
Epicor Prophet 21
User
1:1BusinessCloud Users and Owner records migrate to Epicor User records. We match BusinessCloud user email addresses to Epicor Kinetic User.Email and provision the Epicor User account with the corresponding security group. BusinessCloud role or permission assignments map to Epicor Kinetic Security Role definitions. If a BusinessCloud user has no corresponding Epicor User, the record goes to a reconciliation queue for the customer's admin to provision.
| BusinessCloud | Epicor Prophet 21 | Compatibility | |
|---|---|---|---|
| Customer | Customer1:1 | Fully supported | |
| Vendor | Supplier1:1 | Fully supported | |
| Product | Part1:1 | Fully supported | |
| Inventory | PartPlant + WarehseBin1:1 | Mapping required | |
| Chart of Accounts | GL Account1:1 | Mapping required | |
| Purchase Order | POHeader + PODetail1:1 | Fully supported | |
| Sales Order | OrderHed + OrderDtl1:1 | Fully supported | |
| Work Order / Production Order | JobHead + JobMtl1:1 | Fully supported | |
| Bill of Materials | ECOMtl + ECOJob1:1 | Fully supported | |
| Custom Table (BusinessCloud UD) | UD Table (Epicor UD100, UD101, etc.)lossy | Fully supported | |
| Attachments and Documents | DocStar / Attachment (ERP standard)1:1 | Fully supported | |
| Financial Transactions (GL Journal) | GLJrnGrp + GLJrnDtl1:1 | Fully supported | |
| AP / AR Transactions | APTran + ARTran1:1 | Fully supported | |
| User / Owner | User1: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.
BusinessCloud gotchas
Name collision: 'BusinessCloud' refers to multiple unrelated products
No public API or bulk export documentation
Saudi banking and Muqeem Portal integrations do not map to non-MENA destinations
Per-user pricing model means user count drives migration cost
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
Data export negotiation and schema discovery
We submit a formal data export request to BusinessCloud support for a full database dump covering all tables, custom tables, UD fields, attachments, and transactional history within the agreed retention window. While waiting for the export, we profile BusinessCloud's known schema (the Dafater product uses a standard accounting data model) and cross-reference it against the database dump when received. We document every BusinessCloud table, column, data type, and foreign key relationship to build the migration schema map. This phase produces a written BusinessCloud Data Dictionary and a Schema Diff against Epicor's standard Kinetic data model.
Epicor schema provisioning and UD field design
We provision the Epicor Kinetic target schema in a Sandbox environment. This includes creating Part, Customer, Supplier, GL Account, Warehouse, and Site records matching the BusinessCloud entity codes; designing Epicor UD fields and UD tables for BusinessCloud custom table equivalents; configuring the Epicor COA structure matching BusinessCloud's account hierarchy; setting up Epicor fiscal years and periods; and configuring multi-company if the BusinessCloud deployment includes multiple GCC entities. The Epicor admin receives a provisioning checklist to complete before migration begins. We validate the provisioned schema with a test import of a 100-record sample before full migration.
Transformation layer and test migration to Sandbox
We build a data transformation layer that reads BusinessCloud export files, applies field mapping (BusinessCloud field to Epicor field), handles character encoding correction for Arabic and MENA regional data, resolves foreign key references (Customer ID to Epicor Customer.CustID, Vendor ID to Supplier.VendorID), and writes Epicor-compatible import files. We run a full test migration into the Epicor Sandbox, reconcile record counts per object, spot-check 30-50 records per object against the BusinessCloud source, and document any mapping corrections. The customer's Epicor admin reviews the Sandbox results and signs off before production migration begins.
Master data migration (Customers, Vendors, Parts, GL Accounts)
We migrate master data in dependency order: GL Accounts first (no dependencies), then Customers, then Vendors, then Parts. Epicor DMT loads Part, Customer, and Supplier records as CSV batches. BusinessCloud UD fields and custom tables load via direct Epicor REST API calls or SQL insert into Epicor UD staging tables because DMT does not reliably handle complex UD field structures. Each phase emits a reconciliation report (expected count vs. imported count) before the next phase begins. Any records that fail import are written to an exception log for manual resolution.
Transactional data migration (Orders, Jobs, GL Journals, AP/AR)
We migrate transactional records in dependency order: open Purchase Orders and Sales Orders, then closed/recent orders within the retention window, then Production Jobs (if applicable), then AP and AR transactions, then GL Journal entries. Each transactional record references the migrated master data records (Customer, Supplier, Part, GL Account) by their new Epicor IDs. We skip historical transactional records older than the agreed retention window unless the customer specifically requests them for audit or tax authority requirements. All transactional imports run in Epicor DMT batch mode or REST API batch mode with rollback capability if a batch fails.
Attachment migration and reconciliation handoff
We migrate BusinessCloud file attachments to Epicor's attachment structure, linking each file to the corresponding Epicor record (Customer, Supplier, Part, Order) by resolving the BusinessCloud entity reference to the new Epicor ID. We flag any BusinessCloud attachments where the parent record was not migrated (closed orders, discontinued parts) and deliver a written inventory of orphaned attachments for the customer's admin to handle manually. Post-migration, the customer's Epicor admin completes any remaining UD field mapping in the Epicor Kinetic UI, configures the Arabic language pack if required, and validates VAT/GST tax code assignments.
Cutover, validation, and automation rebuild inventory
We freeze BusinessCloud writes during the cutover window, run a final delta migration of any records created or modified since the last batch run, then hand over Epicor as the system of record. We deliver a written inventory of all BusinessCloud workflows, automations, and scheduled reports that require rebuild in Epicor Kinetic Business Rules, App Studio, and Kinetic REST API. We do not rebuild BusinessCloud automations as Epicor workflows inside the migration scope; that is a separate engagement or an internal Epicor admin task. We provide a one-week hypercare window for reconciliation issues raised during the first production use.
Platform deep dives
BusinessCloud
Source
Strengths
Weaknesses
Epicor Prophet 21
Destination
Strengths
Weaknesses
Complexity grading
Moderate ERP migration. 8 of 8 objects need a mapping; the rest are 1:1.
Overall complexity
Moderate migration
Derived from compatibility, mapping clarity, API constraints, and data volume across BusinessCloud and Epicor Prophet 21.
Object compatibility
8 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
BusinessCloud: Not publicly documented.
Data volume sensitivity
BusinessCloud 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 BusinessCloud to Epicor Prophet 21 migration scoping. Not seeing yours? Book a call.
Walk through your BusinessCloud 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 BusinessCloud
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.