ERP migration

Migrate from PILOT:Suite to Epicor Prophet 21

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

PILOT:Suite logo

PILOT:Suite

Source

Epicor Prophet 21

Destination

Epicor Prophet 21 logo

Compatibility

50%

6 of 12

objects map 1:1 between PILOT:Suite and Epicor Prophet 21.

Complexity

CModerate

Timeline

4-8 weeks

Rollback included Accuracy guarantee Field-level validation

Overview

What this migration involves

Moving from PILOT:Suite to Epicor ERP is a manufacturing-centric ERP migration that requires careful sequencing of master data before transactional records, BOM and routing translation for job-based environments, and GL Account balance roll-forward into Epicor fiscal periods. PILOT:Suite organizes data around Items, Warehouses, Vendors, Customers, Purchase Orders, Sales Orders, and GL Accounts; Epicor ERP maps these to Part, Site, Supplier, Customer, PO, SO, and GL Account entities respectively, with manufacturing-specific objects like Job, BOM, and Routing requiring explicit transformation. We sequence the load to preserve open AP/AR references, resolve parent-record lookups (Site on Part, Supplier on PO, Customer on SO), and flag orphaned records that reference inactive entities in the destination before any data moves. Workflows, custom alerts, and system-level automation built inside PILOT:Suite do not migrate as code; we deliver a written inventory of these for the customer's admin team to rebuild in Epicor Kinetic or the on-premise equivalent.

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

PILOT:Suite logo

PILOT:Suite

What's pushing teams away

  • No public reviews on Capterra (0 reviews recorded) make peer validation effectively impossible during evaluation.
  • Pricing is fully sales-led with no published tiers, making early-stage budget conversations difficult.
  • Mid-market and enterprise MES competitors (Rockwell PlantPAx, Siemens Opcenter, Aveva) have larger partner ecosystems and broader IIoT integration libraries.
  • Felten Group is a German-rooted vendor — partner coverage and support depth outside DACH and Europe may be thinner than buyers expect.
  • Custom integrations to ERP and CMMS systems require Felten Group services rather than a self-serve API marketplace.

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 PILOT:Suite objects map to Epicor Prophet 21

Each row shows how a PILOT:Suite 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.

PILOT:Suite

Item

maps to

Epicor Prophet 21

Part

1:1
Fully supported

PILOT:Suite Items map to Epicor Part records. The Item Number becomes PartNum, description migrates to the Description and ShortChar01 fields, and cost rolls forward into PartUnitCost. We resolve Part plant assignments by matching PILOT:Suite warehouse codes to Epicor Site codes during the Part insert phase. Stocking types (make, buy, service) map from PILOT:Suite item type flags to Epicor PartType values. Custom fields on Item (UDFs) map to Part CustomFields with type-matched Epicor field creation before import.

PILOT:Suite

Warehouse

maps to

Epicor Prophet 21

Site + Warehouse

1:many
Fully supported

PILOT:Suite Warehouses map to Epicor Site records with a corresponding Warehouse record inside each Site. PILOT:Suite item-warehouse assignments become PartWhse records linking Part to Site-Warehouse. Bin locations in PILOT:Suite migrate to Epicor WhseBin records. Multi-company PILOT:Suite configurations map to separate Epicor Companies with inter-company AP/AR configured as separate legal entities.

PILOT:Suite

Vendor

maps to

Epicor Prophet 21

Supplier

1:1
Fully supported

PILOT:Suite Vendors map to Epicor Supplier records using the vendor code as the SupplierID. Address, contact, and payment terms migrate to the Supplier address book and PaymentTerms linkage. PILOT:Suite vendor-specific item pricing (vendor part numbers, lead times, minimum order quantities) migrates to Epicor SupplierPP records. Any inactive or duplicate vendors are flagged in a reconciliation report before import.

PILOT:Suite

Customer

maps to

Epicor Prophet 21

Customer

1:1
Fully supported

