ERP migration

Migrate from IS Packaging to Epicor Prophet 21

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

IS Packaging logo

IS Packaging

Source

Epicor Prophet 21

Destination

Epicor Prophet 21 logo

Compatibility

83%

10 of 12

objects map 1:1 between IS Packaging and Epicor Prophet 21.

Complexity

BStandard

Timeline

6-10 weeks

Rollback included Accuracy guarantee Field-level validation

Overview

What this migration involves

Moving from IS Packaging to Epicor ERP is a production-data migration that requires careful BOM revision alignment, multi-plant lot normalization, and open-order status mapping. IS Packaging organizes data around Items, Locations, Production Orders, and revision-controlled BOMs; Epicor ERP uses Part, PartRev, Job, and Site as its primary entities with a structurally similar but distinct object hierarchy. We extract BOMs from IS Packaging with their revision and routing data, build a cross-reference table that maps IS Packaging revision codes to Epicor PartRev records, and apply that mapping at import so that material assignments on open Production Orders resolve correctly. Multi-plant implementations require lot-number normalization because IS Packaging plants frequently use different lot conventions within the same instance. We consolidate these into a unified Epicor lot format and re-associate lot transactions to prevent orphaned traceability. We do not migrate IS Packaging customizations, Vantage-era configurations, or on-premises database-level modifications; these require an Epicor partner to rebuild in the new 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

IS Packaging logo

IS Packaging

What's pushing teams away

  • As an SAP S/4HANA-based solution, IS Packaging inherits the cost profile and implementation complexity of S/4HANA — smaller converters often migrate to lighter-weight packaging ERPs (Aptean Flex Pack, ePS, SYSPRO) when the SAP TCO outpaces their growth.
  • Pricing is not published — total cost of ownership is sales-led and depends heavily on SAP licensing, infrastructure, and Aicomp implementation scope, which makes budget planning slow versus competitors with published per-user tiers.
  • Cloud-native deployment is limited compared to pure-SaaS packaging ERPs; customers wanting elastic infrastructure and quick provisioning may prefer Advantive or DELMIAworks for similar industry fit.
  • Customisation depth on the SAP layer can become a maintenance liability — converters that over-customise the configurator find S/4HANA upgrades require regression testing of all packaging-specific extensions.
  • Public technical documentation (API references, integration recipes, developer portals) is thin compared to mid-market ERPs, leaving partners and customer IT teams reliant on Aicomp consulting for integration design.

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

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

IS Packaging

Item

maps to

Epicor Prophet 21

Part and PartPlant

1:1
Fully supported

IS Packaging Items map to Epicor Part as the primary product master, with PartPlant records created per site for plant-level data like safety stock, reorder point, and costing layers. The IS Packaging Item Number becomes Part.PartNum, Description becomes Part.Description, and the uom class maps to Part.IUM and Part.PUM. Costing layers (standard, average, last) migrate to the corresponding Epicor costing method on Part. We extract all standard and custom Item properties during discovery and map them to Part UD fields or related Part tables.

IS Packaging

Bill of Materials (BOM)

maps to

Epicor Prophet 21

PartRev and PartMtl

1:1
Fully supported

IS Packaging BOMs with revision codes map to Epicor PartRev (revision header) and PartMtl (component lines). We build a revision cross-reference table during discovery that maps each IS Packaging revision code and effective date to the Epicor PartRev.RevisionNum, PartRev.EffectiveDate, and PartRev.ApprovedDate. Phantom assembly flags, scrap percentages, and operation-specific material issues from IS Packaging routing steps map to PartMtl and JobOper records in Epicor. This mapping is the most critical artifact of the migration because incorrect BOM revision mapping causes wrong material assignments on open Production Orders.

IS Packaging

Production Order

maps to

Epicor Prophet 21

JobHead, JobMtl, JobOper

1:1
Fully supported

IS Packaging Production Orders map to Epicor Job records. JobHead holds the order header (quantity, start date, due date, site), JobMtl holds material lines with the PartMtl.MtlSeq referencing the PartRev BOM components, and JobOper holds operation steps. We map IS Packaging order status to Epicor JobHead.JobReleased, JobHead.JobComplete, or JobHead.JobClose using a status matrix built during discovery. Any open IS Packaging orders that cannot resolve to a valid Epicor PartRev revision are held in a reconciliation queue for manual resolution before import.

