ERP migration

Migrate from ProcessWare ERP to Epicor Prophet 21

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

ProcessWare ERP logo

ProcessWare ERP

Source

Epicor Prophet 21

Destination

Epicor Prophet 21 logo

Compatibility

58%

7 of 12

objects map 1:1 between ProcessWare ERP and Epicor Prophet 21.

Complexity

BStandard

Timeline

6-10 weeks

Rollback included Accuracy guarantee Field-level validation

Overview

What this migration involves

Moving from ProcessWare ERP to Epicor ERP is a cross-vertical migration from a niche Flavors and Fragrances platform into a discrete manufacturing ERP. ProcessWare stores formulation hierarchies, allergen declarations, and IFRA compliance data in F&F-specific objects that have no native Epicor equivalent; Epicor Kinetic stores these relationships through Part master hierarchies, PartRev routing structures, and custom fields. We resolve the Formulation-to-Part hierarchy mapping during discovery, build the PartRev multi-level BOM structures from ProcessWare multi-level recipe exports, and create custom fields for IFRA classification and allergen declarations in Epicor before any records load. The absence of a documented ProcessWare API means we work with CSV exports or database-level access provided by the customer's IT team, which shapes the extraction timeline. Workflows, compliance rule engines, and regulatory approval chains do not migrate; we deliver a written inventory of every ProcessWare automation and compliance rule for the customer's Epicor admin to rebuild in Kinetic.

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

ProcessWare ERP logo

ProcessWare ERP

What's pushing teams away

  • Users report a steep learning curve requiring significant training investment before teams become productive, especially for staff accustomed to simpler systems.
  • The platform lacks offline mode, making it impractical for field sales representatives or warehouse staff in environments with unreliable connectivity.
  • G2 reviewers note difficulty finding specific data within the system, suggesting information architecture or search capabilities are weaker than competing ERPs.
  • Frequent updates require ongoing adaptation, and the absence of a mature app ecosystem means custom functionality must be built by the vendor.

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

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

ProcessWare ERP

Customer

maps to

Epicor Prophet 21

Customer

1:1
Fully supported

ProcessWare Customer records map directly to Epicor Customer. We map customer account hierarchies, contact details, and sales history to Epicor's Customer and ShipTo records. The ProcessWare CRM component's customer lifecycle data (from initial inquiry through active account) migrates as a combination of Customer records and Contact records linked via the CustCnt table. Any customer-specific pricing agreements from ProcessWare migrate as CustPriceLbr records in Epicor.

ProcessWare ERP

Vendor Record

maps to

Epicor Prophet 21

Supplier

1:1
Fully supported

ProcessWare Vendor records map to Epicor Supplier. Supplier profiles including certification status and material qualifications migrate to Supplier tables. We resolve the vendor-to-Part cross-reference during import so that Epicor Part records link to the correct Supplier during procurement.

ProcessWare ERP

Formulation Recipe

maps to

Epicor Prophet 21

Part (configured as compound)

1:many
Fully supported

ProcessWare Formulation Recipe is the core F&F object with compound hierarchies, ingredient ratios, version history, and IFRA regulatory classification. We map each Formulation Recipe to an Epicor Part record with PartType = M (Manufactured). The version history migrates as a series of PartRev revisions (RevisionsNum) with effective dates preserved. Ingredient ratios migrate as PartMtl records linked to sub-formulation Part records. IFRA classification, allergen declarations, and regulatory data map to custom fields on Part (e.g., IFRA_Class_c, Allergen_Flags_c) that we pre-create in Epicor during schema design.

ProcessWare ERP

Bill of Materials

maps to

Epicor Prophet 21

PartMtl

1:many
Fully supported

ProcessWare multi-level BOMs map to Epicor PartMtl structures. We preserve the nesting by creating sub-assembly Part records for each ProcessWare sub-formulation referenced in a BOM, then create PartMtl records with appropriate material quantity andBomSequence values. Epicor's material explode query traverses PartMtl to compute full BOM explosion for production planning. We flag any circular BOM references (where a sub-formulation references its parent) for manual resolution before migration.

ProcessWare ERP

Production Order

maps to

Epicor Prophet 21

Job

1:1
Fully supported