PILOT:Suite Customers map to Epicor Customer records using customer number as the CustID. Address, ship-to, contact, and credit hold status migrate to the Customer address book and CreditHold fields. PILOT:Suite customer-specific pricing and discount groups migrate to Epicor PriceLdisc records. Open AR aging from PILOT:Suite becomes Epicor AR invoices and credit memos with aging carried into the correct fiscal period.

PILOT:Suite

Purchase Order

maps to

Epicor Prophet 21

POHeader + POLine

1:1
Fully supported

PILOT:Suite Purchase Orders map to Epicor POHeader and POLine records. Header fields (PO number, vendor, date, terms) migrate to the POHeader; line items (part number, quantity, unit cost, due date) migrate to POLine with SupplierNum resolved from the Vendor-to-Supplier mapping. Open POs migrate with Release-level scheduling if PILOT:Suite carries release dates. Closed POs migrate as historical records with PODate in the past.

PILOT:Suite

Sales Order

maps to

Epicor Prophet 21

OrderHed + OrderDtl

1:1
Fully supported

PILOT:Suite Sales Orders map to Epicor OrderHed and OrderDtl records. Header fields (order number, customer, ship date, terms) migrate to OrderHed with CustNum resolved from the Customer mapping; line items (part number, quantity, unit price, ship date) migrate to OrderDtl. PILOT:Suite multi-line sales orders become separate OrderDtl lines with lineType variants (make-to-order, stock, assemble-to-order) set from PILOT:Suite item type. Blanket POs and releases map to Epicor BlanketOrder equivalents.

PILOT:Suite

GL Account

maps to

Epicor Prophet 21

GLAccount + COA

1:1
Fully supported

PILOT:Suite GL Accounts map to Epicor GLAccount records within a Chart of Accounts structure. Account number, description, and type (asset, liability, equity, revenue, expense) migrate to GLAccount with NaturalAccount and USETaxType assigned. PILOT:Suite account segments (if any) map to Epicor COASegment values with the segment structure configured before migration. Active versus inactive status carries from PILOT:Suite to GLAccount InActive flag.

PILOT:Suite

Open AP

maps to

Epicor Prophet 21

APInvoice + APLine

lossy
Fully supported

Open AP records from PILOT:Suite (invoices, debit memos, and credit memos with vendor and amount) migrate to Epicor APInvoice records with APLine entries. We carry forward invoice number, vendor reference, invoice date, due date, and open amount. PILOT:Suite payment applications migrate as APLink records. Historical AP aging is preserved for audit by storing the original PILOT:Suite aging bucket in a custom field on APInvoice.

PILOT:Suite

Open AR

maps to

Epicor Prophet 21

ARInvoice + ARLine

lossy
Fully supported

Open AR records from PILOT:Suite (invoices, debit memos, and credit memos with customer and amount) migrate to Epicor ARInvoice records with ARLine entries. Invoice number, customer reference, invoice date, due date, and open amount carry forward. PILOT:Suite payment applications migrate as ARLink records. Customer credit status and payment terms resolve through the Customer mapping.

PILOT:Suite

Custom Fields (UDFs)

maps to

Epicor Prophet 21

Custom Fields on Part/Customer/Supplier

lossy
Fully supported

PILOT:Suite user-defined fields on Item, Vendor, Customer, PO, and SO map to Epicor UD fields (like ShortChar01, Number01, CheckBox01) or formal custom fields created before migration. We inventory every PILOT:Suite UDF during scoping, map the field type to the closest Epicor type, and create the Epicor schema before data migration. Fields without a direct Epicor equivalent are flagged with a type recommendation in the schema design document.

PILOT:Suite

Chart of Accounts Balance

maps to

Epicor Prophet 21

GLJrnDtl + GLAccount

lossy
Fully supported

PILOT:Suite GL Account period balances (opening balances, current period activity) migrate to Epicor GLJrnDtl records for the target fiscal year. We align PILOT:Suite accounting periods to Epicor fiscal periods during scoping, and create GLJrnDtl batch entries for balance roll-forward with journal description referencing the PILOT:Suite migration source. Trial balance validation runs against Epicor's GL Report after import.

PILOT:Suite

