ERP migration

Migrate from Access ERP to Acumatica

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

Access ERP logo

Access ERP

Source

Acumatica

Destination

Acumatica logo

Compatibility

93%

13 of 14

objects map 1:1 between Access ERP and Acumatica.

Complexity

BStandard

Timeline

3–6 months

Rollback included Accuracy guarantee Field-level validation

Overview

What this migration involves

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.

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

Access ERP logo

Access ERP

What's pushing teams away

  • Transition from a legacy ERP involves significant user training and process change management — some teams find the steep learning curve disruptive to daily operations.
  • A subset of users experienced longer-than-expected support response times, especially for complex issues requiring escalation beyond first-line support.
  • Organizations with highly unique workflows report that the platform requires custom code modifications, adding implementation cost beyond the initial subscription.
  • Some customers desire more visibility into The Access Group's ERP product roadmap and enhancement priorities before committing to a long-term platform relationship.
  • Mid-market ERP customers sometimes outgrow Access ERP and migrate to NetSuite or SAP S/4HANA when they require the scale or global features of a Tier 1 system.

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 Access ERP objects map to Acumatica

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

maps to

Acumatica

Customer

1:1
Fully supported

Access 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

maps to

Acumatica

Vendor

1:1
Fully supported

Access 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

maps to

Acumatica

Inventory Item (Non-Stock or Stock Item)

1:1
Fully supported

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

maps to

Acumatica

Account (chart of accounts)

1:1
Fully supported

Access 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

maps to

Acumatica

Subaccount

1:many
Fully supported

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

maps to

Acumatica

Sales Order

1:1
Fully supported

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

maps to

Acumatica

Purchase Order

1:1
Fully supported

Open 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

maps to

Acumatica

AR Invoice

1:1
Fully supported

Access 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

maps to

Acumatica

AP Invoice

1:1
Fully supported

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

maps to

Acumatica

Journal Transaction

1:1
Fully supported

Access 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

maps to

Acumatica

Inventory Summary (by Warehouse)

1:1
Fully supported

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

maps to

Acumatica

Bill of Materials

1:1
Fully supported

Access 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

maps to

Acumatica

Employee / Contact (for non-employee owners)

1:1
Fully supported

Access 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

maps to

Acumatica

Custom Field (attribute on standard object)

1:1
Fully supported

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

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.

Access ERP logo

Access ERP gotchas

High

No published pricing or online trial

High

Highly configurable schema creates hidden custom fields

Medium

Quarterly upgrade cadence can change field names mid-project

Medium