ProcessWare Production Orders (manufacturing directives tied to specific formulations) map to Epicor JobMtl and JobOper records. The ProcessWare formulation reference becomes the Job's setup Make to Order link. Planned quantities, scheduling constraints, and facility routing map to Epicor JobHead, JobMtl, and JobOper respectively. We preserve the production batch number as JobHead.JobNum for traceability back to ProcessWare records.

ProcessWare ERP

Quality Record

maps to

Epicor Prophet 21

QAEngineer records or PartTran ( Lot / Batch)

1:1
Fully supported

ProcessWare Quality Records linked to production batches and raw material lots map to Epicor PartTran for traceability transactions and to custom QA record types that we configure during schema design. Test results and QC documentation attach as PartLot records (with LotNbr and LotText) or as linked DocStar documents if the customer licenses Epicor Document Management. Inspector assignments migrate as User references in the QA record.

ProcessWare ERP

Supply Chain Transaction

maps to

Epicor Prophet 21

PartTran, PODetail, ShipHead

1:1
Fully supported

ProcessWare Supply Chain Transactions (purchase orders, receipts, outbound shipments) map to Epicor PartTran for inventory movements, PODetail for purchase order lines, and ShipHead for outbound shipments. Full traceability to production batches is preserved by maintaining the LotNbr and JobNum references across all transactions. Any orphan Transactions without Customer or Vendor linkage are flagged for manual review before load, matching the same reconciliation process documented for ProcessWare source data.

ProcessWare ERP

Regulatory Compliance Document

maps to

Epicor Prophet 21

Custom fields on Part + DocStar attachments

lossy
Fully supported

ProcessWare IFRA compliance data, SDS documents, and allergen declarations tied to formulations have no native Epicor equivalent and require configuration. We create custom fields on the Part table (e.g., IFRA_Category_c, SDS_DocStarLink_c, Allergen_Declarations_c) and migrate document references as DocStar attachments linked to the Part record. The naming convention and compliance classification mapping is documented during discovery because IFRA sub-segment requirements vary between F&F sub-verticals.

ProcessWare ERP

Custom Fields

maps to

Epicor Prophet 21

Custom fields on destination objects

lossy
Mapping required

ProcessWare custom fields (confirmed accessible via Keka HRMS integration as read/write) map to Epicor custom fields on the corresponding table. We pre-create the Epicor UD field schema during discovery, map field data types (text, numeric, date, checkbox), and migrate values during the object import phase. Epicor's UD column prefix (Character01, ShortChar01, Number01, etc.) is used for custom field mapping when the customer's Epicor configuration does not use the more flexible UD Table approach.

ProcessWare ERP

Attachment

maps to

Epicor Prophet 21

Document Management (DocStar) or file share

1:1
Fully supported

Supporting documents attached to formulations, quality records, and transactions in ProcessWare are extracted and reattached to the corresponding Epicor Part, PartLot, or Job records. We map ProcessWare file storage locations to Epicor Document Management (DocStar) if licensed, or to a structured file share with document type metadata preserved. Not all legacy file formats can be guaranteed accessible post-migration; we document any unsupported formats in the extraction report.

ProcessWare ERP

Raw Material Lot

maps to

Epicor Prophet 21

PartLot

1:1
Fully supported

ProcessWare raw material lots linked to formulations and production batches map to Epicor PartLot records. LotNbr, LotDescription, LotQty, LotExpirationDate, and LotCost migrate from ProcessWare's material lot traceability data. PartLot records are linked to Part via PartNum so that Epicor's LotTracker functionality provides the same real-time traceability from raw material lot to finished compound batch.

ProcessWare ERP

Account / Financial

maps to

Epicor Prophet 21

GL Account

lossy
Fully supported

ProcessWare ERP+CRM combined means financial data may coexist with operational data. We extract GL account structures from ProcessWare exports and map them to Epicor COA (Chart of Accounts) segments. This mapping requires coordination with the customer's accountant to confirm account code structure (segmented vs flat COA) and any F&F-specific cost centers before migration.

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.

ProcessWare ERP logo

ProcessWare ERP gotchas

High

No publicly documented public API

Medium

Steep learning curve increases migration project risk

Medium

