Migrate from Axelor ERP to Acumatica

Axelor Studio custom fields must be pre-created in Acumatica as Usr-prefixed fields before data lands

Axelor Studio stores custom field definitions in the XML model alongside standard JPA entities. When migrating to Acumatica, there is no automated translation — each Axelor custom field needs to be manually created in Acumatica Studio with the Usr prefix (e.g., UsrOriginCountry, UsrProjectPhase). FlitStack AI delivers a complete custom-field manifest listing each Axelor field name, data type, and pick-list values so the Acumatica admin can create them before the migration run. Without this step, the migration inserts null values into the standard Acumatica fields and the custom data is silently dropped. This is a pair-specific gotcha because the field definition lifecycle is a Studio-level concern in Axelor that has no equivalent automation path into Acumatica.

Axelor BPM workflows have no direct Acumatica counterpart and must be rebuilt

Axelor BPM runs as a built-in process engine attached to any domain object — sale approvals, onboarding sequences, and conditional routing are all modeled as BPM processes in the Axelor Studio. Acumatica's approval engine uses Business Events and screen-level automation but has no general-purpose process-modeling canvas. Teams migrating from Axelor frequently underestimate this gap: the process logic lives in the BPM XML definition and cannot be exported as a runnable artifact for Acumatica. FlitStack AI exports the BPM XML as a functional specification and maps each Axelor trigger/step to the corresponding Acumatica screen action. The actual rebuild is a separate Acumatica Studio engagement scoped by the customer's Acumatica administrator or VAR partner. This is the highest-frequency cause of post-migration process disruption when it is not disclosed upfront.

Axelor multi-entity setups using database schemas map to Acumatica's tenant organization tree

Axelor does not ship a native multi-tenant hierarchy; teams needing separate legal entities or inter-company invoicing typically implement this using separate Axelor databases, schema-level database separation, or custom partner-field logic. Acumatica's organization tree handles this natively with separate companies linked at the GL level. FlitStack AI maps each Axelor database or schema to an Acumatica Company within the organization. The complexity arises when Axelor inter-company records reference records in other Axelor databases — these cross-database links must be resolved using the preserved source IDs before they can map to Acumatica's inter-company journal entry structure. A migration plan review with both Axelor DBAs and the Acumatica implementation team is required before sequencing the entity-level migrations.

Axelor BI/reporting dashboards cannot migrate to Acumatica Generic Inquiries

Axelor embeds a BI module that generates pivot tables, charts, and dashboards directly from domain object queries. Acumatica replaces this with Generic Inquiries — saved SQL-like queries configured in the GI editor — plus optional external BI tool integration. The Axelor BI definitions export as XML, not as a format Acumatica can consume. FlitStack AI surfaces the full list of Axelor BI reports, their query scopes, and filter configurations in a GI migration guide. Each report requires a manual rebuild in Acumatica's GI editor. Teams on Axelor's Operations or Business tiers who rely heavily on BI dashboards should budget additional Acumatica configuration time post-migration.

Self-hosted Axelor export performance is I/O-bound on the hosting server

Axelor exports run through its REST API or direct PostgreSQL/MySQL queries against the application database. For large record volumes (200k+ records), export throughput depends on the self-hosted server's disk I/O and network path to Acumatica's cloud endpoint. Community posts on the Axelor forum confirm that docker-volume-backed database containers can export at 5–10x slower throughput than bare-metal PostgreSQL due to I/O contention. FlitStack AI runs a dry-run export to benchmark export throughput before scheduling the full migration and adjusts batch sizing accordingly. For deployments exceeding 500k total records, a database-level export via pg_dump or MySQL dump may be faster and is evaluated as an alternative to the REST API path.