ERP migration

Migrate from Epicor Eclipse to Infor CloudSuite Corporate

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

Epicor Eclipse logo

Epicor Eclipse

Source

Infor CloudSuite Corporate

Destination

Infor CloudSuite Corporate logo

Compatibility

82%

9 of 11

objects map 1:1 between Epicor Eclipse and Infor CloudSuite Corporate.

Complexity

BStandard

Timeline

6-10 weeks

Rollback included Accuracy guarantee Field-level validation

Overview

What this migration involves

Moving from Epicor Eclipse to Infor Cloudsuite is a MultiValue-to-SQL schema migration, not a standard ETL project. Eclipse stores Customer, Supplier, Parts, Orders, Inventory, and Financial records in Rocket UniVerse file dictionaries with dynamic array fields that require specialized extraction before they can load into Cloudsuite's relational tables. We use Eclipse's REST API endpoints supplemented by direct file access where the API does not cover all required fields, flatten dynamic arrays into normalized columns, and sequence the load through Infor's Migration Utility in dependency order. Multi-warehouse inventory with bin locations, lot/serial tracking, and cross-docking rules require explicit mapping because Eclipse stores warehouse-level quantities per part in multi-value fields that do not map 1:1 to Cloudsuite's inventory structure. Work queues for credit holds, order exceptions, and customer calling queues are documented for Cloudsuite rebuild rather than migrated as code. We do not migrate UniBASIC custom programs, EDA dashboards, or EDI connections; these require separate planning with the customer's integration team and trading partners.

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

Infor CloudSuite Corporate logo

Infor CloudSuite Corporate

What's pulling them in

  • Infor CloudSuite is industry-specific out of the box — manufacturing, distribution, healthcare, and food & beverage editions ship with preconfigured workflows that reduce the need for extensive customization and accelerate time to value for operations-heavy organizations.
  • The platform's deep integration with Excel for financial reporting is frequently cited as a key productivity feature, allowing finance teams to pull data directly and make changes without leaving familiar tooling.
  • AWS-hosted multi-tenant deployment eliminates data center management for IT teams, and Infor OS provides a unified integration layer (ION) that connects the CloudSuite to third-party applications without point-to-point middleware.
  • Organizations with multi-site or multi-country operations choose Infor for its multicurrency, multilanguage, and local regulatory compliance capabilities across 175+ countries, which simplifies consolidation for global CFOs.
  • The two-tier ERP strategy positioning lets corporate headquarters run CloudSuite while subsidiaries run lighter instances, which appeals to complex organizational structures that want standardization without full replacement.

Object mapping

How Epicor Eclipse objects map to Infor CloudSuite Corporate

Each row shows how a Epicor Eclipse object lands in Infor CloudSuite Corporate, 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 (Customer Master)

maps to

Infor CloudSuite Corporate

Customer / Party

1:1
Fully supported

Eclipse Customer records (CUSTOMER file) with ID, name, credit limit, terms, and price class map to Infor Cloudsuite Customer (Distribution) or Party (Industrial) records. Eclipse ship-to addresses (SHIP.TO) with location-specific tax jurisdictions map to Infor Customer Ship-to addresses. We extract customer-specific pricing classes, discount schedules, and credit hold status from Eclipse and flag any pricing rules that require manual rebuild in Infor's pricing engine.

Epicor Eclipse

SUPPLIER (Vendor Master)

maps to

Infor CloudSuite Corporate

Supplier / Vendor

1:1
Fully supported

Eclipse Vendor records include PO history, rebate terms, EDI capabilities, and buying codes stored as multi-value fields. We extract the vendor master, transform multi-value buying codes into normalized vendor item cross-reference records in Infor, and preserve terms, classifications, and EDI setup flags. Any vendor-specific rebate accrual balances (SPA, SPJ, rebate claim history) require explicit mapping because Eclipse stores these in separate files that may not be covered by standard Eclipse API endpoints.

Epicor Eclipse

PRODUCT (Product Master)

maps to

Infor CloudSuite Corporate

Item / Product

1:1
Fully supported

Eclipse PRODUCT records contain item ID, description, product group, UOM definitions, and extended attributes stored as dynamic arrays. We flatten dynamic array attributes into Infor Item custom fields, preserving product group hierarchy and UOM conversion definitions. Substitute and replacement part chains from Eclipse's product cross-reference files map to Infor's alternate item relationships. IDW (Industry Data Warehouse) attributes, if used, are extracted as extended item attributes.

