ERP migration

Migrate from inoERP to Acumatica

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

inoERP logo

inoERP

Source

Acumatica

Destination

Acumatica logo

Compatibility

100%

14 of 14

objects map 1:1 between inoERP and Acumatica.

Complexity

BStandard

Timeline

48–72 hours of active migration clock time

Rollback included Accuracy guarantee Field-level validation

Overview

What this migration involves

inoERP is an open-source PHP and Go-based ERP that stores data in MySQL and exposes a JavaScript REST API for client-side customization. Its modules mirror SAP and Oracle R12 in naming conventions: General Ledger, Accounts Receivable, Accounts Payable, Inventory, Sales & Distribution, Purchasing, Manufacturing, and Human Resources. Acumatica is a cloud-native ERP that organizes data into Data Access Classes (DACs), uses User-Defined Fields (UDFs) for custom attributes, and accepts imports via its Import by Scenario framework, REST API, or direct SQL injection into staging tables. The migration carries all master data (customers, vendors, inventory items, chart of accounts) and transactional history (open AR/AP, sales orders, purchase orders, GL journal lines) into Acumatica, while custom scripts, inoERP workflows, and any custom database fields require manual recreation in Acumatica Studio. FlitStack AI sequences the load so foreign-key relationships resolve correctly — accounts before sub-ledgers, inventory items before transactions — and captures the delta window for records modified during cutover.

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

inoERP logo

inoERP

What's pushing teams away

  • The project management module is incomplete and underdeveloped, frustrating organisations that need integrated project tracking alongside operations.
  • Documentation is sparse and community support is limited, making troubleshooting configuration issues and customisation challenges time-consuming for self-hosted deployments.
  • The platform has undergone a major architecture migration from PHP to Go back-end with a Flutter front-end, creating confusion about which version to deploy and whether older PHP documentation still applies.
  • Hosting, maintaining, and securing a self-managed ERP falls on the customer's team, generating hidden labour costs that often exceed the savings from free licensing.

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

Each row shows how a inoERP 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.

inoERP

Customer

maps to

Acumatica

Customer

1:1
Fully supported

inoERP customers map directly to Acumatica Business Account (Customer class). Each inoERP customer site becomes an Acumatica Customer Location on the same Customer record. Primary email and billing address migrate as the default location; additional sites map to sub-locations with their own shipping addresses and GL delivery terms.

inoERP

Vendor

maps to

Acumatica

Vendor

1:1
Fully supported

inoERP vendors map to Acumatica Vendors. inoERP vendor sites map to Acumatica Vendor Locations. Payment terms, tax ID, and remittance address carry forward as Vendor attributes. Acumatica's Vendor class supports both AP-only vendors and customers that are also vendors — flagged from inoERP's supplier_type field.

inoERP

Inventory Item

maps to

Acumatica

Inventory Item (Non-Stock / Stock Item)

1:1
Fully supported

inoERP items classified as Stock map to Acumatica Stock Items with inventory tracking enabled. Non-stock items (services, materials without stock control) map to Non-Stock Items. The item's cost_method (standard, average, FIFO) maps to Acumatica's Cost Method field on the Inventory Item General tab. Default warehouse and last purchase price migrate as item defaults.

inoERP

BOM (Bill of Materials)

maps to

Acumatica

Bill of Materials (BOM & Formula)

1:1
Fully supported

inoERP BOMs map to Acumatica Bill of Materials records. Each inoERP BOM revision maps to an Acumatica BOM revision with an effective date. Component line quantities, scrap percentages, and material issue/overhead costs carry forward. Acumatica distinguishes between BOMs for manufacturing and formulas for batch processing — routed by inoERP's bom_type field.

inoERP

Work Order

maps to

Acumatica

Production Order

1:1
Fully supported

Open and historical inoERP work orders migrate as Acumatica Production Orders with their current status preserved (On Hold, In Process, or Completed). The linked BOM revision and production steps become the production order's operation list. Actual material consumption and labor bookings from inoERP are recorded as completed production transactions in Acumatica.

inoERP

GL Account

maps to

Acumatica

GL Account

1:1
Fully supported

inoERP chart of accounts entries map directly to Acumatica GL Accounts with the same account code, description, type (Asset, Liability, Expense, Income), and active/inactive status. inoERP's account segments map to Acumatica's segmented key structure — each inoERP segment becomes an Account Segment in Acumatica's COA configuration.

inoERP

GL Journal

maps to

Acumatica

Journal Transaction

1:1
Fully supported

Historical inoERP GL journal lines migrate as Acumatica Journal Transactions. Original document dates become the transaction date; the source module is stored in a custom reference field. Opening balances for active accounts are loaded as a single opening-balance journal entry rather than individual historical rows to avoid inflating record counts.

inoERP

Sales Order

maps to

Acumatica

Sales Order

1:1
Fully supported

