ERP migration

Migrate from Epicor iScala to Epicor Prophet 21

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 logo

Epicor iScala

Source

Epicor Prophet 21

Destination

Epicor Prophet 21 logo

Compatibility

93%

14 of 15

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

Complexity

BStandard

Timeline

6-10 weeks

Rollback included Accuracy guarantee Field-level validation

Overview

What this migration involves

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.

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

Epicor iScala logo

Epicor iScala

What's pushing teams away

  • Built-in reports are described as difficult to use and the interface is not considered user-friendly, creating frustration with day-to-day reporting tasks.
  • The application does not support opening multiple windows simultaneously, forcing users to close one screen before accessing another — a workflow bottleneck for order processing teams.
  • Steep learning curve and limited documentation make implementation and ongoing administration challenging for under-resourced IT teams.
  • Outdated UI compared to modern cloud ERPs creates a usability gap that frustrates younger users and increases training costs.
  • Performance issues after migration to newer Epicor Kinetic environments have been reported when server resources are undersized, causing slower reporting and task execution.

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 Epicor iScala objects map to Epicor Prophet 21

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)

maps to

Epicor Prophet 21

Erp.GLAccount + Erp.GLAccountAlloc + Erp.GLBook

1:1
Mapping required

iScala 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)

maps to

Epicor Prophet 21

Erp.Customer + Erp.InvcHead + Erp.InvcDtl

1:1
Mapping required

iScala 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)

maps to

Epicor Prophet 21

Erp.Vendor + Erp.APInvHead + Erp.APInvDtl

1:1
Mapping required

iScala 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)

maps to

Epicor Prophet 21

Erp.OrderHed + Erp.OrderDtl + Erp.OrderRel

1:1
Mapping required

iScala 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)

maps to

Epicor Prophet 21

Erp.POHeader + Erp.POLine + Erp.PORel

1:1
Mapping required

iScala 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)

maps to

Epicor Prophet 21

Erp.Part + Erp.PartBin + Erp.PartLot + Erp.SNTran

1:1
Mapping required

iScala 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)

maps to

Epicor Prophet 21

Erp.JobHead + Erp.JobMtl + Erp.JobOper + Erp LaborDtl

1:1
Fully supported

iScala 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)

maps to

Epicor Prophet 21

Erp.EmpBasic + Erp.EmpPaycheq + Erp.EmpExpense

1:1
Mapping required

iScala 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)

maps to

Epicor Prophet 21

Erp.FinancialCont + Erp.DepreciationDetail

1:1
Mapping required

iScala 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)

maps to

Epicor Prophet 21

Erp.Project + Erp.PJTask + Erp.PJBldCode + Erp.PJExpense

1:1
Mapping required

iScala 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)

maps to

Epicor Prophet 21

Erp.UD{TableName} + Erp.UDColumnMap

lossy
Mapping required

The 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

maps to

Epicor Prophet 21

Erp.Company + Erp.Plant + Erp.Warehouse

1:1
Mapping required

iScala 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)

maps to

Epicor Prophet 21

Erp.ServiceOrderHed + Erp.ServiceOrderDtl

1:1
Mapping required

iScala 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)

maps to

Epicor Prophet 21

Erp.ServiceContractHed + Erp.ContractLine

1:1
Mapping required

iScala 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

maps to

Epicor Prophet 21

Not migrated

1:1
Not supported

Document 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.

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.

Epicor iScala logo

Epicor iScala gotchas

High

Web Services license exhaustion degrades API performance

High

Multi-company schema requires per-company scoping

Medium

User-Defined (UD) field schema varies by iScala version

Medium

Linux container migration can break file share and report paths

Low

