ERP migration

Migrate from Epicor Eclipse to Epicor Prophet 21

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

Epicor Eclipse logo

Epicor Eclipse

Source

Epicor Prophet 21

Destination

Epicor Prophet 21 logo

Compatibility

93%

13 of 14

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

Complexity

BStandard

Timeline

8-12 weeks

Rollback included Accuracy guarantee Field-level validation

Overview

What this migration involves

Epicor Eclipse to Epicor ERP is an intra-vendor upgrade with a specific technical complication: Eclipse runs on Rocket UniVerse, a MultiValue NoSQL database, while Epicor ERP uses a standard relational schema. That database-level difference means this migration is never a simple export-import. We extract Eclipse data through its REST API (port 5000, session-based authentication) supplemented by CSV exports and EDA dashboards, then transform UniVerse dynamic arrays and file-based records into typed Epicor ERP fields. We map Eclipse's Quote-to-Invoice workflow chain end-to-end, flagging any step that breaks in the destination before cutover. Custom UniBASIC programs, EDA configurations, and custom file dictionaries do not migrate automatically; we deliver a written inventory of these for your admin to redevelop. We do not migrate workflows, automations, EDI maps, or forms as code.

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 Eclipse logo

Epicor Eclipse

What's pushing teams away

  • Eclipse lacks a true cloud-native version, pushing organizations toward Kinetic or competing cloud ERPs for scalability and remote access.
  • The character-based green screen interface feels outdated compared to modern web-based ERPs, creating friction for new employees and remote teams.
  • Limited built-in reporting and analytics capabilities require significant customization or third-party tools to gain actionable insights.
  • Integration with modern CRM, e-commerce, and MES systems is challenging without custom development, creating data silos.
  • Rising per-user costs ($120-200/month) and implementation fees drive organizations to evaluate lower-cost cloud alternatives.

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

Each row shows how a Epicor Eclipse 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 Eclipse

CUSTOMER

maps to

Epicor Prophet 21

Customer

1:1
Fully supported

Eclipse stores customer records in the CUSTOMER file with ship-to addresses in SHIP.TO, contacts in CONTACT, and classifications in CUSTOMER.CLASS, all stored as UniVerse dynamic arrays. We extract via the Eclipse REST API or direct file parsing, normalize multi-value address structures into Epicor ERP's standard address schema, and map customer-specific pricing classes and credit limits to CustomerPricesch熊 and CreditLimit fields. The customer number from Eclipse becomes the Epicor ERP CustomerID as the dedupe key.

Epicor Eclipse

SUPPLIER

maps to

Epicor Prophet 21

Vendor

1:1
Fully supported

Eclipse vendor records (SUPPLIER file) include PO history, rebate terms, EDI capabilities, and multi-value buying codes. We extract the vendor master, transform vendor-specific classifications into Epicor ERP Vendor records, and preserve EDI capability flags in custom vendor fields. VENDOR.PRODUCT cross-references map to the Epicor ERP PartVendors table with vendor part numbers preserved.

Epicor Eclipse

PRODUCT

maps to

Epicor Prophet 21

Part

1:1
Fully supported

Eclipse Part records (PRODUCT file) contain dynamic attributes, substitute/replacement chains, and warehouse-specific stocking data stored as dynamic arrays. We flatten these into Epicor ERP Part records, mapping unit-of-measure definitions from UOM, product groups from PRODUCT.GROUP, and part classifications. User-defined dictionary fields that were added via UniBASIC are flagged for manual mapping in Epicor ERP's UD field framework.

Epicor Eclipse

INVENTORY

maps to

Epicor Prophet 21

PartWhse

1:1
Fully supported

Eclipse tracks on-hand, allocated, and on-order quantities per warehouse per part using multi-value fields in the INVENTORY file. We extract warehouse-level quantities, map bin and location data to Epicor ERP's warehouse management schema, and validate that on-hand values reconcile to Eclipse's inventory valuation report. Lot and serial number tracking data migrates to PartLot and PartBin tables with full traceability dates.

Epicor Eclipse

ORDER

maps to

Epicor Prophet 21

SalesOrder

1:1
Fully supported