IS Packaging

Work Order

maps to

Epicor Prophet 21

JobOper

lossy
Fully supported

IS Packaging Work Orders linked to Production Orders map to Epicor JobOper records. JobOper.OpCode, LaborHrs, MachineHrs, and WorkCenterId come from the IS Packaging work center and labor posting data. Status flags vary between IS Packaging plants, so we apply the destination-status mapping matrix during import. Work Orders without a parent Production Order are imported as standalone JobOper records with an informational flag for the customer's review.

IS Packaging

Finished Goods Location

maps to

Epicor Prophet 21

PartBin

1:1
Fully supported

IS Packaging Finished Goods Locations tied to Items map to Epicor PartBin records. On-hand quantity, lot number, and serial number from the source location transfer to PartBin.LotNum, PartBin.BinOnHandQty, and PartBin.SerialNo. We resolve the IS Packaging Location ID to an Epicor Warehouse and Bin combination during import using a location cross-reference table built during discovery.

IS Packaging

Inventory Transaction

maps to

Epicor Prophet 21

PartTran

1:1
Fully supported

IS Packaging transaction history (receipts, issues, adjustments, WIP moves) maps to Epicor PartTran records. We preserve transaction type, date, quantity, cost, warehouse, lot, and reference fields. High-volume transaction sets require chunked extraction and chronological sequencing to maintain integrity. Historical PartTran records older than 24 months may be flagged for archive rather than live migration to protect Epicor performance post-go-live.

IS Packaging

Customer Order

maps to

Epicor Prophet 21

OrderHed and OrderDtl

1:1
Fully supported

IS Packaging Customer Orders map to Epicor OrderHed (order header) and OrderDtl (order lines). OrderDtl maps to the target Part number and links to the corresponding Epicor PartRev for configured items. Pricing exceptions from IS Packaging custom pricing rules are flagged as OrderDtl.DiscountPercent overrides and flagged for manual pricing review before import.

IS Packaging

Vendor Record

maps to

Epicor Prophet 21

Vendor and VendorPP

1:1
Fully supported

IS Packaging Vendor masters map to Epicor Vendor and VendorPP (purchase point) records. Vendor Name, address, terms, and item-supplier cross-references migrate to Vendor and VendorPP with the supplier PartNum preserved on VendorPP.SupplierPartNum. We reassociate any IS Packaging Item-to-Vendor links as VendorPP records for the purchasing module.

IS Packaging

Custom Fields

maps to

Epicor Prophet 21

Part UD fields and UD tables

1:1
Mapping required

IS Packaging custom fields on standard objects require field-level mapping to Epicor UD columns or Part UD tables. We inventory all custom field names, data types, and values during discovery and pre-create the corresponding Epicor Part UD columns (PartUD01 through PartUD10 and related tables) before import. Custom fields that have no Epicor equivalent are flagged for the customer's admin to review for manual re-entry or alternative placement.

IS Packaging

Chart of Accounts

maps to

Epicor Prophet 21

GLAccount

1:1
Mapping required

The IS Packaging Chart of Accounts maps to Epicor GLAccount with segment alignment. We build an account cross-reference table during discovery, mapping IS Packaging account codes to Epicor segment values and COA codes. Any inactive, intercompany, or suspense accounts are flagged for reactivation review in Epicor before import. Multi-entity IS Packaging implementations may require separate COA mapping per legal entity in Epicor.

IS Packaging

Lot and Serial Number

maps to

Epicor Prophet 21

PartLot

lossy
Fully supported

IS Packaging lot numbers across multiple plants use different conventions that we normalize into a unified Epicor PartLot.LotNum format. We build a lot-normalization rule during discovery that maps source lot prefixes, date codes, and sequence formats to the target Epicor convention. PartLot records are created before inventory transactions import, ensuring that PartBin and PartTran records reference valid lots.

IS Packaging

Site or Plant

maps to

Epicor Prophet 21

Site

1:1
Fully supported