Stock lot and serial records require linked migration

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

  • iScala module-prefixed schema requires remapping to Epicor ERP BO tables

    iScala stores data in a flat module-prefixed schema (GLxxx, SCxxx, ORxxx) with company codes embedded in row data. Epicor ERP uses a normalized Business Object table structure with Erp.TableName conventions and a formal Company entity. A direct table-to-table copy will merge data across legal entities and use wrong primary key sequences. We resolve this by querying iScala company codes upfront, building per-company extraction filters into every table pull, and mapping the extracted rows to Epicor ERP BO tables with Epicor Data Fabric keys regenerated at insert time.

  • UD field schema varies between iScala versions

    iScala's User-Defined module allows custom fields on standard objects, but the UD field definition schema changes between versions (2.2 through 2022.1). Epicor ERP's UD table structure also has version-specific UDColumnMap behavior. We inventory UD fields during discovery against the target Epicor ERP version's UD table structure. Any fields with no matching destination property are flagged for manual mapping review before migration. Custom VBA-driven UD logic does not migrate and requires a rewrite in Epicor ERP's modern development framework.

  • Lot and serial stock history requires sequenced migration

    iScala lot and serial numbers in the SC module are linked to stock transactions (receipts, issues, adjustments). Migrating only current balances without transaction history breaks traceability in Epicor ERP's PartLot and SNTran tables, which require linked PartTran records for full lot genealogy. We sequence stock migration to include receipt transaction history so that lot links, expiration dates, and serial number assignments remain intact in the destination PartLot and SNTran tables.

  • File share and SSRS report paths can break on Kinetic migration

    Epicor ERP's migration to Linux containers on Kinetic has re-pointed file share paths (ServerFolder.FileShare) and broken SSRS report server configurations in some customer environments. iScala deployments with file-share-based attachments or embedded Crystal Reports references may lose silent document access or report rendering after cutover. We validate file path references and SSRS report server connections during the pre-migration audit and update them post-migration to the Epicor ERP document storage or Kinetic container paths.

  • Web Services license pool exhaustion can corrupt record sequencing

    Epicor iScala uses a Web Services license pool for API access. When the pool is exhausted, response times degrade progressively. If we do not monitor for this pattern during migration, license exhaustion causes request delays that corrupt the sequencing of dependent record inserts (child records arriving before parents). We pause ingestion when response times exceed a threshold and resume only after pool recovery. This prevents cascading record sequencing errors across dependent objects like OrderDtl referencing an unloaded OrderHed.

Migration approach

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

  1. 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).

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. 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

Context on both ends of the pair

Epicor iScala logo

Epicor iScala

Source

Strengths

  • Integrated multi-company, multi-currency General Ledger supporting real-time financial closing across subsidiaries.
  • Comprehensive manufacturing module (MP) with work orders, routings, and material production control.
  • Lot and serial number tracking in stock control (SC) for regulated industries like pharma and food.
  • Service order management (SM) with field-service scheduling for companies with on-site service operations.
  • Embedded reporting with iScala Query Designer and Crystal Reports for financial and operational analytics.

Weaknesses

  • UI is considered outdated compared to modern cloud ERPs, with no multi-window support limiting concurrent workflow.
  • Built-in reporting is difficult to use, driving users to external BI tools for ad-hoc analysis.
  • Limited public API documentation for iScala makes programmatic data extraction complex.
  • Web Services licensing model can cause degraded API response times when license pools are exhausted.
  • Steep implementation and training requirements for under-resourced IT and business user teams.
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. 2 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 Epicor iScala and Epicor Prophet 21.

  • Object compatibility

    B

    2 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

    Epicor iScala: Not publicly documented for iScala; Web Services license pool governs concurrent API sessions rather than a per-minute rate.

  • Data volume sensitivity

    B

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

Estimator

Estimate your Epicor iScala 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 Epicor iScala to Epicor Prophet 21 data migrations

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

Can't find your answer?

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 consultation

Migrations land between six and ten weeks for organizations under 50,000 parts, 20,000 open orders, and a single iScala company. Multi-company migrations with multiple iScala company codes, active Material Production work orders with routing sequences, large stock lot histories, or HR/Payroll modules move to fourteen to twenty-two weeks because of per-company extraction scoping, BOM and routing field mapping, and the Epicor ERP UD table schema validation work required during discovery.

Adjacent paths

Related migrations to explore

Ready when you are

Move from Epicor iScala.
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