Migrate from Atlas ERP to Acumatica

Business partner consolidation: customers and vendors merge into one BAccount record

Atlas ERP separates Customers (CRM subsystem) and Vendors (Purchasing subsystem) into distinct tables, each with independent address, contact, and payment data. Acumatica uses a single Business Partners (BAccounts) table where the Customer and Vendor flags are fields on one record. If the same entity appears as both a customer and a vendor in Atlas, they must be identified by comparing entity names or tax IDs across both tables, then merged into a single BAccount with both flags set to True. Address and contact records from both Atlas subsystems must be combined into the BAccount's address and contact subrecords, which requires deduping overlapping entries.

Product variant architecture requires Acumatica subitem and attribute redesign

Atlas ERP products use a parent-card with child variant rows where each variant stores its own combination of attributes (size, color, material) and independent pricing. Acumatica does not support variant rows on a product — instead it uses Subitems linked to a stock Item plus attribute definitions on the item class. Each Atlas variant row becomes a separate Subitem with a unique SubItemCD. Variant-level pricing in Atlas maps to Acumatica Price Classes or Customer-Specific Pricing records rather than inline on the variant. We generate the subitem structure and attribute definitions during the migration plan phase so Acumatica item classes are ready before inventory data loads.

Workflows, approvals, and alert rules cannot migrate and must be rebuilt

Atlas ERP drives approvals and process automation through subsystem-specific state transitions and configuration stored in CRM and Finance modules — these are not stored as discrete automation objects. Acumatica has a dedicated Screen-Based Workflow Designer for document approvals, Business Events for trigger-action automation, and Notification Templates for alerts. These have no data-level equivalent in Atlas and cannot be extracted as migration artifacts. We export your Atlas workflow configuration (screens, stages, conditions) as a structured reference document so your Acumatica admin or consultant can rebuild equivalent logic using Acumatica's native automation tools.

Atlas GL structure maps to Acumatica chart of accounts with segment-based subaccounts

Atlas ERP stores GL accounts with optional subaccount codes in its Financial Accounting subsystem. Acumatica uses a Chart of Accounts with segment-based dimensions for subaccounts (configured in the Segments screen under Configuration). Atlas accounts with embedded subaccount codes (e.g., '4100-01') must be split into an Account segment and a Subaccount segment in Acumatica. Multi-entity holding structures in Atlas map to Acumatica intercompany accounts and Branch entities, which require separate configuration in the Organizations screen.

Module scope decisions affect Acumatica licensing and migration completeness

Atlas ERP bundles modules by pricing tier — Financials, CRM, Warehouses, Production Planning, and HRM each have distinct functional scope. Acumatica's module licensing is additive: Financials is the base, then Distribution, Manufacturing, and Project Accounting are activated separately. If Atlas production orders and project records need full project management tracking in Acumatica, the Project Accounting module must be licensed and configured before migration. We assess which Atlas modules are actively used (not just installed) during discovery to recommend the correct Acumatica module scope and avoid paying for unused licenses post-migration.