Open sales orders from Eclipse's ORDER file link to customer, part, pricing, and warehouse records. We extract order headers and line detail, preserving order-specific discounts, notes, and sales person assignments. Order dates, due dates, and ship dates transfer to Epicor ERP SalesOrderHed and SalesOrderDtl. Partially shipped orders require careful line-level status mapping to preserve fulfillment state in the destination.

Epicor Eclipse

PO

maps to

Epicor Prophet 21

PurAgent

1:1
Fully supported

Eclipse purchase orders include vendor terms, line items, and receiving status. We extract open POs, map them to Epicor ERP PO records, and flag partially-received orders that require line-level receipt handling in the destination. PO approval workflow configurations in Eclipse do not migrate; we document the approval chain for reconstruction in Epicor ERP.

Epicor Eclipse

QUOTE

maps to

Epicor Prophet 21

QuoteHed

1:1
Fully supported

Open quotes from Eclipse's quote file migrate to Epicor ERP QuoteHed and QuoteDtl with full line detail, pricing, and configuration data. Closed quote statistics (win/loss rates, average deal size) summarize into a migration report rather than individual records. Eclipse stores quote lines with configuration chains that require careful field-by-field mapping to Epicor ERP's quote schema.

Epicor Eclipse

GLACCT

maps to

Epicor Prophet 21

GLAccount

1:1
Fully supported

Eclipse account structures use non-standard numbering and can embed divisions and cost centers in the same field. We extract account masters, segment them per Epicor ERP's chart of accounts structure (Company-Division-Department-Account-SubAccount), and map external account references. Historical account balances transfer to Epicor ERP's GLJrnDtl with the appropriate fiscal period assignments.

Epicor Eclipse

AR/AP

maps to

Epicor Prophet 21

InvoiceHead / VendorInvoice

1:1
Fully supported

Outstanding invoices (AR) and vouchers (AP) are extracted with full aging data, customer/vendor references, and payment terms. We preserve open invoice totals, aging buckets, and apply-to information for reconciliation in Epicor ERP. Lockbox payments and partial payment history migrate as PaymentDtl records attached to the original invoice.

Epicor Eclipse

CUSTOMER.CLASS

maps to

Epicor Prophet 21

CustomerPriceGroup

1:1
Fully supported

Eclipse customer classifications and pricing assignments map to Epicor ERP CustomerPriceGroup records. Price Break schedules attached to customer classes migrate to PriceLst records with effective dates preserved. This mapping is required before Customer records insert so that pricing group references are satisfied.

Epicor Eclipse

PRODUCT.GROUP

maps to

Epicor Prophet 21

ProductGroup

1:1
Fully supported

Eclipse product categories and classifications (PRODUCT.GROUP file) map directly to Epicor ERP ProductGroup records. The category hierarchy transfers with parent-group references preserved, and each group's default stocking warehouse assignments migrate to the ProductGroup record.

Epicor Eclipse

PDA / Tax

maps to

Epicor Prophet 21

TaxRegion

1:1
Fully supported

Tax jurisdiction assignments and rates tied to customer ship-to locations in Eclipse's tax master extract to Epicor ERP TaxRegion and TaxConn records. Any tax calculation logic embedded in custom UniBASIC programs is flagged for redeployment as BPMs in Epicor ERP, because tax engine configuration does not migrate as code.

Epicor Eclipse

DOCUMENT

maps to

Epicor Prophet 21

Document attachment records

lossy
Fully supported

Eclipse stores document images and attachments in file repositories (DOCUMENT file, Document Imaging module). We extract document references and metadata, mapping file paths and image records to Epicor ERP's attachment framework. Image files themselves require separate file transfer rather than API insertion and are flagged as a distinct step in the migration approach.

Epicor Eclipse

USER / EMPLOYEE

maps to

Epicor Prophet 21

UserAccount

1:1
Fully supported

Eclipse user records include role assignments, warehouse access, and salesperson links. We extract the user master, map to Epicor ERP UserAccount records with role preservation, and flag inactive accounts for admin review before cutover. Salesperson assignments from Eclipse migrate to Epicor ERP SalesRep records linked to UserAccount.

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 Eclipse logo

Epicor Eclipse gotchas

High

UniVerse MultiValue extraction requires non-standard tools

High

