ERP migration
Field-level mapping, validation, and rollback between Infor XA and Acumatica. We move data and schema; workflows are rebuilt natively in Acumatica.
Infor XA
Source
Acumatica
Destination
Compatibility
12 of 12
objects map 1:1 between Infor XA and Acumatica.
Complexity
BStandard
Timeline
3–6 weeks
Overview
Infor XA is an IBM i–native ERP (originally MAPICS) that stores data in RPG-based file structures with no modern REST API — migrations require file-based extraction (CSV, DBF, or ODBC dumps) from System i tables. Acumatica accepts data through its OData/REST endpoints and stores standard objects (Customers, Vendors, Stock Items, SO Orders, PO Orders, Production Orders, GL Transactions) alongside user-defined fields that use the Usr prefix convention. FlitStack AI sequences the migration so that customer and vendor records load first, then inventory items with BOM structures, then open sales orders and purchase orders, then production work orders with operation sequences, and finally GL history with original posting dates. We surface XA's custom fields as Acumatica Usr- prefixed custom properties. Workflows, alert rules, and Infor XA's Business Object Compiler customizations do not migrate — we export those definitions as a rebuild reference for your Acumatica consultant. Delta-pickup captures any transactions created in XA during the cutover window.
Every standard and custom field arrives verified.
AI proposes the map; you confirm before any record moves.
Parent–child, lookups, and ownership stay linked.
Calls, emails, meetings — with original timestamps.
Documents, uploads, and inline notes move with the record.
Why teams make this switch
Leaving
What's pushing teams away
Choosing
What's pulling them in
Object mapping
Each row shows how a Infor XA object lands in Acumatica, including any object-level transformations, lookup resolution, or schema-design dependencies.
Typical mapping — final map is confirmed during the sample migration step.
Infor XA
Customer Master (OECUS)
Acumatica
Customer
1:1XA customer records map to Acumatica's Customer table. XA's country codes and address structure map to Acumatica's Address / Contact fields — multiple ship-to addresses in XA become separate Location records under one Customer in Acumatica. Each location retains its own address lines, contact phone, and email, and the original XA location code is stored in a UsrOriginalShipTo custom field for audit traceability.
Infor XA
Vendor Master (APVND)
Acumatica
Vendor
1:1XA vendor records map to Acumatica's Vendor table. XA's 1099 flag maps to Acumatica's Tax ID type and reporting settings. Remit-to addresses become separate Vendor Locations in Acumatica. Each vendor location can store its own contact name, phone, email, and payment terms; the original XA vendor location code is preserved in a UsrOriginalVendorLoc custom field to support reconciliation and audit trails.
Infor XA
Item Master / Stock Items (IMITM)
Acumatica
Stock Item / Non-Stock Item
1:1XA item records split into Acumatica's Stock Item (for inventoried parts) and Non-Stock Item (for services and non-inventoried parts). XA's unit of measure conversions map to Acumatica's UOM class and UOM records. If the item carries lot or serial tracking, the lot/serial number assignments and expiration dates are transferred to Acumatica's Lot/Serial master and linked to the stock item's inventory ID, ensuring traceability from receipt to usage.
Infor XA
Bill of Materials (BOM) / MSTM
Acumatica
Bill of Materials / Material Kit
1:1XA multi-level BOMs map to Acumatica's BOM structure. XA's phantom BOMs (type P) become Acumatica non-stock kit items. BOM rollup costs recalculated in Acumatica's Cost Management module post-migration. Component quantities, scrap factors, and operation step references are also transferred, preserving the original BOM routing so that production scheduling in Acumatica reflects the same material flow and labor assumptions as the XA system.
Infor XA
Sales Order Header (SOSHD)
Acumatica
Sales Order
1:1XA open sales orders map to Acumatica SO Orders with original order dates preserved. XA's order type codes map to Acumatica's Order Type configuration. Lines map with warehouse and inventory ID resolution. Shipping address, freight terms, and any line-level discounts are carried forward; the original XA sales order number is retained in the ExtRefNbr field for cross-reference and audit purposes.
Infor XA
Purchase Order Header (POHD)
Acumatica
Purchase Order
1:1XA open purchase orders migrate to Acumatica PO Orders with the vendor and line structure intact. XA's approval workflow status carries as a custom field if the approval state does not match Acumatica's workflow states. All line items retain the original unit cost, promised date, and UOM; the original PO number is stored in ExtRefNbr for traceability, and any notes or attachments are exported as file links in the Acumatica PO record.
Infor XA
Work Order / Production Order (WOMHD)
Acumatica
Production Order
1:1XA work orders map to Acumatica Production Orders. XA operation sequences (labor and machine steps) become Acumatica operations linked to the production order. XA's material allocations map to Material Issues in Acumatica. Each operation captures the work center code, scheduled start and end times, and the labor hours, while material issues record the inventory lot, quantity issued, and the warehouse location, preserving the original XA work order number in the ProductionNbr field for reference.
Infor XA
AR / AP Invoices (ARIHDR / APIHDR)
Acumatica
AR Invoice / AP Bill
1:1XA open AR and AP invoices map to Acumatica's AR Invoice and AP Bill records with original posting dates. Closed historical invoices migrate as journal entries in Acumatica's GL if open-item reporting is required. Each invoice line includes the account code, amount, tax amount, and description; the original invoice number is stored in ExtRefNbr for cross-referencing, and any payment terms or due dates are transferred to the Acumatica document's financial tab.
Infor XA
GL Account Ledger (GLBTR)
Acumatica
GL Transaction / Batch
1:1XA GL detail lines map to Acumatica GL Transactions. XA's chart of accounts structure (division/department segments) must be mapped to Acumatica's account segments or subaccount dimension. Multi-segment XA accounts split into Acumatica's Main Account + Subaccount. Every transaction retains the original posting date, source module, and batch reference, and the original XA journal entry number is stored in the ExtRefNbr field for audit traceability and reconciliation against the legacy trial balance.
Infor XA
Lot / Serial Master (LOTCFG / SERSER)
Acumatica
Lot / Serial Number
1:1XA lot and serial number master records map to Acumatica's Lot/Serial tracking at the inventory-item level. XA lot expiration dates carry forward. Active lots link to on-hand quantity records in Acumatica's warehouse. Each lot record stores the original XA lot code in a custom field, and the warehouse location, bin, and receipt date are preserved to support FIFO or LIFO costing layers in Acumatica's inventory valuation.
Infor XA
User-Defined Fields (UDF on Business Objects)
Acumatica
Usr-prefixed Custom Fields
1:1XA custom fields on any Business Object are exported and re-created as Acumatica Usr-prefixed DAC fields in a Customization Project. FlitStack delivers the field list and data population mapping as part of the migration package. Each custom field is added to the appropriate DAC with a data type matching the original XA definition, and the existing values are imported using the Acumatica REST endpoint with batch inserts, ensuring no loss of historical information.
Infor XA
Sales Order History / Invoice History
Acumatica
AR Invoice / SO Line History
1:1XA closed sales orders and invoices become historical records in Acumatica. Original transaction dates and amounts are preserved for reporting continuity. History records post to GL as posted batches. Each historical document retains its original document number in the ExtRefNbr field, and any associated line-level tax, discount, or freight amounts are mapped to the corresponding Acumatica financial columns, maintaining audit trail integrity.
| Infor XA | Acumatica | Compatibility | |
|---|---|---|---|
| Customer Master (OECUS) | Customer1:1 | Fully supported | |
| Vendor Master (APVND) | Vendor1:1 | Fully supported | |
| Item Master / Stock Items (IMITM) | Stock Item / Non-Stock Item1:1 | Fully supported | |
| Bill of Materials (BOM) / MSTM | Bill of Materials / Material Kit1:1 | Fully supported | |
| Sales Order Header (SOSHD) | Sales Order1:1 | Fully supported | |
| Purchase Order Header (POHD) | Purchase Order1:1 | Fully supported | |
| Work Order / Production Order (WOMHD) | Production Order1:1 | Fully supported | |
| AR / AP Invoices (ARIHDR / APIHDR) | AR Invoice / AP Bill1:1 | Fully supported | |
| GL Account Ledger (GLBTR) | GL Transaction / Batch1:1 | Fully supported | |
| Lot / Serial Master (LOTCFG / SERSER) | Lot / Serial Number1:1 | Fully supported | |
| User-Defined Fields (UDF on Business Objects) | Usr-prefixed Custom Fields1:1 | Fully supported | |
| Sales Order History / Invoice History | AR Invoice / SO Line History1:1 | Fully supported |
Gotchas + challenges
Platform-specific issues from each side, plus the pair-specific challenges that don't show up on either platform's page on its own.
Infor XA gotchas
Direct Db2 extraction required for bulk data export
IFS-hosted document attachments fall outside standard extraction
Decades of site-specific RPG customizations resist direct migration
Citrix XenApp dependency complicates user acceptance testing
Acumatica gotchas
API user licenses cap concurrent sessions and request throughput
Multi-tenant filtering requires CompanyID awareness
Custom fields require separate discovery before field mapping
Notes and attachments use a separate linked table structure
Implementation timelines frequently run 3–9 months end-to-end
Pair-specific challenges
Migration approach
Extract XA file layouts and normalize RPG-structured data
FlitStack connects to the IBM i environment via secured ODBC or runs CPYTOIMPF / SQL-to-CSV pipelines against the XA library files (OECUS, APVND, IMITM, SOSHD, POHD, WOMHD, GLBTR, LOTCFG). We capture the DDS field definitions for every file so the target Acumatica field mapping is derived from the actual XA schema, not guessed from a generic template. The extraction produces a staging area of normalized CSV files with original record-create and update timestamps preserved.
Define Acumatica chart of accounts and branch structure
Before data loads, FlitStack delivers an account-structure plan that maps XA's GL segments to Acumatica's Main Account and Subaccount dimensions. We also create the Branch records in Acumatica that correspond to XA's facility and division codes. If multi-company consolidation is required, we configure Acumatica's inter-company GL setup. This step runs in parallel with the XA extraction so both sides are ready when the migration begins.
Load customers, vendors, and inventory items first
Acumatica enforces referential integrity — Stock Items must exist before Sales Order lines can reference them, and Customers/Vendors must exist before AR/AP invoices can post. FlitStack sequences the load order to resolve these foreign keys: Customers → Vendors → Stock Items (with BOM structures) → Locations and Lot/Serial masters. Custom fields identified in the XA schema are created as Usr-prefixed DAC fields before the relevant object batch runs.
Migrate open orders, production orders, and AP/AR with field-level diff
With master data loaded, FlitStack runs a sample migration of open Sales Orders, Purchase Orders, and Production Orders (typically 100–500 records spanning the full record types). We generate a field-level diff comparing source XA field values to destination Acumatica field values so you can verify GL account mapping, order-type mapping, and warehouse resolution before the full run commits. Custom field population is verified in the same diff pass.
Cut over with delta-pickup and audit log
The full migration runs against Acumatica's REST endpoints. A delta-pickup window (typically 24–48 hours) captures any transactions created or modified in XA during the cutover. FlitStack's audit log records every record inserted, updated, or skipped with reason codes. One-click rollback reverts the Acumatica environment to its pre-migration snapshot if reconciliation against XA's trial balance fails. After go-live, the XA read-only access is revoked and XA enters a read-only sunset state.
Platform deep dives
Infor XA
Source
Strengths
Weaknesses
Acumatica
Destination
Strengths
Weaknesses
Complexity grading
Standard ERP migration. 1 of 8 objects need a mapping; the rest are 1:1.
Overall complexity
Standard migration
Derived from compatibility, mapping clarity, API constraints, and data volume across Infor XA and Acumatica.
Object compatibility
1 of 8 objects need a mapping; the rest are 1:1.
Field mapping clarity
Field mapping is derived from defaults — final spec confirmed during the sample migration.
Timeline complexity
8-object category — typical timelines run 2–7 days end-to-end.
API constraints
Infor XA: Not publicly documented — depends on Runtime Server (nginx gateway) configuration and IDF object limits..
Data volume sensitivity
Infor XA exposes a bulk API — large-volume migrations stream efficiently.
Estimator
Rule-based pricing — no per-record fees, no manual quotes. Migrations over 2M records are scoped individually.
Step 1
Pick a category, then your source and destination platforms.
Category
FAQ
Answers to the questions buyers ask most during Infor XA to Acumatica migration scoping. Not seeing yours? Book a call.
Walk through your Infor XA to Acumatica migration with a real engineer — 30 minutes, free, written quote within 24 hours.
Book a free 30 minute consultationAdjacent paths
Other ways to leave Infor XA
Other ways to arrive at Acumatica
Ready when you are
Tell us record counts and timeline. We'll come back with a written quote inside 1 business day — no commitment, no sales pitch.