ERP migration

Migrate from Infor XA to Acumatica

Field-level mapping, validation, and rollback between Infor XA and Acumatica. We move data and schema; workflows are rebuilt natively in Acumatica.

Infor XA logo

Infor XA

Source

Acumatica

Destination

Acumatica logo

Compatibility

100%

12 of 12

objects map 1:1 between Infor XA and Acumatica.

Complexity

BStandard

Timeline

3–6 weeks

Rollback included Accuracy guarantee Field-level validation

Overview

What this migration involves

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.

Field-level fidelity

Every standard and custom field arrives verified.

Schema-aware mapping

AI proposes the map; you confirm before any record moves.

Relationships preserved

Parent–child, lookups, and ownership stay linked.

Full activity history

Calls, emails, meetings — with original timestamps.

Attachments & notes

Documents, uploads, and inline notes move with the record.

Why teams make this switch

Two sides of the same decision

Leaving

Infor XA logo

Infor XA

What's pushing teams away

  • The aging green-screen interface requires Citrix XenApp access and frequent password rotations, creating friction for shop floor operators and increasing IT overhead for every user session.
  • Extracting large datasets from Db2 for i requires additional steps and tooling; customers report that bulk data exports are time-consuming and often need custom scripting.
  • The pool of developers skilled in RPG and IBM i administration is shrinking, making long-term maintenance costs and customization risk escalate as tenured staff retire.
  • Limited native cloud capabilities and difficulty integrating modern CRM, eCommerce, WMS, and automation tools put XA customers at a disadvantage against competitors with cloud-native architectures.
  • High cost of customizations layered over decades of site-specific modifications creates a growing total cost of ownership that drives evaluation of modern ERP alternatives.

Choosing

Acumatica logo

Acumatica

What's pulling them in

  • Unlimited user licensing lets companies add staff without per-seat billing shocks, making Acumatica cost-predictable at scale.
  • Flexibility and scalability earn consistent praise — users value a platform that adapts to vertical workflows without forcing a redesign.
  • Real-time visibility across financials, inventory, and projects gives mid-market businesses a consolidated operational view previously available only in enterprise-tier ERPs.
  • Cloud-native architecture with automatic updates removes infrastructure management burden from in-house IT teams.
  • Modular licensing lets companies start with one or two suites (Financials, Distribution) and expand into Manufacturing or CRM incrementally.

Object mapping

How Infor XA objects map to Acumatica

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)

maps to

Acumatica

Customer

1:1
Fully supported

XA 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)

maps to

Acumatica

Vendor

1:1
Fully supported

XA 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)

maps to

Acumatica

Stock Item / Non-Stock Item

1:1
Fully supported

XA 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

maps to

Acumatica

Bill of Materials / Material Kit

1:1
Fully supported

XA 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)

maps to

Acumatica

Sales Order

1:1
Fully supported

XA 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)

maps to

Acumatica

Purchase Order

1:1
Fully supported

XA 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)

maps to

Acumatica

Production Order

1:1
Fully supported

XA 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)

maps to

Acumatica

AR Invoice / AP Bill

1:1
Fully supported

XA 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)

maps to

Acumatica

GL Transaction / Batch

1:1
Fully supported

XA 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)

maps to

Acumatica

Lot / Serial Number

1:1
Fully supported

XA 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)

maps to

Acumatica

Usr-prefixed Custom Fields

1:1
Fully supported

XA 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

maps to

Acumatica

AR Invoice / SO Line History

1:1
Fully supported

XA 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.

Gotchas + challenges

What specifically takes care here

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 logo

Infor XA gotchas

High

Direct Db2 extraction required for bulk data export

Medium

IFS-hosted document attachments fall outside standard extraction

High

Decades of site-specific RPG customizations resist direct migration

Low

Citrix XenApp dependency complicates user acceptance testing

Acumatica logo

Acumatica gotchas

High

API user licenses cap concurrent sessions and request throughput

High

Multi-tenant filtering requires CompanyID awareness

Medium

Custom fields require separate discovery before field mapping

Medium

Notes and attachments use a separate linked table structure

Low

Implementation timelines frequently run 3–9 months end-to-end

Pair-specific challenges

  • XA's multi-segment GL accounts require subaccount mapping before GL loads

    Infor XA commonly uses composite GL account numbers with embedded division or department segments (e.g., 4-4200-01). Acumatica stores Main Account and Subaccount as separate fields linked by an account structure. If the XA chart of accounts has two or three segments, FlitStack must split them into Acumatica's Main Account code plus the corresponding Subaccount dimension before GL transactions can post correctly — the branch entity also needs to be set in Acumatica so inter-company entries resolve.

  • XA production work orders with operation sequences need step-level remapping

    XA work orders carry operation sequences with labor hours, machine centers, and pre-assignments tied to the shop floor calendar. Acumatica Production Orders separate operations from material issues — the operation step's work center code must resolve to an Acumatica Machine/Work Center, and the calendar ID on the operation must match Acumatica's scheduling calendar. If XA uses overtime or shift overrides, those flags have no direct Acumatica equivalent and require a custom Usr field to preserve the flag.

  • XA Business Object Compiler custom fields are RPG-coded and must be manually re-created

    Infor XA allows developers to attach custom field logic directly into RPG Business Object programs — this logic (field validation, default values, cross-file lookups) is not exported as data. Acumatica handles equivalent logic through C# extension methods on DAC classes within a Customization Project. FlitStack documents every Usr-prefixed custom field found in the XA file layouts and provides the original XA values as import data, but the business-rule logic must be rebuilt by an Acumatica developer using the export as a specification.

  • Acumatica's per-license concurrent session limit affects bulk import throughput

    Acumatica enforces concurrent web-service session limits tied to the license tier (the Stack Overflow discussion on 'API Login Limit' shows the instance-level cap at SM604000). FlitStack's migration runner manages OAuth token lifecycle, implements retry-backoff on 429 responses, and batches records to stay within the licensed concurrency window. XA's file-extraction side has no API — the bottleneck is purely on the Acumatica ingestion side, so we tune batch sizes to your license concurrency setting before the first run.

  • XA item warehouse assignments must be mapped to Acumatica branch/warehouse combinations

    Infor XA stores warehouse assignments at the item-record level with default locations. Acumatica uses a Branch-Warehouse-Location hierarchy — the item must be designated as 'Stock' and assigned to a specific Warehouse on the Stock Items screen. If XA has item records without a warehouse code or with a warehouse code that does not exist in Acumatica, FlitStack flags those items as 'unresolved warehouse' and routes them to a configurable default branch with a UsrOriginalWarehouse custom field preserving the original XA location code.

