Migrate from Epicor Eclipse to Microsoft Dynamics 365 Business Central

Eclipse stores customer records in UniVerse file-based dictionaries with dynamic-array address structures (multi-value ship-to and bill-to addresses in a single field). We extract via Eclipse REST API or direct Eterm file parsing, normalize each dynamic-array address into a separate Dynamics 365 address record (DirPartyPostalAddressV2Entity), and map customer-specific pricing tiers and credit limits to Dynamics 365 Customer Group and Credit Limit fields. Customer account number becomes the Dynamics 365 Customer Account Number; we use it as the dedupe key on import.

Vendor records in Eclipse include PO history, rebate terms, EDI capabilities, and multi-value buying codes stored as dynamic arrays. We extract the vendor master, flatten buying code arrays into the Dynamics 365 Vendor group and payment term lookups, and preserve EDI capability flags as custom fields. Terms and classifications map to Dynamics 365 Vendor Group, Payment Term, and Remit-to address structures. Vendor account number is the dedupe key.

Eclipse Part records contain dynamic attributes, substitute/replacement chains, and warehouse-specific stocking data stored as MultiValue fields. We flatten these into Dynamics 365 Product Master records with variant dimensions for size/color/style, extract the substitute chain as a Related Product relationship, and map Eclipse stocking data to InventOnHand per warehouse. User-defined dictionary fields are flagged as candidates for custom fields in Dynamics 365 and noted in the inventory document.

Open orders in Eclipse link customer, part, pricing, and warehouse records through Eclipse's MultiValue join files. We extract order headers and line detail, preserving order-specific discounts and notes, and map to Microsoft Dynamics 365 Sales Order with line-level reservation and delivery date tracking. The customer account and product references are resolved through parent-record lookup before insert to satisfy Dynamics 365 foreign key requirements. Partially shipped lines are flagged for delivery status reconciliation.

PO records include vendor terms, line items, and receiving status. We extract open POs, map to Dynamics 365 Purchase Order with line-level receipt status tracking, and flag partially-received orders that require careful line-level reconciliation. PO confirmations and expected receipt dates migrate as Purchase Order delivery reminders.

Eclipse tracks on-hand, allocated, and on-order quantities per warehouse per part using MultiValue fields (one sub-value per warehouse in a single field). We extract warehouse-level quantities, map bin and location data to Dynamics 365 Warehouse and Location dimension tables, and validate that on-hand values match Eclipse's inventory valuation report at the summary level before marking inventory as reconciled. Lot and serial number records migrate as InventBatch or InventSerial tables.

Eclipse account structures use non-standard numbering and can bundle divisions and cost centers into a single field. We extract the account master, segment the Eclipse account code into the Dynamics 365 Main Account and Financial Dimension structure (configuring Department, Cost Center, and any custom dimensions per the customer's chart design), and map existing balances to the general ledger. Pre-migration trial balance is extracted from Eclipse and inserted as opening balances in Dynamics 365.

Outstanding invoices and vouchers 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 Eclipse's pre-migration AR and AP aging reports. Matured but unpaid invoices are inserted as open transactions in Dynamics 365 Finance with the original invoice date and due date preserved.

Sales history, purchase history, and RMA records spanning 2-5 years are scoped at discovery based on reporting requirements. We extract closed invoices, payments, and credit memos from Eclipse, transform them into Dynamics 365 CustTrans and VendTrans records, and post them as posted transactions (not open). Historical depth is agreed upon upfront because deep history adds significant extraction and insert time. We deliver a written transaction count by year as part of the scope document.

Open quotes migrate in full detail with line items, pricing, and expiration dates. Closed quote history is summarized (quote count, total value, win/loss flag) rather than fully replicated because Dynamics 365 Quotation records are transactional documents with expiration workflows. Quote configuration lines stored as UniBASIC-dependent structures are flagged as candidates for CRM or CPQ rebuild in Dynamics 365.

Tax jurisdiction assignments and rates are tied to customer ship-to locations in Eclipse. We extract the tax code master and associated jurisdiction mappings, then configure the equivalent Tax Codes, Tax Groups, and Tax Settings in Dynamics 365. Any tax calculation logic embedded in custom UniBASIC programs is flagged in the handoff document as requiring a tax engine integration (such as Vertex or Avalara) post-migration.

Eclipse organizations may use cost centers as part of the account structure rather than as standalone entities. We extract department and cost center definitions from Eclipse's account hierarchy or separate department file, configure them as Dynamics 365 Financial Dimensions (typically a custom Department and Cost Center dimension set), and map account segment values to the appropriate dimension values. The customer defines which Eclipse fields map to which Dynamics 365 dimensions during the schema design phase.

Eclipse stores document images and attachments in file repositories accessible via EDA exports or direct file paths. We extract document references and metadata (file name, type, date, associated record), create DocuRef records in Dynamics 365 linking to the migrated attachments stored in Azure Blob or SharePoint, and deliver a file transfer manifest showing which documents are attached to which migrated records. Full document migration requires a separate file transfer engagement if the volume exceeds API insertion practicality.

User records include role assignments, warehouse access, and salesperson links. We extract the user master and map to Dynamics 365 Workers with personnel number, employment status, and warehouse assignment. Salesperson commissions link to CRM Salespersons. Any Eclipse user without a corresponding Active Directory or Entra ID identity is placed in a reconciliation queue for the customer's admin to provision before production migration. Inactive Eclipse users migrate as inactive Workers to preserve historical transaction ownership.