Performance degradation post-Kinetic migration

High

End-to-end workflow must be validated as a chain

Medium

Historical data scoping determines migration cost

Medium

Integration connections require separate migration planning

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

  • UniVerse MultiValue extraction requires non-standard tools

    Epicor Eclipse runs on Rocket UniVerse, a NoSQL database with file-based storage and PICK BASIC programming. Standard SQL connectors cannot read Eclipse data directly. We use Eclipse's REST API (port 5000, session-based authentication) where available, supplemented by CSV bulk exports and EDA dashboard data pulls. For data locked in UniBASIC programs or user-defined dictionary fields, we engage direct UniVerse file access or UniVerse BASIC queries. Without these specialized extraction methods, the migration cannot proceed beyond superficial record counts.

  • Custom UniBASIC programs and EDA configurations do not migrate

    Eclipse customers commonly have custom UniBASIC programs that perform tax calculations, pricing logic, or data transformations embedded in the application layer. EDA dashboard configurations, custom reports, and Mass Load setups similarly live outside the database. These artifacts do not have a migration path to Epicor ERP. We deliver a written inventory of every custom program, its function, its data dependencies, and its recommended Epicor ERP replacement (BPM, REST endpoint, or Kinetic customization). The customer's development team or an Epicor partner redevelops these post-migration.

  • End-to-end workflow chain must be validated step by step

    Eclipse workflows (Quote → Order → Job → Material → Labor → Shipment → Invoice → Financials) are tightly linked with field-level dependencies between stages. If even one step breaks in Epicor ERP, the downstream chain breaks. We run full end-to-end test scenarios post-load, validating that each workflow stage connects correctly to the next and that financial totals reconcile to Eclipse balances. This validation phase typically adds one to two weeks to the timeline and should not be skipped or compressed.

  • Partially-received POs and partially-shipped orders require line-level mapping

    Open Eclipse POs that are partially received and open sales orders with partial shipments have status flags stored across multiple Eclipse files. The migration must map the partial receipt quantity, the pending receipt quantity, and the receiving history to Epicor ERP's PO Receipt and Order Release tables accurately. Migrations that treat these as simple header imports end up with Epicor ERP showing incorrect PO and order status, triggering duplicate receiving actions by warehouse staff.

  • EDI and integration connections require separate re-enrollment planning

    Eclipse EDI maps, trading partner configurations, and third-party integration endpoints do not migrate to Epicor ERP. The Epicor EDI team has moved customers from TPCx to Epicor EDI with modern AS2, SFTP, and API protocols, but this required new map builds and trading partner re-enrollment for each connection. We identify all integration endpoints during scoping, map integration logic to Epicor ERP's integration framework, and test connectivity before cutover. EDI connections specifically require coordination with trading partners on new IDs and acknowledgment configurations.