Open inoERP sales orders migrate as Acumatica Sales Orders with their line items, quantities, and pricing. Order status (Draft, Open, Completed, Cancelled) maps to Acumatica's status codes. Historical orders with no remaining fulfillment obligation are summarized as completed records in Acumatica without creating active order rows.

inoERP

Purchase Order

maps to

Acumatica

Purchase Order

1:1
Fully supported

Open inoERP purchase orders migrate as Acumatica Purchase Orders. Vendor location, line items, quantities, and unit costs carry forward. inoERP PO approval status is recorded as a custom field in Acumatica because Acumatica handles approval workflows through its internal approval map, not as a data attribute — your Acumatica admin configures the approval map to match inoERP's workflow thresholds.

inoERP

Employee

maps to

Acumatica

Employee

1:1
Fully supported

inoERP employees map to Acumatica Employees with name, position, department, employment status, and hire date. Compensation and payroll data migrates to Acumatica Payroll (if the payroll module is active); otherwise it is exported as a reference file for manual configuration. Leave balances and approval hierarchies become Employee UDFs or are set up manually in Acumatica's HR module.

inoERP

AR Invoice / Credit Memo

maps to

Acumatica

AR Invoice / Credit Memo

1:1
Fully supported

Open inoERP AR documents (invoices, credit memos, prepayments) migrate as Acumatica AR Documents. The customer location and terms code map from inoERP's payment_term field. Historical paid documents are summarized — full document history is preserved in a reference export file; only open aging items create live Acumatica AR records to avoid inflating document counts.

inoERP

AP Invoice / Credit Memo

maps to

Acumatica

AP Invoice / Credit Memo

1:1
Fully supported

Open inoERP AP documents migrate as Acumatica AP Documents with vendor, invoice number, date, amount, and terms. Prepayments and credit memos carry their balance-forward amounts. Historical paid AP items are summarized into a reference archive export; open aging items create live Acumatica AP records.

inoERP

Asset Register

maps to

Acumatica

Fixed Asset

1:1
Fully supported

inoERP asset records (fixed assets with depreciation schedules) map to Acumatica Fixed Assets. Asset class, acquisition date, cost, residual value, and depreciation method carry forward. inoERP accumulated depreciation entries migrate as opening balance entries in Acumatica's asset depreciation history. Asset disposal history and revaluation records are preserved as reference notes on the fixed asset record in Acumatica.

inoERP

Project

maps to

Acumatica

Project

1:1
Fully supported

inoERP project records migrate as Acumatica Projects with customer association, project status, manager, and budget limits. Line-item budgets map to Acumatica project task budgets. Time and material allocations from inoERP become project transactions in Acumatica's Project Accounting module. Project phases, cost categories, and billing rules are transferred as configuration settings within each project.

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.

inoERP logo

inoERP gotchas

High

Architecture version split between PHP and Go/Flutter

Medium

OneApp API has no publicly documented rate limits

Medium

Closed-order and historical transaction volume drives migration scope

Low

Dynamic pull system recalculates lot sizes at runtime

Low

Self-hosting creates data export dependency on the customer

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

  • inoERP custom database fields require UDF pre-creation in Acumatica

    inoERP stores custom fields as additional columns directly on entity database tables. Acumatica does not use direct column extension — custom attributes must be defined as User-Defined Fields (UDFs) on the appropriate DAC before any data can populate them. FlitStack surfaces every inoERP custom field during the discovery phase and delivers a UDF creation checklist mapped to Acumatica's Customization -> User-Defined Fields screen so your admin pre-creates the fields before the migration run. If a UDF is missing, Acumatica silently drops the value at import time — no error is thrown by the Import by Scenario framework.

  • Acumatica's multi-entity branch structure requires pre-configuration for multi-company setups

    inoERP supports multiple legal entities within a single database, each with its own COA. Acumatica maps each legal entity to a separate Branch under an Organization. If inoERP is running multiple companies, Acumatica's Organization tree and branch hierarchy must be configured before any GL or sub-ledger data lands — the branch ID is a required foreign key on journal transactions and customer/vendor records. We deliver a branch-mapping plan as part of the discovery deliverable so the hierarchy is ready before migration begins.

  • AR/AP aging carry-forward requires opening-balance journal entries, not document re-creation

    inoERP's AR and AP modules store documents with individual line items and payment applications. In Acumatica, open AR/AP is carried forward as aging records linked to customer/vendor locations, not as original transaction documents. Re-creating every historical invoice as an Acumatica document inflates the APAR register without providing audit value. FlitStack creates opening-balance journal entries for AR and AP aging amounts per customer/vendor location, using inoERP's document totals as the aging reference and storing original document numbers in a custom field for audit traceability.

  • inoERP JavaScript workflow logic has no Acumatica equivalent — manual rebuild required

    inoERP allows client-side business logic through JavaScript REST API hooks embedded in the application's event system. These scripts fire on record save, approval, or document status change. Acumatica handles equivalent logic through Business Events, Automation Schedules, and Acumatica Workflows — entirely different architectural concepts. Any inoERP JavaScript event handlers that enforce approval routing, automatic field population, or cross-module cascade updates must be rewritten by your Acumatica developer. FlitStack can export inoERP's JavaScript event handler source files as a reference document for your Acumatica implementation team.

  • BOM revision control maps to Acumatica's effective-date revision model

    inoERP BOM revisions are stored as separate BOM records with a revision identifier. Acumatica handles BOM versioning through effective dates — each revision has a start date and optionally an end date. When inoERP BOMs have multiple active revisions simultaneously, FlitStack maps each inoERP revision to a separate Acumatica BOM record with the appropriate effective date window, and flags any BOMs that have overlapping effective periods for manual review before production orders reference them.

