ERP migration
Field-level mapping, validation, and rollback between Base ERP and Acumatica. We move data and schema; workflows are rebuilt natively in Acumatica.
Base ERP
Source
Acumatica
Destination
Compatibility
15 of 15
objects map 1:1 between Base ERP and Acumatica.
Complexity
BStandard
Timeline
48–72 hours
Overview
Base ERP typically handles inventory control, order management, and basic financials for SMB and mid-market operations — often with simpler chart-of-accounts structures, flat warehouse locations, and per-user or flat-fee pricing that caps out as transaction volume grows. Acumatica Cloud ERP replaces that ceiling with consumption-based licensing tied to compute resources rather than user seats, multi-entity ledgers, branch-aware inventory locations, and industry-specific configurations for construction job costing, distribution warehousing, and manufacturing routings. FlitStack AI migrates Base customers, vendors, inventory items with stock quantities, open sales orders, purchase orders, and GL account balances into their corresponding Acumatica entities. Workflows, approval chains, and scheduled automations built inside Base do not carry over — we export the definitions as a rebuild reference for Acumatica business events and screens. Acumatica's REST API and Data Migration Toolkit handle the ingestion, with our delta-pickup window capturing any in-flight orders during the cutover window. All migrated records undergo field-level validation to ensure data integrity before the final cutover is executed.
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 Base 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.
Base ERP
Customer
Acumatica
Customer
1:1Base Customer maps to Acumatica Customer (BAccount with Customer type). We preserve the Base customer ID in CustomerExt.NoteID for traceability. Primary address and contact email transfer as the default location. Tax zone assignments in Acumatica must be set by your tax configuration — we flag any Base tax jurisdiction that lacks a matching Acumatica TaxZone.
Base ERP
Vendor
Acumatica
Vendor
1:1Base Vendor maps to Acumatica Vendor (BAccount with Vendor type). Remit-to address and 1099 flag carry over. Multi-site vendors in Base with different PO addresses require multiple Acumatica locations — we create the primary location and flag additional addresses for manual branch assignment.
Base ERP
Inventory Item
Acumatica
Stock Item
1:1Base inventory items with stock-tracking enabled become Acumatica Stock Items. Items marked as non-stock in Base create Non-Stock Items or Service Items in Acumatica based on the item type flag. Base item class (valuation method, posting group) maps to Acumatica ItemClass with its own valuation method and deferred revenue settings.
Base ERP
Warehouse Location
Acumatica
Warehouse / Sublocation
1:1Base flat warehouse codes become Acumatica Warehouse records scoped by Branch. If Base tracks bin locations within a warehouse, we create Acumatica Warehouse Locations under the corresponding branch — your warehouse manager configures the location type (bin, shelf, pallet) post-migration in Acumatica's IN205000 screen.
Base ERP
Sales Order (Open)
Acumatica
Sales Order
1:1Open Base sales orders migrate to Acumatica SO301000 with original order dates, customer references, and line items. Order statuses carry over using SO.Status field values. Completed or invoiced orders do not migrate — their invoice history appears as AR Invoice records in Acumatica.
Base ERP
Purchase Order (Open)
Acumatica
Purchase Order
1:1Open Base purchase orders migrate to Acumatica PO301000 preserving vendor, line items, quantities, and promised delivery dates. PO status mapping follows the same logic as sales orders, with status codes translated to Acumatica equivalents. Historical closed POs are not migrated — vendor ledger history transfers via the AP Invoice records that represent the posted payables.
Base ERP
AR Invoice / Credit Memo
Acumatica
AR Invoice / Credit Memo
1:1Open AR invoices from Base transfer to Acumatica AR301000 with original invoice date, due date, terms, and balance. Credit memos migrate separately. We preserve the Base document number as a reference. Paid invoices older than the retain-history window are archived externally.
Base ERP
AP Invoice / Credit Memo
Acumatica
AP Invoice / Credit Memo
1:1Open AP invoices from Base transfer to Acumatica AP301000 with original document dates and due amounts. Vendor reference numbers map to Acumatica's ExtRefNbr field for cross-system matching and audit trails. Prepayments and unapplied payments in Base migrate as miscellaneous payments with explicit allocation records to maintain proper payables structure in Acumatica.
Base ERP
Chart of Accounts
Acumatica
GL Account
1:1Base GL accounts map to Acumatica GLAccount with Active flag, Type (Asset/Liability/Revenue/Expense/Header), ClassID, and BranchID assignments. Subaccounts in Base become Acumatica segment values in a configured subaccount dimension. Acumatica requires at least one active account in each Type — we flag gaps before migration.
Base ERP
Journal Entry
Acumatica
Journal Transaction
1:1Base manual journal entries migrate as Acumatica GL Transactions in GL301000 with original posting date, description, and line-level debits/credits. Recurring journal templates in Base do not carry over — we export the recurrence schedule as a reference for Acumatica's recurring schedule configuration.
Base ERP
Payment Terms
Acumatica
Cash Discount / Payment Rule
1:1Base payment term codes (Net 30, 2/10 Net 30, etc.) map to Acumatica CashDiscount records linked to Terms entities. Custom Base terms get recreated as Acumatica Terms with the same due days and discount percentage — your AP manager reviews the Terms screen before go-live.
Base ERP
Shipment / Receiving Record
Acumatica
Shipment / Receipt
1:1Closed Base shipments and receipts that have not yet been invoiced migrate as Acumatica Shipments (SO302000) and Receipts (PO302000) respectively, preserving original shipment dates and quantities. Any shipment or receipt already linked to an invoice in Base is already represented in AR/AP and is not duplicated in the migration — the invoice record carries forward instead.
Base ERP
Custom Field (Entity-level)
Acumatica
Custom Field / UDF
1:1Base user-defined fields on Customer, Vendor, or Inventory entities require Acumatica schema extensions. We create the UDF as a DAC field on the corresponding Acumatica entity with matching data type. Validation rules, pick-list values, and display names are mapped per the Acumatica customization project spec.
Base ERP
User / Owner
Acumatica
Employee / User
1:1Base users with transactional ownership (sales reps, order processors) resolve by email match against Acumatica users. Unmatched Base owners are flagged and assigned to a fallback employee until your admin creates the Acumatica user — no record lands without an owner assignment.
Base ERP
Attachment / File
Acumatica
File
1:1Base file attachments on inventory items, customer records, or orders are downloaded and re-uploaded to Acumatica's file storage. File size limits apply — files exceeding 25MB are noted for manual re-upload. Inline images in notes are extracted and stored as separate attachments.
| Base ERP | Acumatica | Compatibility | |
|---|---|---|---|
| Customer | Customer1:1 | Fully supported | |
| Vendor | Vendor1:1 | Fully supported | |
| Inventory Item | Stock Item1:1 | Fully supported | |
| Warehouse Location | Warehouse / Sublocation1:1 | Fully supported | |
| Sales Order (Open) | Sales Order1:1 | Fully supported | |
| Purchase Order (Open) | Purchase Order1:1 | Fully supported | |
| AR Invoice / Credit Memo | AR Invoice / Credit Memo1:1 | Fully supported | |
| AP Invoice / Credit Memo | AP Invoice / Credit Memo1:1 | Fully supported | |
| Chart of Accounts | GL Account1:1 | Fully supported | |
| Journal Entry | Journal Transaction1:1 | Fully supported | |
| Payment Terms | Cash Discount / Payment Rule1:1 | Fully supported | |
| Shipment / Receiving Record | Shipment / Receipt1:1 | Fully supported | |
| Custom Field (Entity-level) | Custom Field / UDF1:1 | Fully supported | |
| User / Owner | Employee / User1:1 | Fully supported | |
| Attachment / File | File1: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.
Base ERP gotchas
Inventory Control module is in public beta
Duplicate SKUs accumulate in long-running accounts
Marketplace connector credentials are non-exportable
Order export excludes records from paused connectors
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 Base ERP data using API and CSV export
FlitStack AI connects to Base ERP via its REST API and pulls all transactional and master data: customers, vendors, inventory items with stock quantities, open sales orders, open purchase orders, AR/AP invoices, GL account list, warehouse locations, and journal entries. We run parallel exports for independent entity groups to respect API rate limits. Each export is validated for row counts, null key fields, and referential integrity before the field mapping phase begins. Scoped read access is used — your team continues working in Base during the extraction window.
Deliver Acumatica schema setup specification and pre-map GL / branches
Before data moves, we deliver a schema setup document naming every Acumatica entity that must exist first: GL accounts in GL202500 with Type and ClassID, warehouse branches in WH203000 with branch assignments, item classes in IN202000, and tax zones in TX205000. Your Acumatica admin creates these records using the specification. We resolve any circular dependency (e.g., a branch needing a GL account that itself references the branch) and surface account collision risks so there are no surprises at import time.
Run sample migration with field-level diff for 100–500 representative records
A representative slice of Base data — typically 100–200 inventory items, 50–100 customers/vendors, 20–50 open orders, and a sample GL journal batch — migrates first into a sandbox Acumatica environment. We generate a field-level diff comparing source values to destination values so you can verify account mappings, tax zone assignments, payment term links, and cost layer conversions. You sign off on the sample before we commit to the full run. Any mapping adjustments are applied to the migration engine and a second sample validates the fix.
Execute full migration with sequenced entity loading and foreign key resolution
The full migration runs in dependency order: GL accounts and branches first, then customers and vendors (since they are referenced by transactions), then inventory items, then open orders and AP/AR invoices, then journal entries. Foreign key references resolve as each entity loads — if a customer ID in a Base invoice does not exist in Acumatica, the invoice is held in a staging queue until the customer loads, then processed. We track every record's Base ID in the destination NoteID field for post-migration reconciliation. API calls pace to stay within Acumatica's rate limits using exponential backoff.
Activate delta-pickup window and cut over with audit log
After the full migration commits, a delta-pickup window of 24–48 hours captures any Base records created or modified during the cutover — typically new sales orders or vendor invoices. We compare migration timestamps against Base's last-modified field and replay only the delta records. An audit log records every operation (insert, update, skip) with source record ID and destination record ID. If reconciliation fails any threshold check, one-click rollback reverts the Acumatica environment to its pre-migration snapshot so your team can investigate without data loss.
Platform deep dives
Base 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 Base 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
Base ERP: Not publicly documented.
Data volume sensitivity
Base 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 Base ERP to Acumatica migration scoping. Not seeing yours? Book a call.
Walk through your Base 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 Base 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.