Epicor Eclipse

INVENTORY (Warehouse Quantities)

maps to

Infor CloudSuite Corporate

Inventory On Hand / Stock

1:many
Fully supported

Eclipse stores on-hand, allocated, and on-order quantities per warehouse per part using multi-value fields in the INVENTORY file. We split these into Infor warehouse-specific inventory records with bin location, lot/serial tracking, and ranking data extracted from Eclipse's bin location structures. Multi-warehouse operations require branch-level inventory reconciliation because Eclipse may hold different quantities per branch with inter-branch transfer rules that map to Infor's transfer order logic.

Epicor Eclipse

ORDERS (Open Sales Orders)

maps to

Infor CloudSuite Corporate

Sales Order

1:1
Fully supported

Eclipse Order records with headers, line items, pricing, warehouse assignments, and customer references map to Infor Sales Orders. We extract order-specific discounts, notes, and allocation status, preserving the line-level relationship to the source customer and part records. Partially-shipped orders require careful line-level status mapping because Eclipse tracks shipment history that may affect order completeness flags in Infor.

Epicor Eclipse

PURCHASE.ORDERS (Open Purchase Orders)

maps to

Infor CloudSuite Corporate

Purchase Order

1:1
Fully supported

Eclipse PO records include vendor terms, line items, and receiving status. We extract open POs, map them to Infor Purchase Orders, and flag partially-received orders that require line-level migration because Infor tracks received quantities against PO lines and Eclipse tracks receipt history in separate files. Vendor drop-ship flags and special handling codes require explicit mapping to Infor PO terms.

Epicor Eclipse

COA (Chart of Accounts)

maps to

Infor CloudSuite Corporate

Account / GL Account

lossy
Fully supported

Eclipse account structures use non-standard numbering and may encode divisions and cost centers in the same field. We extract account masters, segment them per Infor's GL account structure (which typically separates company, division, department, and account), and map existing Eclipse account numbers to the Infor hierarchy. Any cost center logic embedded in Eclipse account numbers requires analysis during scoping to determine whether cost centers become separate Infor cost center entities or remain part of the GL segment.

Epicor Eclipse

Open AR / Open AP

maps to

Infor CloudSuite Corporate

Receivables / Payables

1:1
Fully supported

Eclipse 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 against Infor's AR/AP aging reports post-migration. Customer credit holds from Eclipse must map to Infor credit limit and hold rules that are configured separately from the data migration.

Epicor Eclipse

QUOTE (Quote / Estimate)

maps to

Infor CloudSuite Corporate

Quote

1:1
Fully supported

Open quotes in Eclipse with full line detail migrate to Infor Quotes. Eclipse stores quote configurations and special pricing agreements at the quote line level, which we map to Infor quote line pricing with manual verification of pricing engine results post-load. Closed quote statistics migrate as summary records if scoped by the customer; quote history is typically not migrated in full because of cost-benefit tradeoffs.

Epicor Eclipse

Work Queue Configurations

maps to

Infor CloudSuite Corporate

Role-Based Assignments / Workflows

1:1
Fully supported

Eclipse self-populating work queues (credit hold queue, order exception queue, warehouse-in-process status queue, customer calling queue) are tightly coupled to Eclipse's hot-key interface and user assignment logic. These queues do not have a direct Infor equivalent and do not migrate as functional code. We document the active queue configurations, assignment rules, and escalation logic during scoping and deliver a written inventory for the customer's Infor admin to rebuild using Infor OS workflow tools.

Epicor Eclipse

Documents / Attachments

maps to

Infor CloudSuite Corporate

Infor Document Management (IDM)

1:1
Mapping required

Eclipse stores document images, attachments, and proof-of-delivery scans in file repositories outside the database. We extract document references and metadata, mapping file paths to Infor Document Management (IDM) storage locations. The actual document files require separate file transfer rather than API insertion. Document imaging and signature capture configurations do not migrate and require separate replacement planning.

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

Infor CloudSuite Corporate logo

Infor CloudSuite Corporate gotchas

High

Infor OS tier-based usage limits gate API and BaaS capabilities

Medium

Custom Fields use inconsistent naming across Infor editions

Medium

SQL migration utility requires source database access

Medium

Multi-site and multi-currency data require separate period closure sequencing

Low

REST API payload and timeout limits restrict bulk migration throughput