Bank reconciliation cut-off requires explicit stakeholder decision

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

  • Account and subaccount load order is a hard dependency chain — inserting records before accounts exist causes foreign-key failures

    Acumatica enforces referential integrity at the database level for journal entries, customer records, and vendor records. A journal transaction line cannot reference an AccountCD that does not yet exist in the Account table. An AR invoice cannot reference a CustomerID that has not been loaded. In Access ERP, accounts and customers may have been added over years with no enforced load sequence. FlitStack sequences the migration as a strict dependency chain: Account records → Subaccount records → Customer records → Vendor records → Item records → Open AR/AP → Open Sales/Purchase Orders → Journal History. Violating this order produces insert errors in Acumatica that require a rollback and re-run of the failed batch. We validate the dependency graph before each batch commits.

  • Access ERP's embedded subaccount segments require decomposition into Acumatica's separate Sub table before posting definitions can work

    Acumatica separates account structure from posting combination logic. The Account table holds the main account number and type; the Sub table holds each sub-segment as an independent row with its own SubCD and Description; the PostAccount table (or screen-level combination) joins them. Access ERP customers who use multi-segment account codes (e.g., 5100-020-01 for Revenue by Region by ProductLine) must decide how to decompose those segments before migration. If all three segments are compressed into the AccountCD, Acumatica cannot use Sub-based reporting or branch-level posting combinations. FlitStack surfaces the decomposition options — flat Acumatica Subaccounts, or a multi-Sub combination — and applies the chosen strategy before any journal entry loads.

  • Acumatica's Generic Inquiries replace Access ERP's report designer, and building equivalent saved searches requires consultant-level SQL knowledge

    Access ERP ships with a built-in report designer that power users can operate without SQL knowledge. Acumatica's equivalent — Generic Inquiries — requires constructing SQL JOINs across related DACs (Data Access Classes) to replicate the same output. A typical Access financial summary report requires an Acumatica Generic Inquiry that joins Account, Sub, Branch, FinPeriod, and GLSetup tables. Teams migrating from Access frequently underestimate the effort required to rebuild custom reports; some organizations require 10–15 Generic Inquiries post-go-live. FlitStack documents every Access report definition and delivers a Generic Inquiry specification sheet as part of the migration package, but the actual GI creation in Acumatica requires either consultant hours or significant internal SQL investment.

  • Workflow automations, approval chains, and Access ERP alert rules do not migrate and require screen-level rebuilding in Acumatica

    Access ERP workflows — such as purchase-order approval thresholds, sales-order credit-hold rules, or inventory-reorder alerts — are stored in the application layer and have no equivalent in Acumatica's data model. Acumatica handles equivalent logic through its Automation Engine (screen-level workflows), Business Events, and notification templates. A purchase-order approval rule in Access ERP that routes PO > $10,000 to a manager for sign-off must be rebuilt as an Acumatica Automation Step with the same conditions and assignee logic. FlitStack exports the Access workflow definitions as a text reference document that documents the rule name, condition, and action, but the rebuild is a separate configuration effort in Acumatica after go-live.

  • Acumatica's resource-consumption pricing requires right-sizing the transaction tier before migration — choosing the wrong tier causes throttling during cutover

    Acumatica's pricing is tied to monthly transaction volume (Small = up to 2,000 transactions, Medium = up to 5,000, Large = up to 20,000, Extra Large and Enterprise beyond that). During the migration run, FlitStack generates a burst of API operations that write records in quick succession. If the destination tenant is on a Small or Medium tier, the migration can hit Acumatica's concurrency limits mid-run, causing timeouts on batch commits. We request a temporary tier upgrade from Acumatica (or the VAR) before the migration window opens, then step back down to the correct tier after go-live reconciliation. This requires coordination with the VAR 2–3 weeks before the cutover date.

Migration approach

Six steps for a successful Access ERP to Acumatica data migration

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

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

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

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

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

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

Context on both ends of the pair

Access ERP logo

Access ERP

Source

Strengths

  • Cloud-hosted ERP with integrated financials, inventory, purchasing, and CRM modules under a single vendor
  • Modular deployment lets mid-market manufacturers add capability incrementally without a full system replacement
  • Quarterly automated upgrades keep the platform current without requiring manual patching or project overhead
  • Competitive mid-market positioning relative to Tier 1 systems like SAP and Oracle
  • Established UK-based vendor with 150,000+ customer organizations and a broad ecosystem of implementation partners

Weaknesses

  • No public pricing — sales-led quote process makes cost comparison with competitors difficult before engagement
  • Steep learning curve reported during transition from legacy systems, requiring significant change management investment
  • Customizations for unique workflows may incur additional developer costs beyond standard subscription
  • Support responsiveness concerns flagged by a subset of users, particularly for escalated or complex issues
  • Roadmap transparency is limited, making it hard for customers to plan their own system roadmap around Access Group priorities
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 Access ERP 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

    Access ERP: Not publicly documented.

  • Data volume sensitivity

    B

    Access ERP doesn't expose a bulk API — REST + parallelization used for high-volume runs.

Estimator

Estimate your Access ERP 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 Access ERP to Acumatica data migrations

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

Can't find your answer?

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 consultation

Most Access ERP to Acumatica migrations complete in 3–6 months of total project time for mid-size manufacturers with 50,000–200,000 records. The data assessment and chart-of-accounts configuration phase typically takes 4–8 weeks. The migration run itself (sample plus full batch) runs in 48–72 hours of clock time. Post-go-live Generic Inquiry and workflow rebuild adds 4–12 weeks depending on the number of custom Access reports and automation rules. Setups with heavy multi-segment account codes or complex BOM hierarchies extend the timeline to 6–9 months.

Adjacent paths

Related migrations to explore

Ready when you are

Move from Access ERP.
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