Migrate from iCast to Epicor Prophet 21

iCast customer records with payment terms, credit limits, account managers, and address data map to Epicor Customer (Customer table). We map the iCast customer number to Epicor CustNum as the dedupe key, preserve payment terms in TermsCode, and audit for duplicate customers across iCast's multi-entity database during load. Any custom fields on the iCast Customer record are inventoried and mapped to UD fields on the Customer table or to related ShipTo records depending on the field's purpose.

iCast vendor records including address, payment terms, and account numbers map to Epicor Supplier (Supplier table). We use VendorID as the dedupe key and preserve RemitTo and RemitAddress references separately. Suppliers without a matching Epicor record are flagged for pre-creation before Purchase Order import, because POHeader.VendorNum is a required foreign key that cannot accept nulls during DMT load.

iCast inventory items with SKU, description, unit of measure, cost, and warehouse location map to Epicor Part records. Multi-location inventory maps to PartWhse records with Plant and Warehouse references resolved at load time. Serialized parts require PartBin and PartTran records to be sequenced after Part creation. Unit of measure conversions from iCast's UOM definitions map to UOMClass and UOMConv records in Epicor. We flag any iCast parts with non-standard cost methods (Average, Standard, FIFO) so the Part.CostMethod field is set correctly during import.

Open and historical sales orders from iCast map to Epicor SOHeader with line items going to OTRW. We map iCast order status to Epicor OpenFlag and OrderHed.OpenOrder values, flag held or pending orders for manual review before insert, and resolve CustomerNum references to the newly created Customer records. Pricing from iCast (including any discount codes) migrates to OTRW.UnitPrice with OrderMsc records for miscellaneous charges.

iCast purchase orders map to Epicor POHeader with line items going to POLine. We resolve VendorNum to the Supplier records created during the vendor migration phase. Expected dates, quantities, and line item descriptions map to POLine.PromiseDate, POLine.OrderQty, and POLine.LineDesc respectively. Open POs and closed POs with recent activity are both migrated; fully fulfilled historical POs are optionally migrated as reference records depending on the customer's historical window scope.

iCast's hierarchical chart of accounts with account numbers and types maps to Epicor GLAccount records under the configured COACode. We map account numbers, account types (Asset, Liability, Equity, Revenue, Expense), and any segment structures. Accounts used in transactions but not yet existing in Epicor are flagged for pre-creation before Journal Entry import, because Epicor's GL validation rejects entries referencing non-existent account codes.

General journal entries from iCast including date, account references, debit/credit amounts, and memo fields map to Epicor GLJrnHed and GLJrnDtl records. We resolve account references against the migrated GLAccount table, flag any entries with non-standard account mappings or missing debit/credit balance, and preserve the original iCast journal entry number in GLJrnHed.JournalCode for audit traceability. Entries with reversing periods are handled through Epicor's FiscalPeriod and FiscalYear configuration.

iCast job costing and shop floor records map to Epicor JobHead for the job header and JobOper for each operation step. We map job number, job status, start and due dates, and estimated quantities. Operations sequence from iCast's routing steps into JobOper with Work Centers mapped to Epicor ResourceGroup and Resource records. JobMtl records carry material requirements mapped from iCast's BOM lines. Multi-level job structures require us to sequence parent jobs before child jobs or use Epicor's JobMtl.LowLevelCode to manage explosion at load time.

iCast BOM structures with parent parts, component parts, quantities per assembly, and operations map to Epicor PartMtl (material requirements) and PartOpr (routing operations). We handle single-level and multi-level BOMs by decomposing the iCast BOM hierarchy before loading. PartRev records serve as the revision header in Epicor, linking PartMtl and PartOpr to the part revision level. We flag any iCast BOMs with phantom assemblies or alternate materials so the PartMtl.EstScrapQty and PartMtl.AltMethod flags are set correctly.

iCast user accounts with login credentials, roles, and access permissions map to Epicor User records and associated UserFile entries. We match users by login name and resolve role mappings to Epicor's UserCodes and security assignments. Any iCast roles without a direct Epicor equivalent are flagged in the role reconciliation report for the customer's admin to map to Epicor's security groups post-migration. Inactive iCast users are created as inactive Epicor users to preserve historical assignment data.

iCast stores file attachments on records (orders, parts, jobs, customers). We extract attachments by referencing the parent record in iCast's attachment table, then load them into Epicor as Document records linked via DocumentRef to the corresponding Part, JobHead, Customer, or Supplier. Document metadata (filename, file type, upload date, attached by user) is preserved. Large binary attachments are chunked and uploaded through Epicor's Document Management REST API with rate-limit handling.

iCast custom fields and calculated fields built by the customer are inventoried during discovery across all objects. Each custom field is listed with its data type, object of origin, and current use. We map these to Epicor UD fields on the equivalent standard table (e.g., OrderHed_c for sales order UD fields) and flag any calculated fields that require BPM logic in Epicor to reproduce the computation. Custom reports built in iCast do not migrate; we deliver a written inventory of every saved report with its parameters and filters for manual rebuild in Epicor Advanced Reporting or SSRS.