Migration approach

Six steps for a successful Infor XA to Acumatica data migration

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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

Context on both ends of the pair

Infor XA logo

Infor XA

Source

Strengths

  • Deep discrete manufacturing functionality purpose-built for engineer-to-order and make-to-order production environments on IBM i.
  • Integrated financials, inventory, production, and purchasing within a single Db2 for i database reduces data synchronization overhead.
  • Long product history means extensive module coverage for mid-to-large discrete manufacturers with complex costing requirements.
  • Support for multi-site, multi-currency, and multi-company structures within a single accounting entity framework.
  • Infor ION and Infor OS integration layers provide some pathway for modern middleware connectivity despite limited native APIs.

Weaknesses

  • Green-screen-centric UI requiring Citrix XenApp creates poor user experience for modern workforce expectations and adds licensing complexity.
  • No publicly documented REST API for direct integration; data extraction relies on direct Db2 reads, CSV exports, or third-party connectors.
  • RPG and IBM i developer scarcity drives up consulting and maintenance costs as experienced staff retire from the workforce.
  • Limited cloud capabilities and mobile access lag behind modern ERP platforms with browser-based or native mobile interfaces.
  • Site-specific customizations accumulated over decades create significant migration risk and often require partial reimplementation in the target system.
Acumatica logo

Acumatica

Destination

Strengths

  • Unlimited named-user licensing eliminates per-seat cost scaling as teams grow.
  • Modular architecture lets companies deploy Financials first and add Distribution, Manufacturing, or CRM incrementally.
  • Cloud-native with automatic updates removes infrastructure patching and version management from IT responsibilities.
  • Flexible customization framework (UDFs, extensions) supports vertical-specific workflows without forking core code.
  • Multi-tenant architecture with CompanyID isolation enables safe data segregation across subsidiaries.

Weaknesses

  • Steep learning curve and complex initial setup create significant onboarding friction.
  • Report Designer is widely cited as unintuitive and difficult to use for non-developers.
  • Feature gaps require customizations or third-party add-ons, adding implementation cost and complexity.
  • Implementation timelines frequently exceed initial estimates, especially for multi-module deployments.
  • API rate limits and concurrent session caps are tied to license tier, creating throughput constraints for bulk data operations.

Complexity grading

How hard is this migration?

Standard ERP migration. 1 of 8 objects need a mapping; the rest are 1:1.

B

Overall complexity

Standard migration

Derived from compatibility, mapping clarity, API constraints, and data volume across Infor XA and Acumatica.

  • Object compatibility

    B

    1 of 8 objects need a mapping; the rest are 1:1.

  • Field mapping clarity

    C

    Field mapping is derived from defaults — final spec confirmed during the sample migration.

  • Timeline complexity

    B

    8-object category — typical timelines run 2–7 days end-to-end.

  • API constraints

    B

    Infor XA: Not publicly documented — depends on Runtime Server (nginx gateway) configuration and IDF object limits..

  • Data volume sensitivity

    A

    Infor XA exposes a bulk API — large-volume migrations stream efficiently.

Estimator

Estimate your Infor XA to Acumatica migration cost

Rule-based pricing — no per-record fees, no manual quotes. Migrations over 2M records are scoped individually.

Step 1

What are you migrating?

Pick a category, then your source and destination platforms.

Category

FAQ

Frequently asked questions about Infor XA to Acumatica data migrations

Answers to the questions buyers ask most during Infor XA to Acumatica migration scoping. Not seeing yours? Book a call.

Can't find your answer?

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 consultation

Most Infor XA to Acumatica migrations complete in 3–6 weeks for under 50,000 records when XA's IBM i environment is accessible via ODBC or file export. Larger manufacturing datasets with 500k+ transactional records, multi-level BOMs, or multi-company consolidation extend to 8–12 weeks. The longest phase is typically GL account structure design and branch setup — resolving XA's composite account codes to Acumatica's Main Account + Subaccount model before any transaction data can load.

Adjacent paths

Related migrations to explore

Ready when you are

Move from Infor XA.
Land in Acumatica, intact.

Tell us record counts and timeline. We'll come back with a written quote inside 1 business day — no commitment, no sales pitch.

Accuracy guarantee Rollback included Quote in 1 business day