The Definitive Guide to Migrating to Acumatica

Acumatica, Inc. provides cloud and browser-based enterprise resource planning software for small and mid-sized businesses, headquartered in Bellevue, Washington in the Seattle metropolitan area ¹. The product is built on the xRP cloud platform and is sold as a consumption-based subscription rather than per-named-user, which materially changes the economics of who you pull into the system.

The typical Acumatica customer runs $5M to $500M of revenue and has outgrown QuickBooks, Sage 50, Dynamics GP or an older NetSuite footprint that no longer fits. Editions cover General Business, Manufacturing, Distribution, Construction, Field Service and Retail-Commerce — each shipping a tuned data model and a tuned Generic Inquiry library, but all sharing the same xRP core and the same Import Scenario engine.

The shapes of migration that actually land on Acumatica tend to fall into four patterns. First, legacy ERP exits — Dynamics GP, SAP Business One, Sage 100/300, Epicor — where the source schema is rigid but the GL discipline is strong, and the project is really about preserving period balances without dragging years of subledger detail into the new system ⁴.

Second, NetSuite exits, where teams move to control total cost of ownership on a consumption-based licence and recover from add-on price creep ³. Third, QuickBooks graduations, where a fast-growing distributor or manufacturer outgrows desktop or online accounting and finally needs real inventory, BOM and multi-entity. Fourth, M&A integration, where an acquirer standardises subsidiaries on a single Acumatica tenant and harmonises chart-of-accounts segmentation across the group.

What makes migrating *to* Acumatica easier than the category average is the Import Scenario framework — a no-code mapping engine that reads CSV or Excel through a configurable data provider, applies formulas and lookups, and writes records through the same business-logic graph that an interactive user would touch, validations and all ²².

What makes it harder than the average is the consumption-based licensing model, where transaction volume and resource tier — not user count — drive cost, and a stale data load can silently push you up a tier on the next renewal ³². Acumatica also does not allow you to override CreatedDateTime or LastModifiedDateTime on standard imports, so all historical timestamps must be captured in custom user-defined fields if reporting depends on them.

Generic Inquiries, dashboards, Customization Projects, Acuminator extensions and reports do not auto-migrate from any source — they are rebuilt against the destination schema. Teams that scope the rebuild work up front finish on time; teams that assume parity do not.

Teams that scope for the Generic Inquiry, dashboard and Customization Project rebuild up front finish on time; teams that assume parity do not.

Acumatica's data model is organised around Data Access Classes (DACs), each of which is exposed through a screen and a Generic Inquiry inside an industry-versioned package — Default, Manufacturing, Distribution, Construction or Field Service ¹¹¹². The set of objects you will touch in a migration depends on edition, but a core cluster shows up on every project.

Before you can map a field on the source side, you need to know which destination DAC the row belongs on, what fields are required by the underlying graph, and what the natural key is. The table below summarises the objects you will touch in a financials-plus-distribution migration.

Most master DACs use a CD field (Customer ID, Vendor ID, Inventory ID, Account ID) as the human-readable key, paired with an internal integer ID that the framework uses for joins ⁵³. For migration, the CD field is your upsert key — load with a stable, deterministic value (often the source primary key prefixed by a system marker) and let Acumatica generate the internal ID.

Transaction documents use a two-part natural key — (DocType, RefNbr) — and this is the single most-missed detail in beginner Import Scenarios. The Document Type is auto-defaulted on the form, so it does not visually appear in the field order, but it must be mapped as the *first* key field in the Import Scenario or the scenario will silently fail on the second invoice.

Custom field types in Acumatica are exposed through the Data Class Editor on a Customization Project and broadly cover the catalogue below. Picklists are declared via PXStringList with parallel arrays of internal codes and display values ⁶⁴; the *code* is what the database stores and what every import path expects, while the *display* string is purely UI.

Relationships are modelled as master-detail — one DAC's primary key is referenced as a foreign key on a child DAC via a PXSelector attribute with a SubstituteKey clause ⁵³. Acumatica does not auto-cascade deletes; the framework instead fires RowPersisting events with PXDBOperation.Delete so business logic can decide whether to cascade or block ¹³¹. There is no native junction-object pattern as in Salesforce — many-to-many relationships are built explicitly with a junction DAC and two PXSelector lookups.

Customization Projects (the no-code/low-code customisation framework) are the wrapper for every custom field, screen extension, workflow tweak and DAC modification you make on the destination side, and projects are what you publish from sandbox to production ⁴¹. Snapshots, captured from System Management → Snapshots, are the binary backup-and-restore unit — they bundle every schema, configuration and data row and can be re-imported into a fresh tenant for staging or rollback ¹²³.

