Migrate from NetSuite to Epicor Prophet 21

NetSuite Accounts (chart of accounts records identified by account type codes and optionally acctNumber) map to Epicor GL Account segments. NetSuite account types (0=Bank, 1=AR, 2=Inventory, 10=AP, 21=Income, 23=COGS, 24=Expense) map to Epicor COA segment values under the configured account structure. We preserve full account number, name, and type. Epicor's account segment structure requires mapping NetSuite's flat account list into Epicor's segmented account format (typically Company-Branch-Natural Account or equivalent per the customer's Epicor COA configuration). The mapping is defined during discovery against the customer's Epicor Chart of Accounts structure.

NetSuite Customers map directly to Epicor Customer records. The NetSuite entity ID becomes the Epicor CustID, and the customer name, address, contact information, credit terms, and tax registration migrate to Epicor Customer and CustShip records. NetSuite Customer fields like creditlimit, terms, and region map to Epicor Customer.CreditHold, Customer.TermsCode, and Customer.SalesRepID. Multi-address NetSuite customers map to multiple Epicor CustShip records linked to a single Customer.

NetSuite Vendors map to Epicor Vendor records. NetSuite entity ID becomes Epicor Vendor.VendorID, and standard fields (name, address, contact, payment terms, 1099 flag) migrate to equivalent Epicor Vendor fields. Tax ID from NetSuite maps to Vendor.TaxID for US 1099 reporting. Multi-address vendors map to multiple Epicor VendRemitTo or VendorPP records.

NetSuite's subsidiary model lets one database represent multiple legal entities with intercompany eliminations. This is the most structurally significant mapping decision in a NetSuite-to-Epicor migration. Epicor does not support a single-database multi-entity model with automatic intercompany eliminations. Each NetSuite subsidiary must map to a distinct Epicor Company, and intercompany transactions must be reclassified as standard journal entries, internal sales orders, or an external consolidation strategy. We build the subsidiary-to-company map during discovery, validate posting group assignments in Epicor before data lands, and present the intercompany treatment options (eliminate, keep as-is, consolidate manually) as a decision point documented in the migration contract.

NetSuite Items (inventory assembly, non-inventory, service, description-only) map to Epicor Part records with PartPlant configuration for inventory-specific settings. The NetSuite item type maps to Epicor Part.TypeCode (MFG, PHant, PKG, etc.). Unit of measure from NetSuite maps to Epicor Part.IUM and Part.DUM. Pricing matrices migrate to Epicor Part.PriceList or OrderDtl base pricing. Build assemblies, BOM relationships, and landed cost fields require mapping to Epicor's engineering and costing modules during the BOM mapping phase.

NetSuite Bill of Materials on assembly items map to Epicor Engineering BOM (EBOM) and ECO (Engineering Change Order) structures. NetSuite work orders map to Epicor Job records with JobMtl (materials) and JobOper (operations/routing) entries. This is the highest-complexity manufacturing mapping because NetSuite nests BOMs under assembly items while Epicor manages BOMs as separate Engineering records linked to Part numbers. Routing steps (NetSuite manufacturing routing) map to Epicor JobOper with work center references. We recommend scoping BOM and work order migration only for active or recent records; historical completed work orders typically convert to job cost history without full reconstruction.

NetSuite Sales Orders and Invoices map to Epicor OrderHed and OrderDtl records. NetSuite transaction body fields (tranDate, memo, externalId) map to Epicor OrderHed.OrderDate, OrderHed.CustomerRF, and OrderHed.XrefOrderNum. Line-level item, quantity, rate, and tax information map to OrderDtl. NetSuite's billing address and shipping address on the transaction map to Epicor OrderHed.BTCustomer and OrderHed.STCustomer with separate ship-to logic. Closed vs open status determines whether records are migrated as closed orders or open invoices requiring subsequent billing action.

NetSuite Purchase Orders map to Epicor POHeader and POLine records. NetSuite Bills (vendor invoices) map to Epicor AP Invoice records. POHeader fields (vendor, terms, ship via) migrate to Epicor equivalents; line-level items, quantities, and costs map to POLine. NetSuite's expensereport and vendor bill payments map to Epicor's AP application workflow. Open POs migrate as open records; closed POs migrate as historical records.