Item Warehouse Assignment

maps to

Epicor Prophet 21

PartWhse

1:many
Fully supported

PILOT:Suite records item quantities and assignments per warehouse. These map to Epicor PartWhse records with PartNum and WarehouseCode resolved. Safety stock, reorder point, and ABC codes from PILOT:Suite migrate to the PartWhse fields. Quantity-on-hand carries from the PILOT:Suite inventory snapshot taken at migration date. We flag any PartWhse where the Part or Warehouse cannot be resolved due to inactive source records.

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.

PILOT:Suite logo

PILOT:Suite gotchas

High

Vendor-implemented system with no public developer portal

Medium

Process-industry data model differs from discrete-manufacturing MES

Medium

No published reviews complicate gotcha discovery

Low

Mobile apps and web UI run against the same relational database

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 and routing structures require explicit translation

    PILOT:Suite does not have native Job, BOM, or Routing objects; manufacturing data lives in item attributes and warehouse assignments. Epicor ERP requires explicit BOM (PartMtl) and Routing (PartOpr) records for configure-to-order and job-based environments. We do not auto-generate BOMs from PILOT:Suite item structures. The customer's engineering team or Epicor consultant must design the BOM hierarchy and routing steps before migration; we deliver a BOM Gap Analysis document listing every Part that needs a BOM created in Epicor and the estimated structure depth.

  • Open AP/AR migration requires fiscal period alignment

    PILOT:Suite open AP and AR carry aging buckets and payment terms that Epicor ERP must reproduce in the correct fiscal period. Migrating AP/AR invoices without matching PILOT:Suite accounting periods to Epicor fiscal calendar periods results in trial balance discrepancies and reporting gaps. We perform period alignment during scoping, create Epicor fiscal periods if the target company calendar is not yet configured, and carry forward aging as both transaction records and a snapshot custom field for audit.

  • Epicor DMT requires pre-formatted CSV with exact column mapping

    Epicor's Data Migration Tool (DMT) accepts only pre-formatted CSV files with exact header names and data types per Epicor table schema. PILOT:Suite exports are rarely DMT-ready; data requires transformation, column renaming, and format validation before DMT load. We handle the CSV transformation and DMT formatting as part of the migration pipeline. Migrations that attempt direct PILOT:Suite export to DMT without transformation typically fail with column name mismatches, date format errors, or missing required fields.

  • Multi-site Part costing diverges by site in Epicor

    Epicor stores Part unit cost per site (Plant), meaning the same Part can have a different standard cost at Site A versus Site B. PILOT:Suite typically stores a single cost per item across all warehouses. During migration we must decide whether to propagate a single PILOT:Suite cost to all Epicor sites or allow the customer to set site-specific costs post-migration. This decision affects inventory valuation and COGS accuracy and must be resolved before PartWhse records are loaded.

  • Custom fields on PILOT:Suite UDF tables may lack Epicor equivalents

    PILOT:Suite allows freeform user-defined fields on most entities. Epicor has a fixed field schema with limited extension capacity on core manufacturing and financial objects. Fields that cannot map to an existing Epicor field (for example, a freeform date field on a PILOT:Suite Vendor) are documented with a field type recommendation and an estimated effort to add a custom field via Epicor Custom Field designer. We do not create unlimited custom fields in scope; complex UDF migrations are scoped as a separate configuration engagement.

Migration approach