The single best predictor of a clean Acumatica migration is how much chart-of-accounts and Item Class work the finance team does on the source side before the destination tenant is even provisioned. Acumatica's own Open University F110 Data Migration course is built around that order of operations — master records first, then opening balances, then open documents, then reconciliation ⁹⁷.

The single best predictor of a clean migration is how much chart-of-accounts and Item Class work happens before the destination tenant is provisioned.

Treat the source export as raw material that needs to be shaped to Acumatica's expected formats — segmented Account values normalised to the new segment definition, Inventory IDs uppercased to the chosen mask, currency rates expressed as Acumatica's effective-rate-on-date convention, dates rewritten to a format the CSV Data Provider can parse, owners resolved to Employee IDs.

Source-side prep

• Audit and dedup the source master data — Customers, Vendors and Inventory IDs — before export. Acumatica's Validation of Records for Duplicates feature finds matches post-import, but it is far cheaper to dedup once on the source than to merge thousands of records inside Acumatica's duplicate-validation workflow ⁹¹.
• Lock the chart-of-accounts segment structure — number of segments, segment lengths, allowed values — before the first Account row exports. Once you have posted a single GL transaction in Acumatica, restructuring segments is destructive and requires a re-implementation. Plan Branch, Account and Subaccount segmentation as a single design decision.
• Normalise picklist codes to Acumatica's PXStringList internal codes for every enumeration field — Customer Class, Vendor Class, Item Class, Account Class. Acumatica stores the 2–4-character code, not the display label ⁶⁴, and Import Scenarios that send labels are rejected silently or generate String or binary data would be truncated errors ⁸².
• Stamp a stable external ID on every record — a UUID or the source platform's primary key — so re-runs and reconciliation are deterministic and so AP/AR open documents can be tied back to the historical source.
• Decide what is in scope for historical transactions versus reference-only archive. Most teams migrate only open AR/AP plus 12–24 months of detail and surface older history through a side-by-side viewer or a reporting warehouse rather than pushing it through the GL ⁹⁶.

Destination-side prep

• Provision a sandbox tenant alongside the production tenant from the start. Acumatica supports multiple tenants in one application instance, and the sandbox is the dry-run target for every Import Scenario before it touches production ⁷³.
• Provision users and roles first — Acumatica ships predefined finance, distribution and CRM roles (AP Admin, AP Clerk, AR Admin, AR Clerk, CA Admin, GL Admin, IN Admin) that you assign to users via the User Roles form before importing owner-stamped records ⁷⁷⁷⁸. Imports that target a non-existent owner are rejected, not silently nulled.
• Build the Customization Project shell for every custom field you intend to add — Usr-prefixed columns on Customer, Vendor, Inventory, Stock Item, Sales Order and AP Bill DACs. Publish the project to sandbox first; only after validation publish to production.
• Configure financial settings — Companies, Branches, Ledgers, fiscal Year and Periods, currency list, exchange-rate types, posting classes, payment methods and Cash Accounts — before the first Account import. The Account import depends on Account Classes existing first.
• Build Generic Inquiries for reconciliation queries before cutover — Trial Balance by source vs. destination, AR Aging vs. source, AP Aging vs. source, Inventory Quantity on Hand vs. source. Run these against sandbox during dry-runs so they are battle-tested before go-live.

People prep

Cutover only works if finance cooperates. Lock down a source-system freeze window — typically a weekend with the close already through period 12 on the source ledger — and communicate it to every department that touches AP, AR, billing or inventory. Train AP clerks, AR clerks and the controller on Acumatica's workflows, document types, and Cash Sale vs. Invoice semantics before go-live, not after.

A clean ledger-only migration runs one to two weekends; a multi-entity manufacturing migration with BOM, production orders and historical projects runs four to twelve weeks of elapsed time. Build the human runway accordingly.

Acumatica's primary load path is the Import Scenario engine, which covers most one-shot migrations and is the most-recommended option for finance-led teams ²²⁵⁰.

Import Scenarios (the recommended default)

Import Scenarios live under Integration → Process → Import Scenarios (screen SM206025) and they read from a configurable Data Provider — CSV, Excel, SQL or a custom provider ⁴⁵. Each scenario maps source columns to target screen fields via the Mapping tab, applies formulas (PadLeft, CStr, LineNbr) for transformation ⁸⁵, and runs the import row-by-row through the same PXGraph business logic that fires when a user types into the screen.