Specialized F&F data objects lack direct equivalents in generic ERPs

Low

Absence of offline mode complicates warehouse-floor data collection

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

  • ProcessWare has no publicly documented API

    Our research found no publicly accessible API documentation for ProcessWare ERP. The only documented third-party interaction is through Keka HRMS, which confirms custom fields are accessible via read/write operations, but the full object schema and endpoint structure remain undocumented. We work around this by coordinating with the customer's IT team to provide database-level access or CSV exports from ProcessWare's reporting module before mapping into our migration pipeline. This extends discovery by two to four weeks and requires the customer's IT team to produce reliable export files from the source system before extraction can begin.

  • Kinetic cloud removes direct SQL database access

    Epicor Kinetic Cloud does not provide direct SQL database access. If the customer's ProcessWare migration relies on a strategy that assumes Epicor on-premise direct DB writes for data import (a common pattern in older Epicor implementations), this must change. We use Epicor Kinetic DMT (Data Management Tool) for batch CSV/Excel imports and BAQ exports for extraction. BAQ-based exports require the customer to have Epicor BAQ expertise or for us to define and validate BAQ queries during the discovery phase. This is a fundamental architectural difference from Epicor on-premise migrations that rely on SQL-level data movement.

  • F&F regulatory compliance objects lack Epicor native equivalents

    Formulation version histories, allergen declarations, and IFRA compliance classifications are highly specific to ProcessWare's F&F data model and have no native Epicor equivalent. Epicor does not have a pre-built IFRA classification object, allergen declaration field, or formulation version tracker. We document the complete object dependency graph during discovery and map these to Epicor custom fields on Part, PartRev, and PartLot. The customer must plan and approve the custom field buildout in Epicor before cutover; Epicor custom fields require administration privileges and are created through Epicor Kinetic's Customization workspace or via UD table definition.

  • Multi-level BOM explosion requires PartRev build sequencing

    ProcessWare multi-level BOMs where sub-assemblies reference other formulations as ingredients require a sequenced PartRev build in Epicor. Circular references (where a sub-formulation references its parent formulation in a BOM) cause Epicor's BOM explosion to fail. We run a BOM dependency analysis during discovery to identify circular references, flag them for the customer's engineering team to resolve in ProcessWare before extraction, and then build Epicor PartRev records in bottom-up dependency order so that sub-assemblies exist before parent BOMs reference them.

  • Epicor DMT requires pre-validation of import file formats

    Epicor DMT (Data Management Tool) enforces referential integrity at import time: parent records must exist before child records can import, and field-level validation (required fields, picklist values, numeric formats) will reject entire batches if any record fails. We build DMT-ready import templates from ProcessWare exports, validate them against Epicor's DMT schema requirements, and run import batches in strict dependency order (Customers before Orders, Parts before BOMs, BOMs before Jobs). Any validation failures are isolated to specific rows and resolved before the next batch begins.

Migration approach