Six steps for a successful PILOT:Suite to Epicor Prophet 21 data migration

  1. Discovery and source audit

    We audit PILOT:Suite across entity count (Items, Warehouses, Vendors, Customers, open POs, open SOs, open AP, open AR, GL Accounts), UDF inventory per entity, BOM and routing presence, and fiscal period close status. We extract a point-in-time inventory snapshot for PartWhse quantity migration and pull Chart of Accounts balances by period. The discovery output is a written migration scope with record counts, a UDF mapping matrix, and a fiscal period alignment table showing how PILOT:Suite periods map to Epicor fiscal periods.

  2. Schema design and Epicor configuration

    We design the destination schema in Epicor before any data moves. This includes creating GL Account segments and COA structure, configuring Sites and Warehouses, setting up Supplier and Customer address book structures, defining Part types (make, buy, service) from PILOT:Suite item type flags, and creating any required custom fields for UDF migration. We deploy schema to a Epicor test or sandbox environment first for validation. BOM gap analysis is delivered here for the customer's engineering team to address.

  3. Test migration and reconciliation

    We run a full migration into the Epicor sandbox using production-like data volume. The customer's finance and operations leads reconcile record counts (Parts in, Sites in, Suppliers in, Customers in, open AP/AR in), spot-check 25-50 random records against PILOT:Suite source, and validate GL trial balance alignment. Any mapping corrections and BOM gaps are resolved here. No production migration begins until the sandbox sign-off is received.

  4. Master data migration (dependency order)

    We run master data migration in strict dependency order: GL Accounts (no dependencies), Sites and Warehouses, Parts (with Site-Plant resolution), Suppliers (with address book), Customers (with address book and credit hold), then BOM and Routing (after Part validation). Each phase emits a row-count and sample reconciliation report. Orphaned records referencing inactive entities are flagged in a quarantine report and resolved by the customer's admin before the next phase.

  5. Transactional migration (AP/AR and Orders)

    Open AP and AR migrate after master data is validated. We carry forward invoice number, vendor/customer reference, dates, terms, and open amount. Payment terms and aging buckets are preserved in custom fields for audit. Open Purchase Orders and Sales Orders migrate with header-line structure intact, with PartNum resolved to Epicor Part, SupplierNum resolved to Epicor Supplier, and CustNum resolved to Epicor Customer. Closed historical orders migrate as read-only records if scoped.

  6. Cutover, validation, and handoff

    We freeze PILOT:Suite 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 the UDF gap analysis, BOM gap report, and workflow inventory document to the customer's admin and Epicor implementation partner. We support a one-week hypercare window for reconciliation issues. We do not rebuild PILOT:Suite workflows, alerts, or custom reports in Epicor as part of the migration scope; these are documented for the customer's Epicor consultant.

Platform deep dives

Context on both ends of the pair

PILOT:Suite logo

PILOT:Suite

Source

Strengths

  • Process-industry depth since 1990 (quality, energy, supply chain integrated with production).
  • Web-based plus native iOS, Android, and iPad apps from one codebase.
  • Hierarchical multi-site model with rights/roles and multilingual support.
  • Cloud and on-premise deployment options off the same data model.
  • Relational database backend simplifies BI and reporting integration.

Weaknesses

  • No public Capterra/G2 reviews mean peer validation is difficult.
  • Pricing is fully sales-led with no published tiers.
  • No public developer portal or OpenAPI spec.
  • Partner ecosystem skews European; coverage thinner outside DACH.
  • Custom integrations require Felten Group services rather than self-serve.
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?

Moderate ERP migration. 2 of 8 objects need a manual workaround.

C

Overall complexity

Moderate migration

Derived from compatibility, mapping clarity, API constraints, and data volume across PILOT:Suite and Epicor Prophet 21.

  • Object compatibility

    D

    2 of 8 objects need a manual workaround.

  • 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

    PILOT:Suite: Not publicly documented..

  • Data volume sensitivity

    B

    PILOT:Suite doesn't expose a bulk API — REST + parallelization used for high-volume runs.

Estimator

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

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

Can't find your answer?

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

Book a free 30 minute consultation

Most migrations land between four and eight weeks for straightforward scopes under 10,000 Items, 2,000 Vendors, and 3,000 Customers with clean GL, no manufacturing data, and open AP/AR carry-forward. Migrations with BOM and Routing translation, multi-site Part assignments, large open order volumes (over 10,000 PO/SO lines), or GL balance roll-forward across multiple fiscal periods move to twelve to twenty weeks because of BOM gap resolution, site-warehouse hierarchy mapping, and fiscal period alignment work that must happen before transactional migration begins.

Adjacent paths

Related migrations to explore

Ready when you are

Move from PILOT:Suite.
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