Migration approach

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

  1. Eclipse configuration audit and extraction method selection

    We document the current Eclipse configuration: version, modules licensed (Order Management, Counter/POS, Inventory, Purchasing, Financial Management, CRM, EDI, Document Imaging), custom UniBASIC programs, EDA dashboard count, Mass Load setups, and API endpoint availability. We then determine the extraction method: Eclipse REST API (session-based, port 5000) for structured master and transaction data; CSV bulk exports for high-volume items like inventory and order history; EDA dashboard exports for historical reporting data. Direct UniVerse file access via UniBASIC queries is reserved for any data not surfaced through API or CSV.

  2. Data mapping design and UniVerse transformation logic

    We design the transformation layer from Eclipse's UniVerse file structure to Epicor ERP's relational schema. This includes mapping CUSTOMER to Customer with SHIP.TO as address records, PRODUCT to Part with PRODUCT.GROUP as ProductGroup, ORDER to SalesOrder with line-level detail, and INVENTORY to PartWhse with warehouse-level quantities. Dynamic arrays in Eclipse (where multiple values are stored in a single field delimited by field marks) are flattened into separate Epicor ERP fields. Any user-defined dictionary fields in Eclipse are flagged for manual mapping to Epicor ERP UD field equivalents. This mapping document is reviewed by the customer's Eclipse admin and Epicor ERP consultant before extraction begins.

  3. Historical data scoping and archive decision

    Eclipse does not auto-purge, so years of data are available. We scope the migration with the customer upfront: open orders, open POs, and current inventory are mandatory. Sales history (typically 2-5 years), customer purchase history, and job history for warranty traceability are common inclusions. Complete invoice history, payment history, and archived document images are optional and add cost and extraction time. Historical data that is required for compliance but not for day-to-day operations is a candidate for archive rather than live migration into Epicor ERP, keeping the new system lean and performant.

  4. Sandbox migration and reconciliation

    We run a full migration into an Epicor ERP Sandbox using representative data volume. The customer's operations and finance leads reconcile record counts (Customers in, Vendors in, Parts in, Orders in, Inventory balances, GL account totals), spot-check 25-50 records against the Eclipse source, and validate that the Quote-to-Invoice workflow chain functions in the sandbox environment. Any mapping corrections, missing field assignments, or workflow breaks are resolved here before production migration begins. This step also validates extraction throughput so that production timelines are realistic.

  5. Production migration in dependency order

    We run production migration in record-dependency order: ProductGroups and CustomerPriceGroups (no dependencies), Parts (with UOM definitions), Vendors, Customers (with ship-to addresses and contacts), PartWhse (inventory with warehouse and bin data), open Sales Orders (with customer and part lookups resolved), open Purchase Orders (with vendor lookups resolved), Quotes, GL Account structure, open AR/AP invoices, and historical transactions last. Each phase emits a row-count and value reconciliation report before the next phase begins. The Eclipse system remains live during migration so that any new transactions during the migration window are captured in a final delta pass before cutover.

  6. Cutover, workflow validation, and custom program handoff

    We freeze Eclipse writes during cutover, run a final delta migration, then validate the full Quote-to-Invoice chain in Epicor ERP with a live test order. Financial totals (AR/AP aging, inventory value, GL trial balance) reconcile to Eclipse pre-cutover reports. We deliver the inventory of custom UniBASIC programs, EDA dashboards, and EDI maps requiring rebuild to the customer's Epicor ERP admin team, with recommended redevelopment paths. We support a one-week hypercare window for reconciliation issues. We do not rebuild UniBASIC programs as Epicor ERP BPMs within the migration scope; that is a separate development engagement.

Platform deep dives

Context on both ends of the pair

Epicor Eclipse logo

Epicor Eclipse

Source

Strengths

  • Specialized for wholesale distribution with counter/POS, cross-docking, RF scanning, and rebate tracking built in.
  • Strong multi-warehouse inventory management with bin locations, lot/serial tracking, and drop-ship capabilities.
  • Integrated financial management including AR/AP, credit management, and multi-currency for distributors.
  • Hot-key interface (F11) allows rapid data entry for high-volume counter sales environments.
  • Epicor Data Analytics (EDA) provides cloud-based dashboards and pre-built reports from Eclipse data.

Weaknesses

  • No true cloud-native version exists; organizations must move to Epicor Kinetic for cloud deployment.
  • UniVerse NoSQL database requires specialized extraction tools and transformation logic not needed for SQL-based ERPs.
  • Character-based green screen interface is dated and creates steep learning curve for new and remote users.
  • Limited analytics and reporting require custom development or third-party tools to achieve modern BI expectations.
  • Custom UniBASIC programs and EDA configurations do not migrate automatically and may require redevelopment.
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. 3 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 Eclipse and Epicor Prophet 21.

  • Object compatibility

    B

    3 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 Eclipse: Rate limiting settings exist on the app server but are not publicly documented by Epicor.

  • Data volume sensitivity

    B

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

Estimator

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

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

Can't find your answer?

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

Book a free 30 minute consultation

Most mid-market Eclipse-to-ERP migrations land between eight and twelve weeks for organizations with up to 100,000 part records, 50,000 customer records, and standard open order and inventory volumes. Migrations with large historical transaction volumes (multiple years of invoice history), complex multi-warehouse inventory structures, active EDI integrations requiring trading partner re-enrollment, or extensive custom UniBASIC program inventory move to fourteen to twenty-two weeks. The sandbox validation phase (step four) is the most common source of timeline compression or extension, depending on reconciliation findings.

Adjacent paths

Related migrations to explore

Ready when you are

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