Outstanding receivables and payables must be migrated as open balances rather than replayed as historical transactions. We extract open invoice amounts, due dates, aging buckets, and payment terms from NetSuite and create Epicor AR Invoice or AP Invoice records in open status. NetSuite AR aging buckets map to Epicor's receivables aging report structure. This mapping requires careful sequencing because customer and vendor records must be fully validated in Epicor before open invoice creation.

NetSuite Journal Entries map to Epicor GL Journal records with line-level debit and credit entries. Historical journal entries require strict sequencing because prior-period adjustments and intercompany eliminations carry original posting dates and exchange rates that must be preserved. Some organizations prefer to carry forward open period balances only (creating fresh journal entries in Epicor rather than replaying historical rows), which is a scoping decision made during discovery. NetSuite currency revaluation journal entries map to Epicor's currency revaluation process output.

NetSuite lot and serial numbers assigned at transaction time are tracked in inventory records and tracked via the inventoryDetail subrecord. Epicor manages lot numbers through the PartLot table and serial numbers through PartSerialNo, with movements tracked via PartTran. NetSuite's lot/serial assignment at item fulfillment maps to Epicor's PartTran entries with the same lot number and transaction date. We preserve lot expiry dates, bin locations, and quantity per lot across the migration. UD Codes for lot classification migrate as Epicor UD Codes attached to PartLot records.

NetSuite Custom Record Types (custrecord_* script IDs) are user-defined record types with custom fields that do not exist in a standard schema. Every NetSuite environment has a unique set of custom record types. We run a metadata discovery pass against the account's SuiteQL endpoint to enumerate all active custom record types before building the migration map. Each custom record type maps to an Epicor UD Table (user-defined table) with equivalent fields. Custom fields on custom record lines (custcol_*) require mapping to UD column definitions in Epicor. Custom record instances migrate as rows in the Epicor UD Table.

NetSuite Employee records map to Epicor Employee records with fields for name, address, department, and employment status. NetSuite's time tracking data (timesheets, time entries) maps to Epicor's Labor collection if the customer uses Epicor MES or Kinetic shop floor module. Compensation history, PTO balances, and benefits enrollment data migrate as Epicor HR records or are flagged for manual entry depending on the Epicor HR module scope in the customer's license.

NetSuite project records (from SuitePeople PSA) include billing records, time entries, resource allocations, and milestones. Project financials must be separated from standard G/L transactions. NetSuite Projects map to Epicor Project (Phase-Project hierarchy) or Job records depending on the customer's Epicor license scope. Revenue recognition, billing schedules, and project WIP mapping depend on whether the customer uses Epicor's Project Billing or Kinetic PSA module.

NetSuite attaches custom fields to nearly every standard object using custbody_*, custcol_*, custentity_*, and custitem_* prefixes. These must be discovered per-entity via SuiteQL before migration because no public documentation enumerates a given account's active custom field set. Each discovered custom field maps to an Epicor UD field on the equivalent table. Custom fields on transaction lines (custcol_*) require Epicor UD columns on the line table (OrderDtl, POLine, etc.) rather than the header table. We pre-create all Epicor UD fields in the target Epicor environment during the schema design phase before any data load begins.

NetSuite tax codes define nexus, rates, and filing jurisdictions and are referenced by internalId on transaction lines. We preserve the full tax code registry and map nexus assignments to Epicor TaxConnect jurisdictions or manual tax code definitions. NetSuite multi-country tax codes (VAT, GST) map to Epicor equivalent jurisdiction codes. Tax rate tables migrate to Epicor's tax rate definitions with effective dates preserved.

NetSuite File Cabinet documents attached to records (via the documents tab or file upload) are extracted with file metadata and content. Large file transfers are chunked and retried under NetSuite API rate limit constraints. Documents migrate to Epicor Document Management (EDM) or the Kinetic Document vault, linked to the equivalent Epicor record by primary key. We do not migrate the full NetSuite file cabinet structure as a file system; we migrate documents associated with specific migrated records.