Two critical rules: key fields must be mapped first and in the order they appear on the target form, and the Document Type field must be explicitly mapped on transaction imports even though it auto-defaults visually. Scenarios can be triggered manually from Integration → Process → Import by Scenario, attached to an Automation Schedule to run unattended at 3 AM, or surfaced as menu items inside a workspace using the *Make Visible on UI* flag ⁴⁸.

The right call: Import Scenario for any migration up to a few hundred thousand records on standard objects, any finance-led project where the controller needs to see and approve the mapping in the UI, and any load you want to re-run on a schedule. The same scenario can be used for cutover, delta-load and ongoing daily-feed.

Third-party staging tools

Tools like Skyvia, Workato, Celigo and Boomi sit between the source and Acumatica. They are commonly used for staging-and-transform — the source is loaded into a warehouse, normalised against the Acumatica chart-of-accounts and Item Class taxonomy, then pushed into Acumatica. Skyvia specifically supports CSV import directly into Acumatica with INSERT, UPDATE, DELETE and UPSERT semantics.

Mapping is where every ERP migration earns its scars. The schema and sequencing decisions you make in your mapping spreadsheet determine whether the trial balance ties on day two, whether AR aging looks right on day five, and whether the warehouse believes the on-hand counts on day thirty.

Work top-to-bottom of the financial implementation order: Companies and Branches first, then the Chart of Accounts, then Subaccounts, then Customer and Vendor Classes, then Customers and Vendors, then Item Classes and Items, then opening trial balance, then open AR/AP documents, then inventory quantity-on-hand, then historical transactions if in scope ⁹⁷.

Chart of Accounts and Subaccounts

Export the demo Chart of Accounts to Excel as a template, replace the demo rows with your own Account IDs, Types, Classes, Currency and Active flags, and import via the Chart of Accounts form's native upload. Subaccount segments — Department, Cost Center, Branch, Product Line — are defined first on the Segmented Keys form (CS202000) and then the combined values on the Subaccounts form.

Get the segment count and length right before the first GL post; restructuring later is destructive and effectively requires a re-implementation.

GL opening balances and trial-balance cutover

The standard Acumatica technique is to post a single GL Journal Entry to the closing period of the prior year (e.g. period 12-2025) carrying every balance sheet account's closing balance, with the Income Statement accounts excluded — Acumatica auto-closes those to Retained Earnings when you roll into period 01-2026 and print the trial balance ¹⁵⁴. Debits must match credits; if they do not, the batch will not release.

Run this entry against a dedicated Migration Branch if multi-entity, and use Migration Mode on the AR, AP and Fixed Asset forms when entering opening subledger balances so those documents post to the subledger only and do not double-up the GL ¹²⁴. After all subledger opening balances are loaded, you turn Migration Mode off, reconcile each subledger to its control account in the trial balance, and only then open period 01 of the live year.

Customers, Vendors, and open AR/AP

Customer and Vendor masters import cleanly through Import Scenarios once Customer Classes and Vendor Classes are pre-created — Class drives the default GL accounts (AR Account, Discount Account, Cash Discount Sub), tax categories, and payment terms.

Missing class defaults are the single most common failure mode: a Vendor import will throw 'Cash Discount Account' cannot be empty. 'Cash Discount Sub.' cannot be empty. and stall until you either fix the Class or hard-code the discount account in the scenario value column ⁸⁴.

Inventory items, BOM, and quantity-on-hand

Stock and Non-Stock items are imported through Import Scenarios against the Stock Items (IN202500) and Non-Stock Items (IN202000) forms. Item Class must exist first and drives default valuation method, posting class, base UoM, lot/serial settings and price/cost classes.

Inventory IDs are stored respecting the configured Item Code mask (often 20 unicode characters) and must conform to that mask — cascading 'the record couldn't be imported due to an error in the next record' errors usually trace back to an inventory code containing a forbidden special character that the Class mask rejects ⁸³.

Opening quantity-on-hand is loaded after items are created, via the Inventory Receipts form (IN301000) or — historically — via the *Initialize Inventory* process. Recent Acumatica releases moved the canonical QoH-load path into Inventory Receipts with a special posting class that hits a clearing account rather than the COGS or Inventory account directly, so the GL entry stays neutral ¹⁵⁹.

Bill of Material rows on the Manufacturing edition are imported through a separate scenario against the BOM form (AM208000) and reference Inventory IDs that must already exist as Stock Items with a Base UoM matching the BOM's operation UoM. Revision and effective-dating come along; production-order history is typically *not* migrated — only open work orders.

