ERP migration
Field-level mapping, validation, and rollback between Epicor iScala and Epicor Prophet 21. We move data and schema; workflows are rebuilt natively in Epicor Prophet 21.
Epicor iScala
Source
Epicor Prophet 21
Destination
Compatibility
14 of 15
objects map 1:1 between Epicor iScala and Epicor Prophet 21.
Complexity
BStandard
Timeline
6-10 weeks
Overview
Moving from Epicor iScala to Epicor ERP is an intra-vendor migration within the Epicor ecosystem, which reduces vendor risk but introduces significant schema complexity. iScala stores data across a two-letter module prefix system (GL, SC, OR, PC, SL, PL, AM, PR, MP, HR, PA) inside a single SQL Server database with company-dependent and company-independent schemas. Epicor ERP uses a normalized Business Object (BO) table structure with Erp.Prefix naming conventions and supports cloud-native deployment via Epicor Kinetic on Linux containers. We resolve the module-to-BO mapping during discovery, scope each iScala company code as a separate Epicor ERP company entity, and map iScala User-Defined (UD) fields to Epicor ERP UD tables with version-aware schema validation. We do not migrate VBA macros, custom report definitions, or iScala's built-in workflow triggers; we deliver a written inventory of these for the customer's Epicor partner to rebuild in the Epicor ERP environment.
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 Epicor iScala 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.
Epicor iScala
General Ledger (GL)
Epicor Prophet 21
Erp.GLAccount + Erp.GLAccountAlloc + Erp.GLBook
1:1iScala GL stores journal entries, chart of accounts, and financial periods under company codes within a single database. Epicor ERP separates GLAccount, GLBook, and JournalEntry tables with a formal Company entity. We map iScala's two-letter company codes to Epicor ERP Company entities, preserve multi-segment account structures (iScala supports multi-dimension accounts), and migrate GL balances and open periods with fiscal year alignment validated against Epicor ERP's fiscal calendar configuration.
Epicor iScala
Sales Ledger (SL)
Epicor Prophet 21
Erp.Customer + Erp.InvcHead + Erp.InvcDtl
1:1iScala SL holds customer masters, open AR invoices, and payment history. Epicor ERP uses Customer as the master, InvcHead/InvcDtl for posted invoices, and CashHead for payments. We extract customer masters and outstanding AR with address and contact normalization, then map invoice headers and lines to their Epicor ERP equivalents. Multi-currency AR balances preserve exchange rates from iScala's currency tables.
Epicor iScala
Purchase Ledger (PL)
Epicor Prophet 21
Erp.Vendor + Erp.APInvHead + Erp.APInvDtl
1:1iScala PL manages vendor records, open AP, and purchase invoices. Epicor ERP uses Vendor for the master, APInvHead/APInvDtl for posted invoices, and APTran for transactions. GRNI (goods-received-not-invoiced) entries from iScala's PC module map to Epicor ERP's APPreuvian records for three-way matching integrity. Multi-currency AP preserves vendor-specific exchange rates.
Epicor iScala
Sales Orders (OR)
Epicor Prophet 21
Erp.OrderHed + Erp.OrderDtl + Erp.OrderRel
1:1iScala OR contains order headers and lines with pricing, discounts, and fulfillment status across the two-letter OR prefix. Epicor ERP separates OrderHed, OrderDtl, and OrderRel with release-level scheduling. We migrate open and recent closed orders preserving line-level pricing, discount codes, and warehouse assignments. Attachment references from iScala are flagged as file-location items for the customer's admin to re-link post-migration.
Epicor iScala
Purchase Orders (PC)
Epicor Prophet 21
Erp.POHeader + Erp.POLine + Erp.PORel
1:1iScala PC manages PO headers, lines, and receipts with GRNI tracking for three-way match. Epicor ERP uses POHeader, POLine, and PORel with PORel representing scheduled releases. We extract open PO records and map receipt history to PORel, preserving the AP match integrity needed for three-way matching in Epicor ERP's Accounts Payable module.
Epicor iScala
Stock Control (SC)
Epicor Prophet 21
Erp.Part + Erp.PartBin + Erp.PartLot + Erp.SNTran
1:1iScala SC covers inventory items, warehouse locations, lot numbers, and serial numbers. Epicor ERP uses Part for item masters, PartBin for warehouse-level quantities, PartLot for lot tracking, and SNTran for serial number movements. We migrate current stock balances first, then receipt transaction history so that lot and serial links remain intact in Epicor ERP. BOM structures from iScala MP map to Erp.JobMtl references for manufactured items.
Epicor iScala
Material Production (MP)
Epicor Prophet 21
Erp.JobHead + Erp.JobMtl + Erp.JobOper + Erp LaborDtl
1:1iScala MP handles work orders, routings, and production schedules. Epicor ERP uses JobHead for work order master, JobMtl for material requirements, JobOper for routing operations, and LaborDtl for labor transactions. We map iScala routing sequences and labor standards to Epicor ERP JobOper with operation-level timestamps and labor codes preserved. Active jobs are prioritized in migration order; completed historical jobs migrate as closed records with job close dates validated.
Epicor iScala
HR / Payroll (HR, PA)
Epicor Prophet 21
Erp.EmpBasic + Erp.EmpPaycheq + Erp.EmpExpense
1:1iScala HR and PA modules store employee records, compensation history, and payroll runs. Epicor ERP uses EmpBasic for employee master, EmpPaycheq for payroll history, and EmpExpense for expense claims. Effective-dated records migrate as-is with start and termination dates preserved. Tax configuration and payroll processing rules are not migrated; we document them in the payroll handoff inventory for the customer's Epicor partner or HRIS team to configure in Epicor ERP Payroll or a linked payroll system.
Epicor iScala
Asset Management (AM)
Epicor Prophet 21
Erp.FinancialCont + Erp.DepreciationDetail
1:1iScala AM tracks fixed assets, depreciation schedules, and asset locations. Epicor ERP uses FinancialCont for asset master, DepreciationDetail for depreciation history, and AssetLocMap for location assignments. We migrate asset masters with opening book value, accumulated depreciation, and depreciation method (straight-line, declining balance) preserved. Asset associations to departments or cost centers map to Epicor ERP's department and cost center entities.
Epicor iScala
Project Management (PR)
Epicor Prophet 21
Erp.Project + Erp.PJTask + Erp.PJBldCode + Erp.PJExpense
1:1iScala PR stores project masters, WBS elements, budgets, and time entries. Epicor ERP uses Project as the master, PJTask for WBS breakdown, PJBldCode for billing codes, and PJExpense for expense records. We migrate project headers and current budget balances as PJObjCoe records. Detailed time entries and labor bookings map to Erp.LaborDtl with Project and Task references resolved. Large time entry histories may require chunked migration with date-range filters.
Epicor iScala
User-Defined Fields (UD)
Epicor Prophet 21
Erp.UD{TableName} + Erp.UDColumnMap
lossyThe iScala UD module stores custom fields on standard objects using a version-varying schema across iScala 2.2 through 2022.1. Epicor ERP uses UD tables with the UDColumnMap configuration for each Business Object. We inventory UD field definitions during discovery against the target Epicor ERP version's UD table structure, then map values to the corresponding Epicor ERP UD columns. Fields with no matching destination property are flagged for manual mapping review before migration.
Epicor iScala
Multi-Company / Multi-Site
Epicor Prophet 21
Erp.Company + Erp.Plant + Erp.Warehouse
1:1iScala supports multiple companies within a single database using company codes embedded in table data. Epicor ERP uses a formal Company entity with Plant and Warehouse as sub-entities. We scope each iScala company code as a separate Epicor ERP Company during migration, map site-specific configurations to Plant records, and resolve inter-company transaction references to Epicor ERP's inter-company GL entries. This per-company scoping prevents cross-company record merging during extraction.
Epicor iScala
Service Order Management (SM)
Epicor Prophet 21
Erp.ServiceOrderHed + Erp.ServiceOrderDtl
1:1iScala SM handles service order headers, line items, and field-service scheduling with contract management. Epicor ERP uses ServiceOrderHed and ServiceOrderDtl with technician assignment and SLA tracking. We migrate open service orders with scheduling windows and SLA flags mapped to Epicor ERP's service management configuration. Contract terms from iScala CM module map to Erp.ServiceContractHed with billing cycles preserved.
Epicor iScala
Contract Management (CM)
Epicor Prophet 21
Erp.ServiceContractHed + Erp.ContractLine
1:1iScala CM stores contract masters, terms, and billing schedules for service or recurring revenue contracts. Epicor ERP uses ServiceContractHed for the contract master and ContractLine for line items. We map active contracts with billing cycles and associated customer or vendor records. Contract pricing and discount terms migrate as-is; billing rules and revenue recognition schedules require manual configuration in Epicor ERP's contract management module.
Epicor iScala
Attachments and Documents
Epicor Prophet 21
Not migrated
1:1Document attachments stored outside the iScala SQL database in file shares, SharePoint, or Epicor's document management are not migrated via API. We inventory file path references during discovery and deliver a written document map with current file locations and recommended target paths in Epicor ERP's document management or Kinetic content storage. The customer's admin re-links documents post-migration using the delivered inventory.
| Epicor iScala | Epicor Prophet 21 | Compatibility | |
|---|---|---|---|
| General Ledger (GL) | Erp.GLAccount + Erp.GLAccountAlloc + Erp.GLBook1:1 | Mapping required | |
| Sales Ledger (SL) | Erp.Customer + Erp.InvcHead + Erp.InvcDtl1:1 | Mapping required | |
| Purchase Ledger (PL) | Erp.Vendor + Erp.APInvHead + Erp.APInvDtl1:1 | Mapping required | |
| Sales Orders (OR) | Erp.OrderHed + Erp.OrderDtl + Erp.OrderRel1:1 | Mapping required | |
| Purchase Orders (PC) | Erp.POHeader + Erp.POLine + Erp.PORel1:1 | Mapping required | |
| Stock Control (SC) | Erp.Part + Erp.PartBin + Erp.PartLot + Erp.SNTran1:1 | Mapping required | |
| Material Production (MP) | Erp.JobHead + Erp.JobMtl + Erp.JobOper + Erp LaborDtl1:1 | Fully supported | |
| HR / Payroll (HR, PA) | Erp.EmpBasic + Erp.EmpPaycheq + Erp.EmpExpense1:1 | Mapping required | |
| Asset Management (AM) | Erp.FinancialCont + Erp.DepreciationDetail1:1 | Mapping required | |
| Project Management (PR) | Erp.Project + Erp.PJTask + Erp.PJBldCode + Erp.PJExpense1:1 | Mapping required | |
| User-Defined Fields (UD) | Erp.UD{TableName} + Erp.UDColumnMaplossy | Mapping required | |
| Multi-Company / Multi-Site | Erp.Company + Erp.Plant + Erp.Warehouse1:1 | Mapping required | |
| Service Order Management (SM) | Erp.ServiceOrderHed + Erp.ServiceOrderDtl1:1 | Mapping required | |
| Contract Management (CM) | Erp.ServiceContractHed + Erp.ContractLine1:1 | Mapping required | |
| Attachments and Documents | Not migrated1:1 | Not 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.
Epicor iScala gotchas
Web Services license exhaustion degrades API performance
Multi-company schema requires per-company scoping
User-Defined (UD) field schema varies by iScala version
Linux container migration can break file share and report paths
Stock lot and serial records require linked migration
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 company code inventory
We audit the source iScala database across all deployed modules (GL, SC, OR, PC, SL, PL, AM, PR, MP, HR, SM, CM, UD), inventorying company codes, installed iScala version, UD field definitions, VBA customizations, and Crystal Report distribution. We extract record counts per module per company code to scope the per-company extraction filters and produce a written migration inventory that identifies which objects are in scope, which are manual-map candidates, and which are excluded from migration (attachments, VBA macros, workflow triggers).
Epicor ERP company and plant setup
We coordinate with the customer's Epicor partner to provision Epicor ERP companies corresponding to each iScala company code. This includes setting up the Epicor ERP fiscal calendar to match iScala's open periods, configuring the chart of accounts segment structure (Epicor ERP's multi-segment GLAccount vs iScala's flat account codes), and enabling the relevant Epicor ERP modules (Financials, Distribution, Manufacturing, HR, Service) on the target environment. The customer provisions Epicor ERP users and assigns security roles before we begin schema validation.
UD field schema mapping and sandbox validation
We map iScala UD field definitions to Epicor ERP UD tables and UDColumnMap configurations. UD fields with no Epicor ERP equivalent are flagged in the migration inventory for the customer's admin to review. We run a sandbox migration using the identified Epicor ERP version to validate UD field mapping, company-scoped record counts, and fiscal period alignment before production migration begins. Any schema corrections happen in sandbox, not in production.
Master data migration in dependency order
We run master data migration in Epicor ERP dependency order: Chart of Accounts and GL Account segments first, then Company configuration, then Part master (Stock Control), Customer master (Sales Ledger), Vendor master (Purchase Ledger), Bill of Materials and Routings (MP), then transactional records. Each phase emits a row-count reconciliation report before the next phase begins. For multi-company migrations, we run each company as a parallel migration thread with inter-company transaction references resolved at the end of the master data phase.
Transactional data migration
We migrate open and recent closed transactional records: open Sales Orders, Purchase Orders, and Service Orders; stock receipts with lot and serial history; open work orders with material and operation allocations; HR employee records with effective dates; and project WBS with current budget balances. Epicor ERP BAQ queries validate migrated record totals against iScala source totals per company code. Historical closed records (completed orders, closed jobs, historical GL periods) are migrated as-is with close dates preserved and locked against further posting.
Cutover, delta migration, and document handoff
We freeze iScala writes during the cutover window, run a final delta migration of any records modified during the migration period, then enable Epicor ERP as the system of record. We deliver the attachment inventory with file location references, the UD field mapping report with any unmapped fields requiring manual entry, the VBA macro and Crystal Report inventory for the customer's Epicor partner to rebuild, and the workflow trigger inventory documenting any iScala workflow logic requiring rebuild in Epicor ERP's modern automation tools. We support a one-week post-cutover reconciliation window for record count validation.
Platform deep dives
Epicor iScala
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 Epicor iScala 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
Epicor iScala: Not publicly documented for iScala; Web Services license pool governs concurrent API sessions rather than a per-minute rate.
Data volume sensitivity
Epicor iScala 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 Epicor iScala to Epicor Prophet 21 migration scoping. Not seeing yours? Book a call.
Walk through your Epicor iScala 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 Epicor iScala
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.