IS Packaging plants map to Epicor Sites. We create Site records for each source plant, map plant-specific parameters (site code, description, address, calendar) to Epicor Site fields, and associate PartPlant records to the corresponding Site during Part import. Multi-plant consolidation scenarios require site code standardization to prevent duplicate sites in Epicor.

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.

IS Packaging logo

IS Packaging gotchas

High

BOM revision control must be matched to destination version exactly

Medium

Open production orders must be status-mapped or manually closed first

Medium

Lot and serial number formats differ between plants in the same instance

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

  • BOM revision cross-reference must be built before any Production Order import

    IS Packaging tracks BOM revisions with effective dates and either date-based or sequential revision codes. Epicor PartRev uses RevisionNum, EffectiveDate, and ApprovedDate as its revision identity. These two schemes do not align automatically. We build a revision cross-reference table during discovery that maps each IS Packaging BOM revision to its Epicor PartRev equivalent, then apply that mapping when JobMtl records are imported. Without this table, open Production Orders reference Epicor BOMs with incorrect revision levels, causing material shortages or wrong component substitutions on the shop floor. This mapping is the single most consequential artifact of the migration.

  • Lot number normalization is required for multi-plant consolidations

    IS Packaging plants within the same instance frequently use different lot-numbering conventions: one plant may use date-coded lots (YYYYMMDD-SEQ), another uses supplier-prefixed lots (SUPPLIER-LOT), and a third uses sequential numbers. When consolidating to a single Epicor Site or across multiple Sites, these formats collide in PartLot and PartTran. We build a lot-normalization rule during discovery that maps each plant's source lot format to a unified Epicor PartLot.LotNum pattern, re-associates any orphaned lot transactions, and creates PartLot records before PartBin inventory import. Skipping this step creates duplicate PartLot records and traceability gaps that are difficult to resolve after go-live.

  • Open Production Order status mapping prevents invalid Job states in Epicor

    IS Packaging Production Orders carry a status lifecycle (entered, released, in-progress, complete, closed) that does not map one-to-one to Epicor JobHead.JobReleased, JobHead.JobComplete, and JobHead.JobClose states. Orders imported without status mapping may default to closed or get stuck in an invalid state that blocks material and labor posting. We either quiesce open orders in IS Packaging before migration or build a status mapping matrix during discovery that routes each IS Packaging status value to the correct Epicor Job state. Orders that reference BOM revisions not yet created in Epicor are held until the BOM import phase completes.

  • IS Packaging customizations and VAR modifications do not migrate

    IS Packaging implementations vary significantly between customers due to VAR-dependent customizations, database-level modifications, and 4GL code changes. These customizations are not part of the standard data model and have no equivalent in Epicor ERP without manual rebuild. We do not migrate customizations, custom database objects, or non-standard forms. We inventory any custom tables and fields encountered during discovery and provide a written report describing each custom object's structure, usage, and recommended Epicor equivalent for the customer's Epicor partner to rebuild.

  • Epicor deployment variant determines import path and data model

    Epicor ERP is sold under multiple deployment variants (Epicor Kinetic cloud, Epicor Prophet 21 for distribution, Epicor 10 on-premises). The import target must be identified before migration because data models differ slightly between variants. We confirm the destination variant during scoping, validate the target Epicor REST and bulk API endpoints, and adjust the Part, PartRev, Job, and Site schema mapping accordingly. Cloud deployments use Epicor Kinetic with updated REST endpoints; on-premises deployments may use older API versions with different field names.

Migration approach