Multi-currency and historical exchange rates

Acumatica stores exchange rates by (CurrencyID, FromCurrency, RateType, EffectiveDate). Historical rates must be loaded for every (date, currency, rate-type) combination referenced by an opening document or the document will be revalued at the current spot rate and produce a translation gain/loss against the trial-balance reconciliation. Export the full historical rate table from the source and import it via the Currency Rates form (CM301000) before the AR/AP open-document load.

Period close and revaluation run on the fiscal calendar configured under Financial → Configuration → Fiscal Year — get the period count, period numbering and adjustment-period flag right before posting starts. Adjustments to closed periods require an explicit reopen by a user with the appropriate finance role.

Historical activities, notes, and attachments

Historical activities (calls, tasks, events, notes) associated with Customers, Vendors and Opportunities import through scenarios against the CRM screens, but they re-stamp the CreatedDateTime to import time on standard paths — the original timestamp must be captured in a UsrLegacyCreatedDateTime custom field if reporting relies on it ¹⁴².

File attachments are bound to records through the platform-wide attachment subsystem. The default File Upload Preferences (SM202550) cap is 25 MB per file; larger files require either the cap to be raised or external storage ¹⁰⁴. Acumatica supports Azure Blob, AWS S3 and Google Cloud Storage as external file providers — Acumatica stores a pointer and the binary lives outside the database ¹⁰³.

For large attachment estates (hundreds of GB) the pattern most teams adopt is external storage from day one, with a backfill script that bulk-uploads the binaries into the configured external store before Acumatica pointers are loaded.

Audit trail, ownership and original timestamps

Acumatica's Field-Level Audit feature (Configuration → Audit) tracks per-field before/after values *going forward* once enabled on a screen, but it does not retroactively reconstruct source-system history. The AuditHistory DAC stores ModifiedFields, user and timestamp, and is queryable through Generic Inquiries with the *Field-Level Audit* role assigned ¹³².

On bulk import, the standard CreatedDateTime, LastModifiedDateTime, CreatedByID and LastModifiedByID columns are stamped by the framework — they cannot be overridden through Import Scenarios on the standard screens. The mitigation is to add a pair of custom fields (UsrLegacyCreatedDateTime, UsrLegacyCreatedBy) on every DAC where the audit trail matters, populate them from the source export, and rewrite any historical-period reports to use the legacy fields rather than the system columns.

ERP-specific: Customization Projects, Generic Inquiries, Snapshots

Customization Projects do not import from any source — they are rebuilt against the destination DACs. Plan to spend the first sprint of the project enumerating every customisation on the source system (custom fields, screen extensions, automation steps, workflows, custom reports) and triaging them into Migrate / Replace-with-standard / Retire. Acuminator, Acumatica's Visual Studio analyser, is the recommended tool for any C# extension work ⁴¹.

Generic Inquiries (SM208000) — the platform's no-code data-view builder — are the foundation of dashboards, OData feeds and many ad-hoc reports. Plan to rebuild key GIs in sandbox during cutover prep so finance has a working trial balance, AR aging and inventory valuation report from day one. Snapshots (System Management → Snapshots) are the standard way to clone a sandbox tenant for training, parallel testing or rollback; deleted snapshots are gone permanently unless exported to a workstation first ¹²³.

Validation is the bridge between Import Scenarios completing and finance being allowed to post into the live ledger. Acumatica's own F110 Data Migration course recommends three validation stages: a sandbox dry-run with 10 percent of records and stakeholder spot-checks, the full load with real-time reconciliation against source counts and balances, and a 30-day post-go-live data-quality audit including the first month-end close ⁹⁷.

Build a reconciliation pack using Generic Inquiries — one per object — that compares source totals against destination totals on each of these dimensions. Anything outside a tolerance you agreed with the controller in advance (typically zero for cash, $1 for AR/AP balances, $50 for inventory valuation) gets investigated before users get login access.

• Trial balance by account by period vs. source — debits and credits must tie to the cent on every Branch and every Currency.
• AR aging by customer by bucket vs. source — opening AR balance per customer per aging bucket, summed and compared.
• AP aging by vendor by bucket vs. source — opening AP balance per vendor per aging bucket, summed and compared.
• Inventory quantity on hand by warehouse by item vs. source — units and valuation must reconcile, with cost layers (FIFO, average, standard) explained.
• Customer and Vendor master record count vs. source — minus deliberately excluded rows (inactive accounts older than retention threshold, dedup merges).
• Open Sales Orders and Purchase Orders with header totals and line counts — by status, owner and date bucket.
• Currency rates per (CurrencyID, RateType, EffectiveDate) present for every date referenced by an open document — missing rates cause silent revaluation at spot.

