Migrate from Extensiv Order Manager to Acumatica

Ad-hoc custom fields require upfront Acumatica schema work

Extensiv allows you to add custom fields directly in the Custom Order Info section without any schema setup — fields can be created on an ad-hoc basis or pre-configured under Customers > Custom Fields. Acumatica requires User-Defined Fields to be explicitly defined in the Customization Project editor with the Usr prefix before any data can be imported into those fields. If your Extensiv setup has 20+ custom order fields, your Acumatica admin must pre-create each one; otherwise the migration skips those fields silently. We deliver a UDF manifest listing every Extensiv custom field with its data type so your admin can batch-create them before the migration runs.

Stock Items must exist before Sales Orders can reference them

Acumatica enforces referential integrity at the database level for Sales Order lines — the InventoryID field must resolve to an existing Stock Item or Non-Stock Item record in IN202500 or IN202000. Extensiv allows you to create an order with a SKU that has never been set up as a product in the system. This means the migration must run in strict sequence: Products (Stock Items) → Customers/Vendors → Purchase Orders → Sales Orders. If Extensiv has orders referencing products that were never set up as formal products, those line items are flagged as errors and must be resolved — either by creating the missing Stock Item first or by removing the line from the migration scope.

Warehouse strings must map to formal Acumatica Warehouse entities

Extensiv stores warehouse as a freeform string field on orders, shipments, and inventory records — you can add a new warehouse name without any formal registration. Acumatica maintains a formal Warehouse entity (WH203000) with a WarehouseID, Branch association, and address. Every Extensiv warehouse name must map to a corresponding Warehouse record in Acumatica, and that Warehouse must be associated with a Branch for GL postings to resolve correctly. If Extensiv has warehouses that were never formally registered, the migration plan must include creating those Warehouse and Branch records first. This is a common source of delayed migrations when multi-warehouse setups were grown organically in Extensiv.

Integration connections to sales channels do not migrate

Extensiv's core value proposition is its library of 60+ pre-built connectors to ecommerce platforms (Shopify, BigCommerce, Magento), marketplaces (Amazon, Walmart, eBay), and 3PL providers. These integration configurations live in Extensiv's connection layer and have no equivalent in Acumatica's native schema. Acumatica offers the Integration Desktop (IDK) and a REST API for building custom integrations, but there is no out-of-the-box equivalent for marketplace connectors. We export the Extensiv integration configuration (channel credentials, field mappings, filter rules) as a reference document. Rebuilding each connection in Acumatica requires separate scoping and is typically priced as a distinct engagement.

Workflows and fulfillment automation cannot migrate

Extensiv's order routing rules, fulfillment automation, and warehouse assignment logic are platform-native constructs with no Acumatica equivalent. Acumatica uses screen workflows, business events, and automation schedules — a fundamentally different model. Extensiv workflows based on channel, warehouse, product type, or customer tier must be translated into Acumatica automation steps. We export the workflow definitions from Extensiv as a configuration document that your Acumatica consultant can use to scope and rebuild each rule in Acumatica's workflow designer. This is always a manual step post-migration.