Migrate from Atlas ERP to Epicor Prophet 21

Atlas stores the Chart of Accounts as a flat or hierarchical table in MS SQL with account codes, names, types, and optional cost-center linkage. We extract the full account tree via direct SQL read, preserving parent-child hierarchy, and create corresponding GL AccountMaster records in Epicor with the same account structure. Account codes are mapped 1:1 where possible; if the customer has a non-standard Atlas coding scheme, we apply a code-remapping table during the transform phase before Epicor insert.

Atlas uses a self-referential company table where parent_company_id points to the holding entity. We walk this tree recursively during extraction to identify all subsidiaries and the holding node. In Epicor, we create Company records (for the legal entity) and Plant records (for operating locations) in parent-first order to satisfy foreign-key constraints. Inter-company GL posting settings in Epicor are configured based on the Atlas inter-company transaction flags discovered during schema inspection.

Atlas Warehouses are master-data records with warehouse_id, name, address, and optional cost-center linkage. We export them as-is and create corresponding Warehse records in Epicor, mapping the Atlas warehouse_id to Epicor's WarehseID and the name to WarehseName. If the Atlas warehouse has bin or location sub-records, we also create WhseBin entries in Epicor for the warehouse location hierarchy.

Atlas Items are product master records with type (stock item, service, non-stock), unit of measure, costing method, and optional site linkage. We extract the part master and map Atlas item_type to Epicor PartType (stock item becomes Stock, non-stock becomes Non-Stock, service becomes Service). PartNumber maps directly from Atlas item_code. Unit of measure from Atlas uom_code maps to Epicor IUM and SalesUM.

Atlas BOM lines live in a separate bom_lines table linked by item_code. A naive export of just the item master will miss the entire production capability for manufactured goods. We join the bom_lines table to the item export, extract the full BOM hierarchy (including sub-assemblies with multiple levels), and map each line to Epicor PartMtl records. We preserve the quantity-per and material type, and set PartMtl.Est ScrapPercent from Atlas scrap_rate if present.

Atlas production routing step definitions are stored in routing_steps companion tables linked by item_code. We extract routing_steps in order sequence and map each step to Epicor JobOper records attached to the JobHead production order. The Atlas work_center_id maps to Epicor ResourceGroupID or ResourceID depending on whether the source is a group or an individual resource.

Atlas Production Orders carry a header with order number, status, planned start and end dates, and the linked item_code. We extract the JobHead record and also pull the associated BOM lines (bom_lines) and routing steps (routing_steps) that were active at the time of order creation, inserting them as PartMtl and JobOper respectively. Status mapping: Atlas planned/released/in-progress/closed map to Epicor JobHead.JobReleased/JobComplete/JobClose. Open production orders are migrated with their full material and operation structure; closed orders migrate as historical job records.

Atlas Sales Orders use a header-and-line table structure with order number, customer link, order date, and line items covering item_code, quantity, price, discount, and tax. We extract the full order header and line detail together, preserving open/closed status, and map OrderHed to Epicor OrderHed with CustomerNum resolved via a customer dedupe lookup. OrderDtl lines carry PartNum, UnitPrice, Discount, and OrderQty mapped directly.

Atlas Purchase Contracts and planned deliveries are stored in the Purchasing module with contract headers, line items, supplier linkage, and delivery schedule dates. We extract contract headers as Epicor POHeader records (with PORel for scheduled delivery dates) and map line items to PODetail. Pending delivery lines are flagged in the migration report so the customer can verify open PO quantities against supplier confirmations at go-live.

Atlas CRM records include company name, contact persons, addresses, sales responsible person, and lifecycle stage. We export the full contact hierarchy and map to Epicor Customer records with ShipTo addresses. The Atlas contact person becomes a CustCnt record linked to the Customer. The Atlas responsible person (sales owner) is resolved against the User mapping and set as the Epicor SalesRepCode on the Customer record.

Atlas Employee records include name, department, position, employment status, and salary grade. We map these to Epicor EmpBasic with department from Atlas dept_name mapped to Epicor EmpBasic.Department, and employment status (active/inactive/terminated) mapped to the Epicor flag fields. The Atlas employee_number maps to EmpBasic.EmpID as the dedupe key.

Atlas payroll history is stored in a separate payroll module with period-based gross/net breakdown, deductions, and employer contributions. We export the run summary and line-by-line detail and map to Epicor's payroll work file (PrWrkCmpr) structure. Gross pay, net pay, and deduction codes are mapped to the Epicor pay code schema. Note that Epicor payroll configuration requires the customer to define the pay code set before payroll records can be imported; we deliver a payroll field map as part of the migration package.

Atlas posts all module transactions automatically to the Finance module, so journal entries exist as both the original operational record (Sales Order, Production Order, Payroll run) and the corresponding GL posting. We extract journal_lines and journal_headers tables together and map to Epicor GLJrnHed and GLJrnLine. Because we migrate operational records separately and suppress re-posting, we import only the historical ledger records for closed periods, and leave the current open period to post fresh in Epicor after go-live to avoid double-counting.

Atlas Service Desk tickets carry status, priority, assignee, and conversation history. We export the ticket header, linked SLA terms (which are not transferable and must be re-created in Epicor), and conversation threads. SLA configurations and escalation rules are documented in the handoff package for the customer's Epicor admin to rebuild. Ticket status values map to Epicor HDCase status codes.

User-defined fields added through Atlas system administration are stored in companion tables alongside core entity tables and are not exposed in the standard UI export. We detect these shadow columns by running a pre-migration schema diff against the base Atlas table definitions. Each discovered extra column is mapped to the equivalent Epicor UD field (Part.UDField, OrderHed.UDField, JobHead.UDField, EmpBasic.UDField) during import. Customers must confirm any known custom fields during scoping so no shadow column is missed.

Documents linked to Atlas orders, items, employees, or production orders are stored on the file system or in varbinary columns in MS SQL. We extract the binary blobs and recreate them as file attachments in Epicor, linked to the corresponding entity record. Epicor's document management supports PDF, image, and Office file types. Large binary attachments (over 25 MB per file) are flagged for chunked extraction to avoid SQL Server memory pressure during read.