Pair-specific challenges

  • UniVerse MultiValue extraction requires non-standard tools

    Eclipse runs on Rocket UniVerse with file-based storage, PICK BASIC programming, and dynamic arrays that do not map directly to SQL columns. Standard SQL connectors cannot read Eclipse data. We use Eclipse's REST API (.NET Core engine on port 5000) where endpoints cover required fields, supplemented by direct UniVerse RetrieVe queries and UniBASIC extraction programs for data in user-defined dictionary fields. Eclipse CSV export via Mass Load utility covers products, customers, pricing, and transactions for simpler migrations. We flag any data locked in custom UniBASIC programs or deprecated EDA configurations that require manual extraction before the migration window.

  • Infor Migration Utility requires SQL Server on the source

    Infor Cloudsuite's Migration Utility accepts source data from SQL Server 2008 or later. Eclipse's UniVerse database is not SQL Server. We solve this by extracting Eclipse data first into an intermediate SQL Server staging database (which we provision and populate), then running the Infor Migration Utility against that staging database. This adds an extraction-transformation stage not present in SQL-to-SQL migrations. The intermediate staging layer must be validated for data types, lengths, and null handling before the Infor Migration Utility sequences begin.

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

    Eclipse Quote-to-Invoice workflows (Quote → Order → Job → Material → Labor → Shipment → Invoice → Financials) are tightly linked, and Infor Cloudsuite has a different workflow engine. We run full end-to-end test scenarios post-migration, validating that each stage connects correctly to the next: that Infor Sales Orders generate the correct Purchase Requisitions, that warehouse picks flow to shipment, that invoices post to the correct GL accounts, and that financial totals match Eclipse balances. Skipping this validation step before cutover risks discovering broken workflow chains during production operation.

  • Multi-branch inventory reconciliation is complex

    Eclipse supports multi-branch operations where each branch may have unique product assortments, pricing variations, inventory locations, and inter-branch transfer rules. These are stored as branch-specific records in the INVENTORY, CUSTOMER, and pricing files. We extract branch definitions, map branch-level inventory quantities to Infor warehouse records, and flag any inter-branch transfer logic that requires manual configuration in Infor's warehouse management or distribution modules. Inconsistent branch configurations accumulated over years of Eclipse operation must be cleansed before migration or they propagate to Infor.

  • EDI connections require vendor and trading partner re-enrollment

    Most Eclipse EDI connections (850, 810, 856, 867 transaction sets) are configured at the Eclipse level with trading partner IDs and communication settings. These do not migrate to Infor Cloudsuite and require re-enrollment with each trading partner. We identify all EDI endpoints during scoping, document the current Eclipse EDI configuration (partner IDs, transaction sets, acknowledgment settings), and deliver an EDI re-enrollment checklist. Trading partner re-enrollment timelines vary from two weeks to three months depending on partner responsiveness and must be planned in parallel with the Infor implementation.

Migration approach

