Migrate from IMPulse ERP to Acumatica

Subaccount segment configuration must precede data migration — not retrofitted afterward

Acumatica requires a segment-keyed subaccount structure as the foundation for all financial transactions, and every account must be assigned subaccount segments before any journal entry or inventory transaction can post. IMPulse ERP stores cost-center data as flat attributes on records without enforcing a multi-segment hierarchy. Teams that load data before establishing the subaccount segments find that every record's account assignment breaks — they must re-map and reload GL account distributions and inventory account links. FlitStack AI audits the IMPulse ERP cost-center schema during discovery and delivers a subaccount segment plan (segment count, segment names, and segment values per account) that your Acumatica admin creates before any import scenario runs. We flag any IMPulse account that cannot cleanly map to the chosen segment structure and escalate before committing data.

Branch and warehouse assignment is mandatory on inventory transactions in Acumatica — IMPulse ERP often has no equivalent entity

Acumatica's Branch entity is a first-class configuration object that ties together a legal entity, a set of GL accounts, a tax zone, and one or more warehouses. Every inventory issue, receipt, and transfer must be assigned to a Branch. IMPulse ERP typically uses a flat warehouse list without a branch or legal-entity layer. Teams migrating from a single-warehouse IMPulse configuration into a multi-branch Acumatica deployment must decide whether to consolidate all inventory into one branch or use Acumatica's branch structure to represent the IMPulse warehouse split. FlitStack AI surfaces this decision during schema planning: we build a branch-and-warehouse mapping table and apply it consistently across all inventory documents. If you plan to operate Acumatica across multiple legal entities post-migration, we create the branch hierarchy first so that item warehouse assignments resolve correctly during the import.

Custom attributes require a registered Acumatica Customization Project before any data loads — they cannot be added inline during import

IMPulse ERP user-defined properties are defined per object and stored alongside standard fields. Acumatica treats custom attributes (UDFs) as schema-level extensions that must be registered in a Customization Project or via the Generic Inquiry designer before any data import can populate them. If your IMPulse ERP configuration has more than 20 custom fields across the Customer, Item, Sales Order, and Purchase Order entities — common in manufacturing setups where items carry custom engineering attributes — those custom attributes must be coded and published in Acumatica before migration begins. FlitStack AI's discovery phase inventories every IMPulse custom field, classifies its data type, and produces an Acumatica customization manifest. We coordinate with your Acumatica implementation partner to register the custom attributes; the data migration plan waits for schema registration to complete.

IMPulse ERP production orders do not map to a single Acumatica entity — they decompose into a Production Order plus material and labor entries

IMPulse ERP production or work orders store the job header, bill of materials, and labor tracking in a single record with line-type distinctions. Acumatica separates production execution into three distinct entities: the Production Order (controlling the overall job), Material Issues (consuming components from inventory), and Labor Entries (recording production time). Open IMPulse work orders that span multiple component lines must be decomposed into the corresponding Acumatica Material Issue lines, and any recorded labor must be posted as Labor Entry records. FlitStack AI reads the IMPulse work order lines, classifies each by line type (material, labor, or outside processing), and generates the corresponding Acumatica documents. Closed or historical IMPulse work orders are migrated as completed Production Orders for audit continuity without triggering inventory transactions.

Acumatica's document workflow states differ from IMPulse ERP's custom status flags — the translation table must be explicit and agreed upon before migration

IMPulse ERP allows users to define custom status values on sales orders and purchase orders without enforcing a state-transition matrix. A status called 'Ready to Ship' or 'Pending Approval' in IMPulse has no guaranteed equivalent in Acumatica's fixed pick-list of OrderNbr statuses (On Hold, Pending Approval, Open, Completed, Cancelled). FlitStack AI builds an explicit status-translation table during discovery: each IMPulse ERP order status value is mapped to exactly one Acumatica status, and the mapping is reviewed with your team before migration runs. The status translation affects workflow routing in Acumatica — misaligned statuses can cause orders to appear in the wrong queue or bypass approval workflows entirely. We document the translation table as part of the migration specification and validate post-migration that order queues reflect the intended state.