ERP migration
Field-level mapping, validation, and rollback between Access ERP and Acumatica. We move data and schema; workflows are rebuilt natively in Acumatica.
Access ERP
Source
Acumatica
Destination
Compatibility
13 of 14
objects map 1:1 between Access ERP and Acumatica.
Complexity
BStandard
Timeline
3–6 months
Overview
Access ERP and Acumatica share a modular ERP foundation — both track customers, suppliers, inventory items, and GL accounts — but their schema conventions diverge sharply. Access ERP uses flat segment-style account codes with a built-in report designer and per-user pricing. Acumatica uses a branch-aware chart of accounts, Generic Inquiries (saved searches) for custom reporting, and a resource-consumption pricing model that does not charge per seat. The migration carries all master data (customers, suppliers, items, GL accounts) and transactional history (open sales orders, AP/AR balances, inventory on-hand) into Acumatica's normalized table structure. Workflows, approval chains, custom report definitions, and Access-specific alert rules do not migrate — those must be rebuilt in Acumatica's screen-level automation framework or with Acumatica consultants post-go-live. FlitStack sequences the load so foreign-key dependencies resolve correctly: accounts first, then customers and suppliers, then inventory items, then open transactions. A delta-pickup window captures any records modified 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 Access ERP 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.
Access ERP
Customer / Account
Acumatica
Customer
1:1Access ERP customers map directly to Acumatica Customer records. Acumatica uses a single customer table with a CustomerClass that determines default terms and tax settings. Customers must be loaded before any open AR or sales-order records, because Acumatica enforces the CustomerID foreign key at insert time. Address records in Access ERP translate to Acumatica Address rows attached to the Customer through the AddressID link.
Access ERP
Supplier / Vendor
Acumatica
Vendor
1:1Access ERP suppliers become Acumatica Vendor records. Acumatica Vendor includes default PaymentTerms, TaxZone, and RemittanceAccount settings that Access stores as supplier-level fields. We map the Access supplier classification (e.g., 'preferred', 'one-time') to a custom VendorClass in Acumatica if no standard class matches. Supplier contacts migrate to VendorContact records with email, phone, and role preserved.
Access ERP
Inventory Item / Stock Item
Acumatica
Inventory Item (Non-Stock or Stock Item)
1:1Access ERP inventory items map to Acumatica Stock Items (for inventory-tracked goods) or Non-Stock Items (for service parts and materials). The ItemClass in Acumatica controls posting accounts (COGS, Inventory, and Revenue), so we map Access item categories to the closest Acumatica ItemClass during migration. If Access uses lot/serial tracking, we create matching Lot/Serial classes in Acumatica before items load.
Access ERP
GL Account (header row)
Acumatica
Account (chart of accounts)
1:1Access ERP account codes map to Acumatica Account records. The AccountID in Acumatica is the primary key used in journal entries and trial-balance reporting. We strip any embedded segment data from Access account codes and load them as pure Account numbers in Acumatica. The AccountType (Asset, Liability, Equity, Revenue, Expense) maps directly to the Acumatica Account type enumeration.
Access ERP
GL Subaccount / Account Segment
Acumatica
Subaccount
1:manyAccess ERP embeds organizational hierarchy in account code segments (e.g., 4000-100-00 encodes Division and Region). We decompose each segment into a separate Subaccount row in Acumatica. The posting combination of Account + Subaccount (and optionally Branch/Department) forms the full posting key used in journal entries. Each unique segment value from Access becomes a Subaccount with a meaningful Description derived from the segment label.
Access ERP
Sales Order (Open)
Acumatica
Sales Order
1:1Open Access ERP sales orders migrate to Acumatica Sales Orders with status 'Open' preserved. Order dates, requested dates, and promised dates map to corresponding Acumatica order fields. The CustomerID and Ship-To address link to the migrated customer and address records. Line items reference migrated inventory items by InventoryID. Completed orders are migrated as historical records with a 'Completed' status flag.
Access ERP
Purchase Order (Open)
Acumatica
Purchase Order
1:1Open Access ERP purchase orders migrate to Acumatica Purchase Orders. The VendorID links to the migrated vendor. Line items map to the migrated inventory item by InventoryID. Expected delivery dates and purchase account assignments are preserved. Historical (completed) purchase orders are migrated as reference records without affecting open AP balances.
Access ERP
AR Invoice / Credit Memo
Acumatica
AR Invoice
1:1Access ERP AR invoices and credit memos migrate to Acumatica AR Invoice and Credit Memo records. The customer reference number is preserved in the ExternalRef field for cross-system reconciliation. Open invoices carry a balance in Acumatica's AR register. Credit memos are linked to the original invoice where a reference exists in Access. The invoice date, due date, terms, and tax amount map directly.
Access ERP
AP Invoice / Credit Memo
Acumatica
AP Invoice
1:1Access ERP AP invoices and credit memos migrate to Acumatica AP Invoice and Credit Memo records. Vendor reference numbers are preserved in the VendorRef field. Open AP balances land in Acumatica's AP register with the same due date and payment terms. Prepayments from Access ERP are migrated as AP Payment applications in Acumatica.
Access ERP
GL Journal Entry (historical)
Acumatica
Journal Transaction
1:1Access ERP journal entries migrate to Acumatica Journal Transactions using the migrated Account + Subaccount combination. Each line in the Access journal becomes a separate JournalLine row in Acumatica. Original entry dates and descriptions are preserved. If Access stores the batch number, we create a matching BatchNbr in Acumatica. Year-end closing entries are migrated with the 'Released' flag set to preserve audit trail continuity.
Access ERP
Inventory On-Hand / Warehouse Stock
Acumatica
Inventory Summary (by Warehouse)
1:1Access ERP warehouse stock levels map to Acumatica Inventory Summary records by WarehouseID and InventoryID. The OnHandQty, AvailableQty, and CostperUnit are extracted from Access's stock table and loaded into Acumatica's INSiteStatus table. If Access uses multiple warehouses, we create matching Branch/Warehouse records in Acumatica and distribute the on-hand quantities accordingly.
Access ERP
Bill of Materials (BOM)
Acumatica
Bill of Materials
1:1Access ERP BOMs map to Acumatica BOM records with multi-level structure preserved. Each BOMLine references the child InventoryID and the QtyPer quantity. Phantom BOMs in Access become PhantomBOM = true in Acumatica. If Access BOMs use operation steps (routings), those map to the Acumatica Labor and Machine overhead codes attached to the BOM revision. BOM revision effective dates map to the BOM Version's EffStartDate and EffEndDate.
Access ERP
User / Owner / Employee
Acumatica
Employee / Contact (for non-employee owners)
1:1Access ERP users and owners who are assigned to records are resolved by email match against Acumatica users. Non-employee owners who cannot be matched to an Acumatica user are migrated as Contact records with a custom 'SourceOwner' flag set to true, so the owner association is preserved for reporting even without a login. This prevents records from landing with a null OwnerID.
Access ERP
Custom Field / User-Defined Field
Acumatica
Custom Field (attribute on standard object)
1:1Access ERP custom fields that extend standard tables (customer UD fields, item UD fields) are created as Acumatica custom attributes using the Customization project framework. The attribute is defined with the same data type (string, number, date, list) and attached to the target DAC (Data Access Class) in Acumatica. We generate the Acumatica customization project XML so it can be published in the target tenant before data migration runs.
| Access ERP | Acumatica | Compatibility | |
|---|---|---|---|
| Customer / Account | Customer1:1 | Fully supported | |
| Supplier / Vendor | Vendor1:1 | Fully supported | |
| Inventory Item / Stock Item | Inventory Item (Non-Stock or Stock Item)1:1 | Fully supported | |
| GL Account (header row) | Account (chart of accounts)1:1 | Fully supported | |
| GL Subaccount / Account Segment | Subaccount1:many | Fully supported | |
| Sales Order (Open) | Sales Order1:1 | Fully supported | |
| Purchase Order (Open) | Purchase Order1:1 | Fully supported | |
| AR Invoice / Credit Memo | AR Invoice1:1 | Fully supported | |
| AP Invoice / Credit Memo | AP Invoice1:1 | Fully supported | |
| GL Journal Entry (historical) | Journal Transaction1:1 | Fully supported | |
| Inventory On-Hand / Warehouse Stock | Inventory Summary (by Warehouse)1:1 | Fully supported | |
| Bill of Materials (BOM) | Bill of Materials1:1 | Fully supported | |
| User / Owner / Employee | Employee / Contact (for non-employee owners)1:1 | Fully supported | |
| Custom Field / User-Defined Field | Custom Field (attribute on standard object)1: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.
Access ERP gotchas
No published pricing or online trial
Highly configurable schema creates hidden custom fields
Quarterly upgrade cadence can change field names mid-project
Bank reconciliation cut-off requires explicit stakeholder decision
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
Assess Access ERP data inventory and schema
FlitStack inventories all Access ERP tables that contain business data — customers, suppliers, items, GL accounts, subaccounts, open orders, open invoices, inventory on-hand, and BOM structures. We profile record counts, identify duplicate and null-field rates, and flag any circular subaccount references (where Access stores a parent-account reference within the subaccount segment). The output is a Data Readiness Report with a field-level mapping draft that names every Access table and column, their Acumatica equivalents, and any transformation logic required. This report drives the Acumatica configuration planning session.
Configure Acumatica chart of accounts and branches
Before any data loads, Acumatica's chart of accounts must be set up to receive the Access GL structure. FlitStack delivers an Account Configuration Plan that specifies: (a) the Account records to create from Access GL headers, (b) the Subaccount decomposition strategy chosen by the customer (flat Sub, multi-Sub combination, or Branch-based split), and (c) any Branch or Department records required if Access uses multiple companies or warehouses. The Acumatica admin (or our team) creates these records so they exist before the migration batch runs. If the Access chart uses more than 5 subaccount segments, we recommend creating Subaccount screens in advance to avoid load-order failures.
Load master data in dependency order
FlitStack executes the migration in a strict sequence: (1) Account records, (2) Subaccount records, (3) Customer records and Address rows, (4) Vendor records, (5) Inventory Item records with ItemClass assignments, (6) Inventory On-Hand quantities by warehouse, (7) BOM and routing structures, (8) Open AP and AR invoices, (9) Open Sales and Purchase orders. Each batch is validated against Acumatica's foreign-key constraints before the next batch opens. Owner resolution by email match runs in parallel — any Access owner without an Acumatica user match is flagged and assigned to a fallback contact so no record lands with a null owner.
Run sample migration with field-level diff
A representative sample — typically 200–500 records spanning the full object range — migrates first. FlitStack generates a field-level diff report comparing source values against destination values for each record. The customer reviews the diff to verify that: (a) account and subaccount combinations are correct, (b) customer and vendor balances match the Access trial-balance figures, (c) inventory on-hand quantities by warehouse are accurate, and (d) owner resolution worked for all but the flagged exceptions. No full migration run begins until the sample diff is signed off.
Execute full migration with delta-pickup cutover
The full migration batch runs against the production Acumatica tenant. A delta-pickup window — typically 24–48 hours — captures any records created or modified in Access ERP during the cutover (new sales orders entered while the migration ran, updated customer addresses, new AP invoices). After the delta window closes, FlitStack generates a reconciliation report comparing total record counts and balance totals between Access and Acumatica. An audit log records every insert, update, and skip operation. One-click rollback is available if reconciliation reveals discrepancies above the agreed tolerance threshold (default: 0.1% of total balance).
Deliver Generic Inquiry and workflow rebuild reference
After go-live, FlitStack delivers the Access Workflow Reference document and the Generic Inquiry Specification Sheet. The workflow document lists every Access automation rule by screen name, condition, and action so the Acumatica admin can rebuild each rule in the Automation Engine. The GI specification sheet provides SQL join templates for the 10 most-used Access reports, including join paths between Account, Sub, Branch, FinPeriod, Customer, and Vendor tables. Rebuild of workflows and Generic Inquiries is a separate configuration engagement outside the data-migration scope.
Platform deep dives
Access ERP
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 Access ERP 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
Access ERP: Not publicly documented.
Data volume sensitivity
Access ERP doesn't expose a bulk API — REST + parallelization used for high-volume runs.
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 Access ERP to Acumatica migration scoping. Not seeing yours? Book a call.
Walk through your Access ERP 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 Access ERP
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.