Migration approach

Six steps for a successful inoERP to Acumatica data migration

  1. Discover inoERP schema and export data via MySQL and REST API

    FlitStack connects to the inoERP MySQL database with read-only access and enumerates all entity tables, custom columns, and relationship keys. We also call inoERP's REST API endpoints to verify active document states, workflow statuses, and any data not stored in MySQL directly. The discovery output is a schema map listing every source table, column, and record count — this becomes the basis for the Acumatica import plan. Your team keeps working in inoERP throughout this phase.

  2. Design Acumatica import schema and pre-create UDFs

    FlitStack maps inoERP entities to Acumatica DACs and designs the Import by Scenario XML structure for each entity type. We deliver a UDF creation checklist identifying every custom inoERP field that requires a corresponding Acumatica User-Defined Field, including the DAC it belongs to, the field type, and any pick-list value sets. Your Acumatica admin creates these UDFs before migration data is loaded so no values are silently dropped during import.

  3. Migrate GL and chart of accounts first, then sub-ledgers

    Acumatica requires the chart of accounts to exist before any journal transactions, customer, vendor, or inventory items can reference account codes. FlitStack sequences the migration: GL Accounts and Branch/Organization structure load first, then Customers and Vendors (which reference account codes for AR and AP), then Inventory Items, then open AR/AP aging, then open Sales and Purchase Orders, then historical work orders and production orders. This foreign-key ordering prevents Acumatica's referential integrity checks from rejecting records.

  4. Run sample migration with field-level diff for validation

    A representative slice of data — typically 200–500 records spanning customers, vendors, inventory items, an open sales order, an open purchase order, and a work order — migrates first. FlitStack generates a field-level comparison report showing source value versus destination field for every mapped column. You review the diff to verify UDF mapping, account code resolution, status value translation, and document date preservation before the full migration run commits to Acumatica.

  5. Execute full migration with delta-pickup and rollback readiness

    The full migration run loads all remaining records into Acumatica using the validated Import by Scenario framework and REST API calls. A 24–48 hour delta-pickup window captures any inoERP records created or modified during the cutover window. FlitStack maintains an audit log of every operation, and one-click rollback is available if the reconciliation report shows unexpected gaps. After the delta window closes, your team goes live on Acumatica and inoERP is set to read-only.

Platform deep dives

Context on both ends of the pair

inoERP logo

inoERP

Source

Strengths

  • 100% free and open source with no per-user or per-module licensing fees.
  • Full ERP stack covering Finance, SCM, Manufacturing, and HR in a single integrated system.
  • Dynamic pull-based MRP adapts lot sizes to real-time demand changes rather than using fixed Kanban quantities.
  • Multi-database support including Oracle 12c, MySQL, and MariaDB on Windows, macOS, and Linux.
  • Mobile clients available for Android, iOS, macOS, Windows, and web browsers.

Weaknesses

  • Sparse official documentation and limited community support make self-hosting challenging.
  • Project Management module is under development and not yet production-ready.
  • Major architecture shift from PHP to Go/Flutter has created documentation fragmentation.
  • Self-hosting model shifts infrastructure labour costs to the customer, often negating free-licensing savings.
  • Very limited third-party review coverage and few public case studies demonstrating real-world deployments.
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 inoERP 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

    inoERP: Not publicly documented.

  • Data volume sensitivity

    B

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

Estimator

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

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

Can't find your answer?

Walk through your inoERP to Acumatica migration with a real engineer — 30 minutes, free, written quote within 24 hours.

Book a free 30 minute consultation

Most inoERP to Acumatica migrations complete in 48–72 hours of active migration clock time for datasets under 50,000 records. Complex setups with multi-year GL history, multi-entity branch structures, or 200,000+ transaction rows extend to 2–5 weeks of total project time. The longest planning step is Acumatica UDF pre-creation and branch hierarchy configuration — both must be completed before data loads, and your Acumatica admin controls that timeline.

Adjacent paths

Related migrations to explore

Ready when you are

Move from inoERP.
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