Six steps for a successful ProcessWare ERP to Epicor Prophet 21 data migration

  1. Discovery and ProcessWare export coordination

    We audit the ProcessWare system in collaboration with the customer's IT team to understand the full data inventory: Customer records, Vendor records, Formulation Recipe count and version depth, BOM nesting levels, Quality Record volume, Supply Chain Transaction history, and any custom field usage. Because ProcessWare has no documented API, we define the CSV export schema during discovery by sampling actual ProcessWare record layouts with the customer's IT team. We identify any orphan Transactions lacking Customer or Vendor linkage during this phase and flag them for manual resolution. The discovery output is a written extraction specification, a ProcessWare export file delivery schedule, and a migration object inventory.

  2. Epicor Kinetic schema design and custom field buildout

    We design the Epicor destination schema including Part setup (PartType, Unit of Measure, Product Code groups), PartRev revisions (one per Formulation Recipe version), PartMtl structures (BOM levels in dependency order), Supplier records, Customer records, and custom field definitions for IFRA classification, allergen declarations, and any ProcessWare custom field equivalents. We create custom fields through Epicor Kinetic's Customization workspace or UD table definitions and validate that they appear in the correct Kinetic forms (Part Maintenance, Job Entry, Quality Management) before data loading begins. This phase requires active participation from the customer's Epicor administrator.

  3. Extraction, transformation, and BOM dependency analysis

    We extract data from ProcessWare using the agreed CSV export format or database access provided by the customer's IT team. During extraction, we run the BOM dependency analysis to identify circular references in ProcessWare formulation hierarchies and flag them for engineering resolution. We transform ProcessWare data into Epicor DMT-compatible CSV format: Part records first (manufactured parts for formulations, stock parts for raw materials), then PartMtl records (BOM levels bottom-up), then PartLot records for raw material lots, then Customer and Supplier records, then Job records (production orders), then PartTran records (supply chain transactions). Each extraction file is validated against Epicor's DMT template schema before loading.

  4. Sandbox migration and reconciliation

    We run a full migration into Epicor Kinetic Sandbox using production-like data volume. The customer's Epicor administrator and process owners reconcile record counts (Parts in, PartMtl rows in, Customers in, Jobs in, PartTran transactions in), spot-check 25-50 random records against the ProcessWare source, and validate BOM explosion (PartMtl multi-level query) produces the expected material demand. Any custom field mapping corrections, BOM sequencing fixes, or PartRev revision assignments happen in Sandbox, not in production. The customer signs off the sandbox migration before production migration begins.

  5. Production migration in dependency order with DMT

    We run production migration in Epicor Kinetic using DMT batch imports in strict dependency order: Part master records first (formulation parts and raw material parts), then PartMtl (BOM rows in bottom-up sequence), then PartLot (raw material lots), then Customer and Supplier, then Job records (production orders with PartNum, JobMtl, and JobOper populated), then PartTran transactions for supply chain traceability. Each DMT batch is validated by Epicor's import engine and emits a row-count reconciliation report before the next phase begins. Any orphan transactions identified during reconciliation are held in a manual review queue for the customer's team to resolve.

  6. Cutover, validation, and automation rebuild handoff

    We freeze ProcessWare writes during cutover, run a final delta migration of any records modified during the migration window, then enable Epicor as the system of record. We deliver a written inventory of every ProcessWare automation, compliance rule, and workflow requiring rebuild in Epicor Kinetic (workflows, compliance rule engines, and regulatory approval chains are out of scope for migration). We provide a field-by-field reconciliation report so functional teams (formulation engineers, QA managers, supply chain planners) can confirm data accuracy without needing technical knowledge of the source system. We support a one-week hypercare window for reconciliation issues. Epicor Kinetic implementation, workflow rebuild, and post-migration training are separate engagements handled by the customer's Epicor partner or internal admin team.

Platform deep dives

Context on both ends of the pair

ProcessWare ERP logo

ProcessWare ERP

Source

Strengths

  • Only ERP purpose-built for Flavors & Fragrances with native IFRA and regulatory compliance modeling
  • ERP+CRM combined eliminates data silos between customer-facing and operational teams
  • Real-time traceability from raw material lot to finished compound batch
  • Cloud-native architecture with IoT and sensor connectivity for real-time operational visibility

Weaknesses

  • Extremely narrow vertical focus limits available migration resources and third-party tooling
  • No public API documentation found; Keka HRMS integration is the only documented third-party API reference
  • Steep learning curve documented across G2 reviews, increasing change management effort during migration
  • Minimal market share in the broader ERP category means limited community knowledge to draw from
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 ProcessWare ERP 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

    ProcessWare ERP: Not publicly documented.

  • Data volume sensitivity

    B

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

Estimator

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

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

Can't find your answer?

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

Book a free 30 minute consultation

Most ProcessWare to Epicor migrations land between six and ten weeks for accounts with under 500 active Formulation Recipes, two-level BOM structures, and clean customer and vendor data. Migrations with deep formulation version histories (five or more versions per recipe), multi-level BOMs (three or more nesting levels), high-volume Quality Records, and raw material lot traceability chains requiring PartLot configuration move to twelve to twenty weeks because of the additional PartRev build complexity, BOM explosion validation, and IFRA custom-field mapping scope. The absence of a documented ProcessWare API extends discovery by two to four weeks compared to migrations from platforms with accessible APIs.

Adjacent paths

Related migrations to explore

Ready when you are

Move from ProcessWare ERP.
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