On top of GI-driven reconciliation, run a manual spot-check protocol: pick 30 random records across Customers, Vendors and Items, and verify each field against the source UI. Pick five high-value AR invoices and five high-value AP bills and trace the full document — header, lines, taxes, applications. If a non-trivial discrepancy shows up in three or more of the 30, halt the cutover, fix the root cause in the Import Scenario, restore the snapshot, and re-run.

Acumatica's native rollback is the Snapshot subsystem. The standard pattern: take a Snapshot of the empty configured tenant before any data load, run the full import, validate, and if catastrophe strikes restore the Snapshot and re-run ¹²³. Export the Snapshot to a workstation before deleting it.

There is no native row-level undo for an Import Scenario — you either restore the Snapshot or build a delete Import Scenario keyed on an UsrImportBatchID custom field stamped on every loaded row.

Cutover sequencing: (1) source goes read-only at end-of-business on Friday; (2) source closes its final period; (3) final delta export captures everything that changed during the dry-run window; (4) configured Acumatica tenant snapshot is taken; (5) Import Scenarios run in the documented order — Accounts → Subaccounts → Classes → Customers → Vendors → Items → opening trial balance → open AR → open AP → on-hand inventory → optional historical detail.

Then: (6) reconciliation GIs run; (7) Migration Mode flags flipped off; (8) controller signs off; (9) users get login access Monday morning with a 48-hour hyper-care window; (10) source system kept in read-only mode for 90 days, then decommissioned.

Acumatica is sold and implemented exclusively through a channel of VARs, ISVs and consultancies — there is no direct-sales motion. Partners are tiered Gold, Silver and Bronze by certification and revenue, with edition specialisations (Manufacturing, Distribution, Construction, Field Service). For finance-heavy migrations specifically, partners with a published Sage 300 → Acumatica, Dynamics GP → Acumatica or NetSuite → Acumatica practice tend to ship cleaner than generalist implementers because they have already met the specific subledger mapping gotchas.

Named Gold-certified partners visible in the public partner directory include Blytheco, NexTec Group, Cortekx HGL, PC Bennett Solutions, Cloud 9 ERP Solutions, Prometheus Technology Services and Revive ERP — each offers fixed-scope migration packages alongside ongoing managed services and edition-specific add-ons. ISV partners on the Acumatica Marketplace add depth in narrow verticals (process manufacturing, e-commerce connectors, payroll, document management) that often get woven into the migration scope.

On the ETL and iPaaS side, Skyvia, Workato, Celigo, Boomi, MuleSoft, Fivetran and Airbyte all have Acumatica connectors. Their role in a migration is rarely the migration itself — it is the staging layer that lands source data into a warehouse, the transformation layer that converts picklist codes and resolves Customer Classes, and the ongoing-sync layer that takes over post-migration.

Skyvia is the most commonly cited tool for direct CSV-into-Acumatica loads with full INSERT, UPDATE, DELETE and UPSERT semantics.

Managed-migration cost ranges vary widely. Acumatica's own consulting rate ranges from $150 to $300 per hour, with integrations costing $1,000 to $15,000 depending on complexity and number of source systems. A clean QuickBooks-to-Acumatica financials-only migration of under 25,000 records often lands in the $10,000–$25,000 range with a fixed setup fee plus per-object pricing.

A Dynamics GP-to-Acumatica project with multi-entity GL, open AR/AP, inventory cutover and three years of historical drilldown typically runs $40,000–$200,000, with the upper end driven by record count, custom-field complexity, historical-data depth and the number of integrations rebuilt rather than re-pointed.

For teams that want to outsource the migration end-to-end, FlitStack specialises in Acumatica migrations and handles the chart-of-accounts mapping, GL opening-balance design, Import Scenario authoring, picklist code conversion, multi-currency rate-history load, and reconciliation work described in Sections 5 and 7 of this guide. Pricing is fixed-fee, based on record count, source platform and edition, with separate line items for Custom DAC extensions, Generic Inquiry rebuilds and historical-data depth so the scope is transparent before signature.

This is one of several legitimate paths — the right choice for any given team depends on whether they want a Gold-certified partner with edition specialisation, an iPaaS-first approach, an ISV bundled with the implementation, or a specialist migration vendor. Explore FlitStack →