Six steps for a successful Epicor Eclipse to Infor CloudSuite Corporate data migration

  1. Discovery and Eclipse environment documentation

    We audit the Eclipse environment including version (9.x series), Solar Eclipse GUI usage, modules licensed and actively used (Counter/POS, Inventory, Purchasing, Financials, Job Management, EDA, EDI, Mobile), and concurrent user count. We inventory all Eclipse file dictionaries (PRODUCT, INVENTORY, CUSTOMER, SHIP.TO, CONTACT, VENDOR, ORDERS, etc.), map active integration endpoints (EDI, Commerce Connect, RF devices, proof of delivery, VsiFax), and document custom UniBASIC programs and EDA configurations. This output is a written Eclipse data inventory and a recommendation on extraction method (REST API, CSV export, or direct UniVerse access) per data domain.

  2. SQL Server staging layer provisioning and extraction

    We provision a SQL Server 2008+ staging database and build extraction pipelines from Eclipse. For data covered by Eclipse REST API endpoints, we use session-based authentication (sessionToken/refreshToken) with rate-limit handling. For data requiring direct UniVerse access, we use RetrieVe queries or UniBASIC extraction programs. For bulk export of products, customers, and pricing, we use Eclipse CSV export via Mass Load utility. All extractions run off-peak and produce record-count summaries validated against Eclipse reports. The staging layer is structured to match the Infor Migration Utility's expected source schema, with dynamic array fields flattened into normalized columns.

  3. Infor Cloudsuite schema design and Migration Utility setup

    We work with the customer's Infor implementation team to configure the Infor Migration Utility pack in a non-production environment. This includes defining Import Source Tables (from the SQL Server staging layer), Import Target Tables (Infor Cloudsuite tables), and Import Steps (the sequencing of table loads with dependency awareness). We map Eclipse CUSTOMER to Infor Customer, PRODUCT to Item, INVENTORY to Inventory On Hand, ORDERS to Sales Order, and so on, using Infor's preconfigured mappings as a starting point and adding custom mappings for Eclipse-specific fields. Branch-specific configurations are mapped to Infor site or warehouse entities.

  4. Data quality assessment and cleansing

    Eclipse installations accumulate data quality issues over years of operation. We run a Data Assessment Report through the Infor Migration Utility to identify duplicate records, missing required fields, invalid references, and inconsistent UOM configurations. We cleanse the staging layer before migration, flagging duplicates for customer decision (merge vs. keep both), correcting address structures, marking obsolete products as inactive, and resolving orphaned records. Historical data scoping is confirmed at this stage: which years of sales history, which invoice ranges, and which archived document metadata are in scope.

  5. Sandbox migration and reconciliation

    We execute a full migration into an Infor Cloudsuite sandbox using production-like data volumes from the staging layer. The customer reconciles record counts (customers in, vendors in, parts in, orders in, inventory quantities by warehouse) against Eclipse reports, spot-checks 25-50 records per object for field-level accuracy, and validates financial totals (AR aging, AP aging, GL account balances). Work queue and workflow configurations are reviewed against the written inventory. Any mapping corrections are documented and the migration script is updated before production migration begins.

  6. Production migration, cutover, and validation

    We freeze Eclipse writes during cutover, run a final delta extraction of any records modified during the migration window, and execute the production migration using the validated scripts. Migration runs in dependency order: master data first (customers, vendors, items, chart of accounts, tax codes), then open transactions (orders, POs, quotes), then inventory, then financial balances (AR/AP open items), then historical transactions if scoped. Each phase emits a row-count reconciliation report before the next phase begins. We validate the Quote-to-Invoice workflow chain end-to-end post-load and deliver the work queue and EDI re-enrollment inventory to the customer's Infor admin team for rebuild planning.

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.
Infor CloudSuite Corporate logo

Infor CloudSuite Corporate

Destination

Strengths

  • Industry-specific preconfiguration across manufacturing, distribution, healthcare, and food & beverage reduces post-implementation customization effort.
  • Deep Excel integration for financial reporting allows finance teams to export, manipulate, and push data back without leaving a familiar environment.
  • Multi-tenant AWS deployment with Infor OS provides a unified integration layer that simplifies connecting to third-party applications and legacy systems.
  • Strong multicurrency, multilanguage, and regulatory localization capabilities support organizations operating across 175+ countries from a single platform.
  • Modular architecture allows organizations to deploy core financials, supply chain, or manufacturing modules independently and expand over time.

Weaknesses

  • Opaque pricing model with no public per-user rates and deployments commonly ranging from $500K to $5M creates significant budget uncertainty for prospective buyers.
  • Implementation complexity and timeline (commonly 2+ years for large deployments) leads to extended periods of reduced productivity and elevated project risk.
  • Steep learning curve with hidden options and a lack of public setup guidance makes self-service onboarding difficult compared to competitors with richer documentation communities.
  • Manufacturing module functionality is perceived by some users as outdated relative to modern ERP platforms, with reported bug issues that require workarounds.
  • Tight coupling between modules and environment-specific configurations makes migration to non-Infor systems labor-intensive, increasing switching costs.

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 Infor CloudSuite Corporate.

  • 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 Infor CloudSuite Corporate 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 Infor CloudSuite Corporate data migrations

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

Can't find your answer?

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

Book a free 30 minute consultation

Most single-site migrations land between six and ten weeks for environments under 50,000 parts, 10,000 customers, and 5,000 open orders with straightforward pricing structures. Multi-branch, multi-warehouse migrations with complex vendor rebate agreements, branch-specific pricing, or large historical transaction sets (over 500,000 invoices) move to fourteen to twenty weeks because of dynamic array transformation, branch-level reconciliation, and Infor Migration Utility sequencing. EDI re-enrollment with trading partners runs in parallel but can extend the overall project timeline depending on partner responsiveness.

Adjacent paths

Related migrations to explore

Ready when you are

Move from Epicor Eclipse.
Land in Infor CloudSuite Corporate, 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