Six steps for a successful IS Packaging to Epicor Prophet 21 data migration

  1. Discovery and extraction audit

    We conduct a discovery phase that inventories the IS Packaging database schema, identifies all standard and custom objects, measures record volumes per object, and assesses data quality. We extract a representative sample of 50-100 records per object to validate field-level mapping. This phase also includes identifying the IS Packaging BOM revision scheme, plant-level lot conventions, open Production Order status values, and any custom pricing or costing rules. The discovery output is a written migration scope document, a preliminary object mapping matrix, and a lot-normalization requirements document for multi-plant implementations.

  2. BOM revision cross-reference and lot-normalization rule building

    Before any data moves, we build the BOM revision cross-reference table by matching every IS Packaging BOM revision to its target Epicor PartRev. We also build the lot-normalization rule for each source plant. These two artifacts are the critical path items; migration cannot proceed past sandbox testing until both are validated. We deliver these as spreadsheets with source value, target value, and transformation logic that the customer's team reviews and signs off before we proceed to extraction.

  3. Sandbox migration and validation

    We run a full migration into a customer-provided Epicor Sandbox using production-like data volumes. We import in dependency order: Sites (for multi-plant), Part and PartPlant (with PartRev BOMs and PartMtl components), Vendor records, Job records (from Production Orders), PartBin (inventory), PartTran (transactions), OrderHed and OrderDtl (customer orders), and GLAccount mappings last. Each phase emits a row-count reconciliation report. The customer's operations and IT team spot-checks 25-50 records per object against the IS Packaging source and signs off the mapping before production migration begins.

  4. Custom field and UD table preparation

    We create Epicor UD columns and UD tables for all IS Packaging custom fields identified during discovery. This includes Part UD fields, OrderHed UD fields, JobHead UD fields, and any standalone custom tables. Custom fields that cannot map to Epicor UD columns are flagged with an explanation and recommended alternative placement. We do not rebuild IS Packaging customizations or VAR-specific modifications; we document them for the customer's Epicor partner to address as a separate workstream.

  5. Production migration and cutover

    We freeze writes to IS Packaging during cutover, extract the final delta of any records modified during the migration window, and run the production import in dependency order. We resolve all parent-record lookups (PartNum on JobMtl, PartRev.RevisionNum on JobMtl, Site on JobHead, Warehouse and Bin on PartBin) at import time. We run post-import reconciliation comparing record counts and spot-checking values against the IS Packaging source. Lot-normalization is applied during PartBin and PartTran import. We do not migrate IS Packaging Workflows, Automations, or Reports; we deliver a written inventory of these for the customer's admin and Epicor partner to rebuild.

  6. Post-migration validation and handoff

    We validate inventory balances (PartBin on-hand vs. IS Packaging last count), BOM completeness (every PartRev has at least one PartMtl), and job status (open jobs in Epicor match open orders in IS Packaging). We deliver the final migration report, the BOM revision cross-reference, the lot-normalization map, and the custom field inventory to the customer's team. We support a one-week hypercare window for reconciliation issues raised during the first production week. Any Epicor Workflow, BPM, or Report rebuild is outside standard migration scope.

Platform deep dives

Context on both ends of the pair

IS Packaging logo

IS Packaging

Source

Strengths

  • Purpose-built for multi-plant packaging operations with BOM and routing support
  • Integrates production scheduling, inventory, and costing in one database
  • Supports revision control for BOMs used in regulated food and pharmaceutical packaging
  • Provides lot/serial traceability from raw materials through finished goods
  • Offers MRP pegging to tie customer demand to specific production orders

Weaknesses

  • Limited documented public API — no widely published REST or bulk export endpoints
  • Customizations and modifications vary significantly between customer implementations
  • Reporting and analytics capabilities are generally considered basic compared to tier-one ERPs
  • Support and documentation quality depends heavily on the specific VAR or internal IT team
  • No self-service cloud option known at time of research — implementations are typically on-premises or hosted
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 IS Packaging 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

    IS Packaging: Not publicly documented — governed by underlying SAP S/4HANA Gateway and OData service limits, which we confirm with the vendor at scoping..

  • Data volume sensitivity

    A

    IS Packaging exposes a bulk API — large-volume migrations stream efficiently.

Estimator

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

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

Can't find your answer?

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

Book a free 30 minute consultation

Migrations under 10,000 Items, 500 BOM revisions, and 1,000 open Production Orders at a single plant typically complete in six to ten weeks. Multi-plant consolidations with divergent lot conventions, large transaction histories, or extensive custom fields extend to fourteen to twenty weeks because of BOM revision cross-reference building, lot-normalization rule development, and phased sandbox-to-production validation. Discovery takes two to three weeks, sandbox migration three to four weeks, and production cutover one to two weeks.

Adjacent paths

Related migrations to explore

Ready when you are

Move from IS Packaging.
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