ERP migration
Field-level mapping, validation, and rollback between Vault-ERP and Epicor Prophet 21. We move data and schema; workflows are rebuilt natively in Epicor Prophet 21.
Vault-ERP
Source
Epicor Prophet 21
Destination
Compatibility
13 of 14
objects map 1:1 between Vault-ERP and Epicor Prophet 21.
Complexity
BStandard
Timeline
3-5 weeks
Overview
Moving from Vault-ERP to Epicor ERP is a structural ERP migration that must respect the interdependency of financial, inventory, and HR data. Vault-ERP runs on a NetSuite-derived architecture with per-instance custom forms and fields, meaning no two deployments share an identical schema. Epicor Kinetic uses a purpose-built manufacturing data model with GL accounts, Part and PartTran records, UD (User-Defined) fields, and BAQ (Business Activity Query) reporting. We run a pre-migration schema discovery pass across the Vault-ERP instance to enumerate every custom field, then design the Epicor UD field configuration to absorb them. We load records in strict dependency order—accounts first, then customers and vendors, then items, then open AP/AR, then orders—to preserve foreign-key integrity. Historical transaction data above the agreed window is archived rather than migrated, consistent with Epicor migration best practices documented across the Epicor user community. Custom workflows, forms, and integrations in Vault-ERP do not migrate; we deliver a written inventory of every automation requiring rebuild in Epicor Kinetic using BPMs (Business Process Management) and Kinetic Framework.
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 Vault-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.
Vault-ERP
Chart of Accounts
Epicor Prophet 21
GL Account
1:1Vault-ERP stores the full account hierarchy via its NetSuite-derived API. Epicor Kinetic uses a GL Account table with Account Type (Asset, Liability, Equity, Revenue, Expense), Posting Account flags, and a Company Assignment. We extract the Vault-ERP account structure with account number, name, type, and parent reference, then map it to Epicor's GL Account with the same posting semantics. Intercompany account mappings require additional configuration in Epicor's Multi-Company Journal entry setup if the destination spans multiple Epicor companies.
Vault-ERP
Customer
Epicor Prophet 21
Customer
1:1Vault-ERP Customer records map to Epicor Kinetic Customer records with contact details, ship-to and bill-to addresses, credit limits, and payment terms preserved. The Vault-ERP customer class and region codes map to Epicor Customer Group and Territory fields. Any Vault-ERP custom classification fields require pre-migration UD field setup in Epicor before the Customer import batch begins.
Vault-ERP
Vendor
Epicor Prophet 21
Vendor
1:1Vault-ERP Vendor records map to Epicor Kinetic Vendor records with address, payment terms, and bank account details. Vendor holds are preserved as a Vendor.ApprovalStatus field configuration in Epicor. Vendor-specific lead times and freight terms migrate to the Epicor Vendor PPP (Purchasing Terms) record.
Vault-ERP
Item (Inventory)
Epicor Prophet 21
Part + PartBin
1:1Vault-ERP Item records map to Epicor Kinetic Part records with Part Number, Description, Type (Stock, Non-Stock, Service), UOM (Unit of Measure), and cost information. Vault-ERP item classes map to Epicor Part Class codes. Current on-hand quantities from Vault-ERP transfer to Epicor PartBin records by warehouse. Custom item fields in Vault-ERP require UD field setup on Epicor's Part table before this import batch runs.
Vault-ERP
Item (BOM)
Epicor Prophet 21
Part + PartMtl
1:manyVault-ERP BOM (Bill of Materials) structures with multi-level assemblies map to Epicor Kinetic PartMtl (material) and PartOpr (operation) records. Each Vault-ERP BOM header becomes a Part record of Type MfgKit or Assemble; each component becomes a PartMtl row with qty-per, scrap percent, and material type flags. We preserve the BOM revision and effective date in Epicor's PartRev and PartRevDtl tables. Manufacturing routing data from Vault-ERP maps to PartOpr records with work center and cycle time assignments.
Vault-ERP
Open AP
Epicor Prophet 21
APInvoice + APLnk
1:1Open payable records in Vault-ERP carry vendor reference, invoice number, invoice date, due date, outstanding balance, and currency. These map to Epicor Kinetic APInvoice records with invoice line distributions mapped to GL accounts from the Chart of Accounts migration. We preserve the original AP invoice number in Epicor's Invoice Reference field. Prepayments and partial payments migrate as separate APTran entries.
Vault-ERP
Open AR
Epicor Prophet 21
ARInvoice + ARLnk
1:1Open receivable records in Vault-ERP map to Epicor Kinetic ARInvoice with customer reference, invoice number, invoice date, due date, and outstanding balance. Vault-ERP payment terms map to Epicor AR Terms codes. Deposit records and credit memos migrate as separate ARTran entries with transaction type flags. Currency and subsidiary assignments are preserved from the source records.
Vault-ERP
Sales Order
Epicor Prophet 21
OrderHed + OrderDtl
1:1Vault-ERP Sales Orders map to Epicor Kinetic OrderHed (order header) and OrderDtl (order detail). The customer reference and ship-to address resolve via the Customer mapping; line items resolve via the Part mapping. Vault-ERP order status (open, partial, complete) maps to Epicor OrderHed.OrderStatus. Custom fields on Vault-ERP order headers migrate to UD fields on OrderHed after UD field setup in Epicor. We flag any Vault-ERP order that references a discontinued part and hold it for customer admin resolution.
Vault-ERP
Purchase Order
Epicor Prophet 21
POHeader + POLine
1:1Vault-ERP Purchase Orders map to Epicor Kinetic POHeader and POLine records. Vendor resolves via the Vendor mapping; line items resolve via the Part mapping. POStatus, buyer assignment, and FOB terms migrate. Purchase order approvals in Vault-ERP do not transfer; Epicor's PO approval workflow is configured separately post-migration.
Vault-ERP
Employee
Epicor Prophet 21
EmpBasic + EmpRouting
1:1Vault-ERP Employee records carry job title, department, hire date, and effective-dated compensation changes. These map to Epicor Kinetic EmpBasic (name, address, contact, department, job code) and pay rate data. We extract the full effective-dated change log from Vault-ERP and load it into Epicor as a sequence of dated HR records, preserving audit continuity. Custom employee fields migrate to UD fields on EmpBasic after pre-migration UD field configuration.
Vault-ERP
Time Tracking Entry
Epicor Prophet 21
LaborDtl
1:1Vault-ERP time entries with billable and non-billable hours, project associations, and employee links map to Epicor Kinetic LaborDtl records. We map the Vault-ERP project reference to an Epicor JobNum or ProjectID, and the hours, labor type, and work date transfer to LaborDtl with the appropriate LaborType and LaborHrs values. Vault-ERP's configurable time entry layout requires a pre-migration review to identify which fields map to Epicor's fixed LaborDtl schema.
Vault-ERP
Bank and Cash Account
Epicor Prophet 21
BankAcct
1:1Vault-ERP bank account definitions and current balance snapshots map to Epicor Kinetic BankAcct records with bank code, account number, currency, and opening balance. We transfer the balance as of the migration effective date as an opening balance. Epicor's bank reconciliation module is configured separately; historical cleared transactions are not migrated as part of the standard scope.
Vault-ERP
Tax Code
Epicor Prophet 21
TaxRegion + TaxConnect
1:1Vault-ERP tax codes with jurisdiction-specific rates and rules map to Epicor Kinetic TaxRegion and TaxConnect configuration. Each Vault-ERP tax code becomes an Epicor TaxRegion with associated TaxDetail rows for rate, tax type, and effective date. Tax exemptions and tax group assignments migrate to Epicor TaxExempt records linked to Customer and Vendor.
Vault-ERP
Document and Attachment
Epicor Prophet 21
DocumentReference
1:1Vault-ERP file attachments linked to customers, vendors, orders, and items export as document records with binary content and metadata. We transfer the file content, original filename, and linked record reference. Every migrated attachment is verified post-transfer by SHA-256 checksum comparison against the source file; any mismatch is flagged for manual resolution. Epicor Kinetic stores these in its Document Management system with reference links back to the parent record.
| Vault-ERP | Epicor Prophet 21 | Compatibility | |
|---|---|---|---|
| Chart of Accounts | GL Account1:1 | Mapping required | |
| Customer | Customer1:1 | Fully supported | |
| Vendor | Vendor1:1 | Fully supported | |
| Item (Inventory) | Part + PartBin1:1 | Fully supported | |
| Item (BOM) | Part + PartMtl1:many | Fully supported | |
| Open AP | APInvoice + APLnk1:1 | Fully supported | |
| Open AR | ARInvoice + ARLnk1:1 | Fully supported | |
| Sales Order | OrderHed + OrderDtl1:1 | Fully supported | |
| Purchase Order | POHeader + POLine1:1 | Fully supported | |
| Employee | EmpBasic + EmpRouting1:1 | Fully supported | |
| Time Tracking Entry | LaborDtl1:1 | Fully supported | |
| Bank and Cash Account | BankAcct1:1 | Fully supported | |
| Tax Code | TaxRegion + TaxConnect1:1 | Fully supported | |
| Document and Attachment | DocumentReference1: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.
Vault-ERP gotchas
Custom form and field variations across tenants
Referential integrity across ERP tables during migration
File storage integrity is not guaranteed across migrations
ERP transaction history is intermingled with current state
HR data carries effective-dated changes that must be preserved
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
Schema discovery and Epicor UD field pre-configuration
We audit the Vault-ERP instance to enumerate every standard and custom field across Customers, Vendors, Items, Orders, Employees, and any custom objects. We cross-reference each Vault-ERP custom field against Epicor Kinetic's available UD field slots on the corresponding tables. We then pre-configure Epicor Kinetic UD fields (via the UD Table maintenance in Epicor) as a prerequisite gate before any import batch. The discovery output is a written field map and a UD field configuration manifest that the customer's Epicor admin approves before migration begins.
Epicor environment configuration
We work with the customer's Epicor admin to configure the base Epicor Kinetic environment: GL Account structure with account types and posting assignments, Part Classes and Part number format, Customer Groups and Vendor Groups, TaxRegion and TaxConnect jurisdiction setup, warehouse and bin structure, and production calendar. Epicor Kinetic deployment option (on-premise, private cloud, or Epicor SaaS Kinetic) is confirmed before this step because some configurations differ by deployment type.
Data migration in dependency order
We run the migration in strict record-dependency order: GL accounts and Bank Accounts (no dependencies), Customers and Vendors (depend on accounts), Tax Codes (depend on GL accounts and regions), Parts and BOM structures (depend on Part Classes), Open AP and AR (depend on Vendors, Customers, and GL accounts), Sales Orders and Purchase Orders (depend on Customers, Vendors, and Parts), Employees and HR records with effective-dated history (depend on department and job code setup), Time Tracking entries (depend on Employees and any project or job references), and Documents and Attachments last. Each phase emits a row-count reconciliation report; the next phase does not begin until the previous phase's reconciliation clears or exceptions are documented.
BOM and manufacturing routing validation
For Vault-ERP deployments that use BOM structures for assembly or manufacturing, we validate the multi-level BOM explosion before Epicor PartMtl import. We verify that every component Part exists or is created before its parent assembly, that quantity-per and scrap factors are numeric and within tolerance, and that any work center references in Vault-ERP's routing data map to valid Epicor Resource Groups. BOM validation errors are held in a reconciliation queue for the customer's engineering or operations team to resolve before the Epicor production environment is populated.
File attachment transfer and checksum verification
We export all Vault-ERP file attachments with their source SHA-256 checksums, transfer them to Epicor Kinetic Document Management storage with original filenames and MIME types, and verify by checksum comparison. Every file that fails verification is logged with the original filename, the linked Vault-ERP record (customer, vendor, order, part), and the checksum mismatch reason. Files that pass verification are linked to their parent records via DocumentReference entries. We do not migrate Vault-ERP's internal file store server configuration; we transfer file content only.
Cutover, validation, and automation inventory handoff
We freeze Vault-ERP writes during cutover, run a final delta migration of any records modified during the migration window, then mark Epicor as the system of record. We deliver a reconciliation report comparing Vault-ERP and Epicor totals for accounts, customers, vendors, items, open AP/AR, and employee headcount. We also deliver a written inventory of every Vault-ERP workflow, custom form logic, and integration that requires rebuild in Epicor Kinetic using BPMs, Epicor Functions, or Kinetic Framework. We support a one-week hypercare window for reconciliation issues. We do not rebuild Vault-ERP automations as Epicor BPMs inside the migration scope; that is a separate engagement.
Platform deep dives
Vault-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 Vault-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
Vault-ERP: Not publicly documented.
Data volume sensitivity
Vault-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 Vault-ERP to Epicor Prophet 21 migration scoping. Not seeing yours? Book a call.
Walk through your Vault-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 Vault-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.