Migrate from Atlas ERP to Microsoft Dynamics 365 Business Central

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 via direct SQL read, remap account codes to the destination G/L Account number format, and preserve the hierarchical structure in the destination's Account Category (Income, Expense, Asset, Liability) assignment. Account types migrate as G_L_Account DirectPosting and Posting Type assignments in Business Central. In Finance and Operations, the account structure follows the Financial Dimensions framework which requires dimension sets to be configured alongside the main account chart.

Atlas posts all module transactions (sales, purchases, inventory movements, payroll) to the Finance module automatically via inter-module posting routines. When we migrate operational records (Orders, Productions, Payroll runs) AND finance records together, the destination Finance module will regenerate journal entries. We suppress the auto-posting flag during operational migration, migrate only open-period journal lines (typically the last 12 months) into Gen_JournalLine with a manual journal batch, and leave closed-period entries in a read-only reference archive. This prevents double-counting ledger rows in the destination.

Atlas Warehouses are master data records with warehouse_id, name, address, and optional cost-center linkage. We export them as-is and create corresponding inventory Locations in Business Central (or Site/Warehouse in Finance and Operations). Address data migrates to the Location's Address and Additional Location Details fields. If Atlas uses location-level costing, we configure Location as a stocking location in the inventory posting group setup before Items are imported.

Atlas Items include product masters with item_code, description, unit of measure, costing method, and default warehouse. We extract the item master and join it to the bom_lines and routing_steps companion tables to capture the full production capability. The Atlas costing method (Standard, Average, FIFO) maps to Business Central's Costing Method field on Item. For manufactured items, we set the Production BOM No. and Routing No. fields on the Item card to link the item to its BOM and routing after those records are created.

Atlas Bill of Materials for manufactured items is stored in a companion table linked by item_code, with line-level component items, quantities, and scrap percentages. We extract the bom_header and bom_lines tables, resolve the component item_code references to the migrated Item table, and create Production BOM records in Business Central (or Bill of Materials in Finance and Operations). The BOM Version is activated with a validity date range matching the Atlas effective-from/to dates. BOM line unit of measure conversion factors are preserved.

Production routing step definitions in Atlas live in a separate routing_steps table with sequence, work center or machine center, setup time, run time per unit, and transfer time. We extract the routing data, map the Atlas work-center codes to Business Central Work Centre or Machine Centre records (which we pre-create during setup), and create Work Routing records with the correct operation sequence, route job time, and concurrent capacity values. Routing versioning is preserved against the corresponding Production BOM.

Atlas Production Orders link to the Production Planning module and carry a status lifecycle (Planned, Released, In-Progress, Finished). We export order header, line detail, consumed and issued quantities, and link to the source item and routing. Production orders migrate as Production Order records in Business Central. Status is preserved in a custom field production_order_status__c for audit; the destination order is created in Released status so the customer can re-plan or confirm in Dynamics 365 post-migration. Closed production orders migrate as historical records only.

Atlas Sales Orders are stored with a header table (order number, customer, order date, payment terms, salesperson) and a line table (item, quantity, unit price, discount percent, tax code). We extract the full order header, line detail, and associated customer record, preserving open/closed status. Lines migrate to Business Central Sales Lines with Line Discount Percent, Unit Price, and Quantity migrated directly. Open orders are created as unposted Sales Orders so the customer can invoice from the migrated records post-go-live. Header-level discounts, shipping address, and internal notes migrate as document-level fields.

Atlas Purchase Contracts and planned deliveries are stored in the Purchasing module with contract headers, line items, supplier linkage, and delivery schedule dates. We export contract headers, line items, vendor account reference, and delivery schedule dates. Pending delivery lines are flagged as open purchase lines in Business Central. Long-term purchase contracts that span multiple periods are created as recurrent contract headers with line schedules if the destination supports recurring purchase templates; otherwise they are created as standard purchase orders with multiple line entries per delivery date.

Atlas Employee records include name, department, position, employment status, salary grade, and employment start date. We map these to Business Central's Employee table, preserving the department hierarchy (which maps to Business Central's Business Unit or a custom department dimension), the employment status (Active/Inactive), and salary information for payroll migration. In Finance and Operations, employees migrate to the HCM module with full Human Resources detail including employment type, pay frequency, and cost center linked to Financial Dimensions.

Atlas Payroll history is stored in a separate payroll module with period-based gross/net breakdown, deductions, employer contributions, and tax withholdings. We export the run summary and line-by-line detail, then map to Business Central's Payroll Journal (via an installed payroll extension or third-party payroll integration such as Ceridian or Workday) or to the general journal if the destination uses a custom payroll posting setup. Historical payroll data for closed periods migrates as general journal lines with detailed description fields; open-period payroll migrates with full gross/net/deduction detail for the customer's payroll admin to post through the configured payroll workflow.

Atlas CRM module stores Customer records with company name, contact persons, addresses, responsible salesperson, and lifecycle stage. We export the full contact hierarchy and map to Business Central Customer and Contact records. The primary contact's email, phone, and address migrate to the Customer card; additional contacts migrate as Contact records linked to the Customer. Salesperson assignments map to the Salesperson Code on the Customer. Lifecycle stage from Atlas (if used as a custom field) is preserved as a custom field customer_lifecycle_stage__c on the Customer for segmentation in Dynamics 365.

Atlas Service Desk tickets carry status, priority, assignee, and conversation history. We export the ticket header, linked SLA terms (which are not transferable to Dynamics 365 as SLA configurations differ between platforms), and conversation threads as notes or service line descriptions. Ticket priority maps to Business Central Service Item priority. If the destination is Business Central with the Service module, tickets become Service Orders; if Finance and Operations, they become cases in the HR or Customer Service module. SLA configurations must be rebuilt by the customer's admin post-migration.

Atlas supports multi-company and holding structures using a self-referential company table where parent_company_id points to the holding entity. We walk this tree recursively during extraction, extracting all subsidiaries in parent-first order. In Business Central, each Atlas company becomes a separate Company within the same tenant (or a separate tenant depending on licensing). We create companies in parent-first order to satisfy foreign-key constraints and configure inter-company journal templates in each destination company. In Finance and Operations, the holding structure maps to the Legal Entity hierarchy, with each Atlas company becoming a separate legal entity.

User-defined fields added through the Atlas system administration module are stored in companion shadow tables alongside core entity tables and are not exposed in the standard UI. We detect these by running a pre-migration schema diff against the base Atlas table definitions, identifying columns that exist in the customer's database but not in the standard Atlas schema. Discovered custom fields are exported with their entity context, and the API names from Atlas companion tables are used to name the corresponding custom fields in Business Central or Finance and Operations Extensions.

Documents linked to orders, items, employees, or production orders in Atlas are stored on the file system or in varbinary columns in MS SQL. We extract the binary blobs, preserve the original file name and MIME type, and recreate them as Document Attachment records in Business Central linked to the relevant parent record (Sales Header, Item, Employee, Production Order). Documents that are images (product photos, warehouse diagrams) are attached to the corresponding Item or Location card. Documents that are transactional evidence (signed orders, delivery notes) are attached to the relevant sales or purchase header.