ERP migration
Field-level mapping, validation, and rollback between Epicor Eclipse and Acumatica. We move data and schema; workflows are rebuilt natively in Acumatica.
Epicor Eclipse
Source
Acumatica
Destination
Compatibility
12 of 12
objects map 1:1 between Epicor Eclipse and Acumatica.
Complexity
BStandard
Timeline
4–8 weeks
Overview
Epicor Eclipse runs on a Rocket UniVerse (MultiValue/NoSQL) database with file-based storage and dynamic arrays — an architecture fundamentally different from Acumatica's relational SQL schema. The migration must therefore go through an intermediate transformation layer: Eclipse data is extracted via its REST API (session-based auth, default port 5000) or direct file export, normalized into a relational structure, then loaded into Acumatica's Customers, Vendors, Stock Items, Sales Orders, and Projects screens. The most complex translation is Eclipse's SPA (Selling Price Adjustment) and SPJ (Selling Price Job) price matrices, which Acumatica models through Customer Price Classes, Availability Rules, and Distribution categories. We carry over all standard master records (customers, vendors, parts with bin/lot/serial data, open and closed sales orders, and GL account mappings) plus any Eclipse custom fields as Acumatica custom fields. Workflows, work queues, counter/POS automation, EDI configurations, and custom UniBASIC programs do not migrate — these must be rebuilt in Acumatica's automation framework and the EDI module post-migration. FlitStack sequences the migration so foreign keys (customer before orders, part before inventory) resolve in the correct order, runs a sample migration with a field-level diff, then executes a delta-pickup window (24–48 hours) to capture any in-flight changes during cutover.
Every standard and custom field arrives verified.
AI proposes the map; you confirm before any record moves.
Parent–child, lookups, and ownership stay linked.
Calls, emails, meetings — with original timestamps.
Documents, uploads, and inline notes move with the record.
Why teams make this switch
Leaving
What's pushing teams away
Choosing
What's pulling them in
Object mapping
Each row shows how a Epicor Eclipse object lands in Acumatica, 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
Acumatica
Customer
1:1Direct map from Eclipse Customer file to Acumatica Customers. Eclipse stores billing address, shipping address, and contact details in sub-values of dynamic arrays — we split these into Acumatica's address tabs and contact records. CustomerClassId maps from Eclipse's customer type code to Acumatica's Customer Class for AR terms and tax settings.
Epicor Eclipse
Vendor
Acumatica
Vendor
1:1Direct map from Eclipse Vendor file to Acumatica Vendors. Eclipse's vendor sub-agent files (for rebate programs) do not have a direct Acumatica equivalent — rebate program logic migrates as Vendor Rebate records in Acumatica's Vendors > Rebates tab, with effective dates and volume thresholds preserved as notes for manual verification.
Epicor Eclipse
Part / Product
Acumatica
Stock Item / Non-Stock Item
1:1Eclipse's Parts file holds both inventory and non-stocked items in one file with a stocking-type flag. We split this on migration: stocked parts map to Acumatica Stock Items with Volume and Weight, lot/serial class, and warehouse allocation; non-stocked parts map to Non-Stock Items with the same descriptive fields. The Eclipse PartClassCode becomes the Acumatica ProductManagerID (for reporting) and a custom ProductClass__c field.
Epicor Eclipse
Sales Order
Acumatica
Sales Order
1:1Direct map of open Eclipse sales orders to Acumatica Sales Orders. OrderTypeId maps from Eclipse's order type code (e.g., SO, CM) to Acumatica's Order Types configured per warehouse. Line items reference migrated Stock Item IDs via the Eclipse PartNum. Pending and on-hold orders carry their status in a custom Eclipse_Status__c field.
Epicor Eclipse
Purchase Order
Acumatica
Purchase Order
1:1Direct map of open Eclipse purchase orders to Acumatica Purchase Orders. VendorID resolves via email match to Acumatica vendor records. Drop-ship and special-order flags in Eclipse PO sub-values become Acumatica PO line type settings. Closed POs migrate as historical records linked to the vendor account for reference only.
Epicor Eclipse
SPA Price Matrix
Acumatica
Customer Price Class + Sales Price
1:1Eclipse SPA (Selling Price Adjustment) matrices — customer-specific pricing, quantity breaks, and promotional rules — are the most complex translation. Each Eclipse SPA rule becomes either an Acumatica Customer Price Class assignment or individual Sales Price records per Stock Item. Quantity-break tiers map to Sales Price break quantities. Where Eclipse stores effective-date ranges, we create date-specific Sales Price records.
Epicor Eclipse
SPJ Price Matrix
Acumatica
Non-Stock Item Price + Sales Price
1:1Eclipse SPJ (Selling Price Job) pricing applies to job/project-based work. We translate these to Acumatica Non-Stock Item prices linked to Project tasks, or to Sales Price records scoped to the specific Project. Labor and overhead cost codes from Eclipse become Acumatica Labor Item and Non-Stock Item records with cost/price pairs.
Epicor Eclipse
Warehouse / Bin
Acumatica
Warehouse + Location
1:1Eclipse warehouse codes and bin locations map directly to Acumatica Warehouses and Location records. Multi-bin setups per warehouse become separate Location records with the Eclipse bin code as LocationCD. Branch-specific inventory quantities aggregate by warehouse in Acumatica's Inventory sub-module. If Eclipse tracks lot or serial numbers at the bin level, those attributes are preserved in Acumatica's Lot/Serial Class and linked to the corresponding Location, ensuring traceability across warehouses.
Epicor Eclipse
GL Account
Acumatica
Account
1:1Eclipse GL account numbers map to Acumatica Account records with the same account code. Eclipse's sub-account structure (division/department segments) maps to Acumatica's Subaccount dimension using the Segment Code framework. The chart of accounts is migrated before all transaction records so line items resolve correctly.
Epicor Eclipse
Quote
Acumatica
Sales Quote
1:1Open Eclipse quotes (QuoteMstr and QuoteDtl files) map to Acumatica Sales Quotes with the same customer, line items, and pricing as the SPA translation above. Expired quotes migrate with a Quote_Expired__c custom flag and ExpirationDate preserved for reference. Quote attachments (PDFs stored in Eclipse's document imaging module) are re-uploaded to Acumatica Files.
Epicor Eclipse
Rebate Program
Acumatica
Vendor Rebate
1:1Eclipse rebate claim history and program definitions do not have a 1:1 Acumatica equivalent. We migrate the rebate records as Vendor Rebate entries (Vendors > Rebates tab) with program details in a Rebate_Program_Details__c custom long-text field for your AP team to configure properly in Acumatica.
Epicor Eclipse
Counter / POS Work Queue
Acumatica
Sales Order + Custom Screen
1:1Eclipse counter/POS workflows and work queue automation have no Acumatica equivalent — these are destination-side operational processes that must be redesigned. FlitStack exports the Eclipse work queue definitions as a reference document for your Acumatica implementation team. To rebuild, your team should define order‑hold rules, create custom screens for counter entry, and use Acumatica's Automation Engine for queue notifications. The exported reference includes field mappings and suggested UI layouts.
| Epicor Eclipse | Acumatica | Compatibility | |
|---|---|---|---|
| Customer | Customer1:1 | Fully supported | |
| Vendor | Vendor1:1 | Fully supported | |
| Part / Product | Stock Item / Non-Stock Item1:1 | Fully supported | |
| Sales Order | Sales Order1:1 | Fully supported | |
| Purchase Order | Purchase Order1:1 | Fully supported | |
| SPA Price Matrix | Customer Price Class + Sales Price1:1 | Fully supported | |
| SPJ Price Matrix | Non-Stock Item Price + Sales Price1:1 | Fully supported | |
| Warehouse / Bin | Warehouse + Location1:1 | Fully supported | |
| GL Account | Account1:1 | Fully supported | |
| Quote | Sales Quote1:1 | Fully supported | |
| Rebate Program | Vendor Rebate1:1 | Fully supported | |
| Counter / POS Work Queue | Sales Order + Custom Screen1:1 | Fully supported |
Gotchas + challenges
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 gotchas
UniVerse MultiValue extraction requires non-standard tools
Performance degradation post-Kinetic migration
End-to-end workflow must be validated as a chain
Historical data scoping determines migration cost
Integration connections require separate migration planning
Acumatica gotchas
API user licenses cap concurrent sessions and request throughput
Multi-tenant filtering requires CompanyID awareness
Custom fields require separate discovery before field mapping
Notes and attachments use a separate linked table structure
Implementation timelines frequently run 3–9 months end-to-end
Pair-specific challenges
Migration approach
Extract Eclipse master data via REST API or file export
FlitStack connects to Epicor Eclipse using its REST API (session-based authentication, port 5000) or direct UniVerse file export for environments without API access. We extract all master records — Customers, Vendors, Parts, Warehouses, GL Accounts, open Sales Orders, open Purchase Orders, and Quotes — in their native dynamic-array format. For each file, we document the field positions, delimiter conventions, and any multi-value sub-field structures before writing the normalization scripts. Eclipse does not automatically purge historical data, so closed orders and AR/AP history are available for scoped migration.
Normalize UniVerse arrays and build Acumatica field mapping
Each Eclipse file's dynamic arrays are parsed into a normalized intermediate format — customer addresses become separate Address records, SPA pricing rules become individual price adjustment rows, and GL sub-account segments become Sub records linked to the Account. We build the Eclipse-to-Acumatica field map covering all standard fields plus any Eclipse custom fields (tracked in the Eclipse Configuration worksheet). Custom fields migrate as Acumatica custom fields (custom FieldName__c) with data type preserved. Parent-before-child sequencing is enforced: GL Accounts before Transactions, Customers before Orders, Parts before Inventory.
Translate SPA/SPJ pricing rules into Acumatica price entities
This is the most complex step. Each Eclipse SPA rule is analyzed for scope (customer, product class, quantity break, effective date range) and translated into either an Acumatica Customer Price Class assignment or individual Sales Price records. SPJ (job/project pricing) rules map to Non-Stock Item Sales Prices scoped to Project tasks. We generate a pricing translation summary showing how many Sales Price records will be created per customer so your team can validate price accuracy before the full run. Quantity-break tiers become Sales Price BreakQty values; date-effective promotions become Sales Price records with StartDate and EndDate.
Run sample migration with field-level diff
A representative slice migrates first — typically 500–1,000 records covering a sample customer with full address history, 200 parts spanning stocked/non-stocked/lot-controlled, 50 open orders, and a representative SPA pricing set. We generate a field-level diff between Eclipse source values and Acumatica destination values so you can verify customer address parsing, pricing rule translation, lot/serial number mapping, and GL account resolution. Sample migration results are reviewed and signed off before the full run proceeds.
Execute full migration with delta-pickup window
The full migration loads all validated master records, transaction records, and historical data into Acumatica. A delta-pickup window (typically 24–48 hours) runs after the initial load to capture any orders, shipments, or receipts created in Eclipse during the cutover period. Audit logs record every insert and update operation. If reconciliation reveals discrepancies — a missing order line, a pricing exception not translated — one-click rollback is available to restore Acumatica to its pre-migration state while the issue is resolved.
Platform deep dives
Epicor Eclipse
Source
Strengths
Weaknesses
Acumatica
Destination
Strengths
Weaknesses
Complexity grading
Standard ERP migration. 3 of 8 objects need a mapping; the rest are 1:1.
Overall complexity
Standard migration
Derived from compatibility, mapping clarity, API constraints, and data volume across Epicor Eclipse and Acumatica.
Object compatibility
3 of 8 objects need a mapping; the rest are 1:1.
Field mapping clarity
Field mapping is derived from defaults — final spec confirmed during the sample migration.
Timeline complexity
8-object category — typical timelines run 2–7 days end-to-end.
API constraints
Epicor Eclipse: Rate limiting settings exist on the app server but are not publicly documented by Epicor.
Data volume sensitivity
Epicor Eclipse doesn't expose a bulk API — REST + parallelization used for high-volume runs.
Estimator
Rule-based pricing — no per-record fees, no manual quotes. Migrations over 2M records are scoped individually.
Step 1
Pick a category, then your source and destination platforms.
Category
FAQ
Answers to the questions buyers ask most during Epicor Eclipse to Acumatica migration scoping. Not seeing yours? Book a call.
Walk through your Epicor Eclipse to Acumatica migration with a real engineer — 30 minutes, free, written quote within 24 hours.
Book a free 30 minute consultationAdjacent paths
Other ways to leave Epicor Eclipse
Other ways to arrive at Acumatica
Ready when you are
Tell us record counts and timeline. We'll come back with a written quote inside 1 business day — no commitment, no sales pitch.
