ERP migration
Field-level mapping, validation, and rollback between Deacom ERP and Acumatica. We move data and schema; workflows are rebuilt natively in Acumatica.
Deacom ERP
Source
Acumatica
Destination
Compatibility
12 of 13
objects map 1:1 between Deacom ERP and Acumatica.
Complexity
BStandard
Timeline
2–4 weeks
Overview
Deacom ERP stores data across dm (maintenance), dt (transaction), and dx (system) tables using _id primary keys and _*id foreign-key references. Its per-user pricing model and on-premise or single-tenant cloud deployment create a different cost structure than Acumatica's resource-based cloud model. Acumatica organizes data around customers, vendors, inventory items, stock items, non-stock items, GL accounts, warehouses, and projects—with separate screens for each and Generic Inquiry for custom reporting. We map Deacom's customer, vendor, item, and transactional tables to their Acumatica equivalents, using email matching to resolve owner and buyer assignments. Transactional history (invoices, receipts, production orders) is preserved as imported records, though Acumatica's open vs. closed period model requires configuration decisions before migration. We handle master data (accounts, warehouses, customer addresses) in the first pass, then load open transactions in dependency order so foreign keys resolve correctly. Workflows, approval chains, and EDI mappings built in Deacom have no direct Acumatica equivalent—these are documented for manual rebuild using Acumatica's configuration tools.
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 Deacom 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.
Deacom ERP
dmCUST (Customer Master)
Acumatica
Customer
1:1Deacom customer records (dmCUST) map directly to Acumatica Customer DAC records. The customer ID (cu_id), name, address, and payment terms transfer as-is. Deacom's customer class (cu_classid) maps to Acumatica's Customer Class (CustomerClassID). Email and phone fields land in the respective Contact sub-tab. We resolve Deacom's owner assignment by matching cu_buyerid to Acumatica users by email.
Deacom ERP
dmVEND (Vendor Master)
Acumatica
Vendor
1:1Deacom vendor records (dmVEND) map to Acumatica Vendor DAC records. The vendor ID (ve_id), name, address, and AP terms transfer. Deacom's vendor class maps to Acumatica's Vendor Class. Remit-to addresses in Deacom become separate Address records on the Acumatica Vendor. We preserve the original vendor ID in a custom Vendor_TempID__c field for reconciliation.
Deacom ERP
dmPROD (Item/Product Master)
Acumatica
StockItem / NonStockItem
1:manyDeacom items in dmPROD split into Acumatica StockItem (for inventoried items) or NonStockItem (for non-inventoried materials). The split is based on Deacom's item type flag (pr_type). Inventoried items carry over warehouse-bin assignments, lot/serial settings, and stocking UOM conversions. Non-stock items transfer without inventory tracking fields. Each item's Deacom ID (pr_id) is preserved in a custom LegacyItemID__c field.
Deacom ERP
dmBOMH / dmBOMM (BOM Header/Lines)
Acumatica
Bill of Materials (BOM)
1:1Deacom BOM structures (dmBOMH for header, dmBOMM for lines) translate to Acumatica's Bill of Materials screen. Deacom's BOM revision system requires mapping each active revision to a separate Acumatica BOM revision record. Material quantities, scrap factors, and operation steps from Deacom's routing (dmROUTEH) map to Acumatica's BOM Materials and Operations tabs. We flag inactive Deacom BOM revisions as inactive BOMs in Acumatica.
Deacom ERP
dmFACCT (GL Account Master)
Acumatica
GLAccount
1:1Deacom's dmFACCT table maps to Acumatica GLAccount records. The account number (fa_id), description, and account type (fa_type) transfer. Deacom's account segments map to Acumatica's account format segments if Deacom uses a segmented chart. Active/inactive status in Deacom translates to Active flag in Acumatica. Subaccount structure in Deacom requires mapping to Acumatica's Subaccount dimension.
Deacom ERP
dtARIN (AR Invoice Transactions)
Acumatica
ARInvoice
1:1Open Deacom AR invoices (dtARIN) map to Acumatica ARInvoice records. The invoice number, date, due date, customer reference, and line items (dtARINL) transfer. Deacom's payment terms code (dtARIN.terms) maps to Acumatica's Terms ID on the invoice. Historical paid invoices are imported with a status flag; open invoices import as open records. Line-level discounts and tax amounts from Deacom land in Acumatica's Amount and TaxAmount fields.
Deacom ERP
dtAPIN (AP Invoice Transactions)
Acumatica
APInvoice
1:1Open Deacom AP invoices (dtAPIN) map to Acumatica APInvoice records. Vendor reference, invoice date, and due date transfer. Deacom's AP terms map to Acumatica's Terms ID. Line items (dtAPINL) with GL account assignments and amounts land in the invoice detail grid. Prepaid invoices in Deacom (where partial receipts occurred) require Acumatica's Prepayment Invoice type. We flag unmatched vendor IDs before migration for manual resolution.
Deacom ERP
dmWHSE (Warehouse Master)
Acumatica
Warehouse
1:1Deacom warehouse records (dmWHSE) map to Acumatica Warehouse records. The warehouse ID (wh_id), name, and address transfer. Deacom's bin structure (dmBIN) maps to Acumatica Location records within each Warehouse. Multiple Deacom facilities map to multiple Acumatica warehouses. We preserve the original warehouse ID in the Warehouse_OrigID__c field.
Deacom ERP
dmUDFH / dxCAPTION (Custom UDF Definitions)
Acumatica
Custom Fields (Usr* on respective DACs)
1:1Deacom user-defined fields stored via dxCAPTION pick-list options and dmUDFH definitions require Acumatica custom fields on the respective DACs. Each UDF field's data type (text, date, pick-list) maps to the equivalent Acumatica field type. Pick-list UDF values in Deacom (stored via d3_c2guid links) translate to Acumatica custom pick-list values on the field. We create custom fields using the Usr prefix convention and map the data during the entity migration pass.
Deacom ERP
dtPRODH / dtPRODL (Production Order Header/Lines)
Acumatica
Production Order
1:1Open Deacom production orders (dtPRODH with dtPRODL lines) map to Acumatica Production Order records. The production order number, status, scheduled start/end dates, and BOM reference transfer. Deacom's production operations (from dmROUTEH) require Acumatica's production routing setup per item before orders can be scheduled. We import orders in Released status where routing data exists; orders without routing data land in Planned status for manual routing assignment.
Deacom ERP
dmCONTACT (Contact Records)
Acumatica
Contact (under Customer/Vendor)
1:1Deacom contact records attached to customers or vendors (dmCONTACT) map to Acumatica Contact records linked to the respective Customer or Vendor. The contact name, email, phone, and title transfer. Primary contact designation in Deacom (co_primary flag) sets IsPrimaryContact on the Acumatica Contact. Multiple contacts per customer map to separate Contact records under the same parent Customer.
Deacom ERP
dmSHIPTO (Ship-To Addresses)
Acumatica
Address (on Customer)
1:1Deacom ship-to addresses (dmSHIPTO) attached to customers map to Acumatica Address records on the Customer DAC. The address line, city, state, postal code, and country transfer. Deacom's default ship-to flag maps to the IsDefaultShipping flag on the Address. Multiple ship-to addresses per customer become multiple Address records with distinct types.
Deacom ERP
dxCAPTION (System Lookups/Codes)
Acumatica
Segment / Subaccount Values
1:1Deacom system lookup codes stored in dxCAPTION (such as department codes, cost center codes) map to Acumatica Subaccount values. Each Deacom code group becomes a separate subaccount segment in Acumatica. The dxCAPTION c2_description maps to the Subaccount description. We preserve the original Deacom code value in the Subaccount_OrigCode__c field for audit traceability.
| Deacom ERP | Acumatica | Compatibility | |
|---|---|---|---|
| dmCUST (Customer Master) | Customer1:1 | Fully supported | |
| dmVEND (Vendor Master) | Vendor1:1 | Fully supported | |
| dmPROD (Item/Product Master) | StockItem / NonStockItem1:many | Fully supported | |
| dmBOMH / dmBOMM (BOM Header/Lines) | Bill of Materials (BOM)1:1 | Fully supported | |
| dmFACCT (GL Account Master) | GLAccount1:1 | Fully supported | |
| dtARIN (AR Invoice Transactions) | ARInvoice1:1 | Fully supported | |
| dtAPIN (AP Invoice Transactions) | APInvoice1:1 | Fully supported | |
| dmWHSE (Warehouse Master) | Warehouse1:1 | Fully supported | |
| dmUDFH / dxCAPTION (Custom UDF Definitions) | Custom Fields (Usr* on respective DACs)1:1 | Fully supported | |
| dtPRODH / dtPRODL (Production Order Header/Lines) | Production Order1:1 | Fully supported | |
| dmCONTACT (Contact Records) | Contact (under Customer/Vendor)1:1 | Fully supported | |
| dmSHIPTO (Ship-To Addresses) | Address (on Customer)1:1 | Fully supported | |
| dxCAPTION (System Lookups/Codes) | Segment / Subaccount Values1: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.
Deacom ERP gotchas
Rate limiting on the Deacom Public API requires chunked export sequencing
BOM revisions require revision-date sequencing to preserve formulation state
Custom UDF pick-list options use _guid references that break cross-database
Multi-tenant cloud hosting limits server-level access needed for deep exports
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
Scoped export from Deacom dm/dt tables
We connect to the Deacom database or API (based on your Deacom version and API availability) and extract all dm and dt table groups in scope. For each entity—customers, vendors, items, warehouses, GL accounts—we run a full export and apply a date-range filter for transactional tables (AR invoices, AP invoices, production orders) based on the agreed historical window. We validate foreign-key integrity (e.g., ai_cuid references to dmCUST) before extracting, flagging any orphaned records for your Deacom admin to resolve. Deacom API rate limiting (version 17.04.008+) is handled via throttled request patterns; direct SQL read access (on-premise or managed Deacom cloud) bypasses rate limits for faster extraction.
Pre-create Acumatica schema (companies, custom fields, BOMs, routings)
Before data lands in Acumatica, your Acumatica admin (or our team) creates the necessary structure: multiple companies if migrating multi-entity Deacom setups, custom fields on Customer/Vendor/StockItem DACs for migrated UDFs, and BOM/Routing records for any items with active production orders. We deliver a schema setup checklist based on the Deacom assessment, so the Acumatica side is ready before validation runs. Custom field names follow Acumatica's Usr prefix convention. BOMs and Routings must be active in Acumatica before production orders can be scheduled—not imported in Planned status indefinitely.
Run sample migration with field-level diff on 200–500 records
A representative slice of master data (50 customers, 50 vendors, 100 items) plus a sample of transactional records migrates to Acumatica first. We generate a field-level diff report comparing source Deacom values against destination Acumatica fields, specifically checking: customer payment terms resolution, item UOM conversion on stocked items, GL account code mapping, and transactional date vs. Acumatica period calendar alignment. This pass catches UDF pick-list mapping gaps, dxCAPTION chain resolution failures, and any period-closed conflicts before the full run. You review the diff and approve or request corrections before we commit to the complete migration.
Execute full migration with dependency-ordered entity sequence
The full migration runs in dependency order so foreign keys resolve correctly: GL accounts and warehouses first (foundation entities), then customers and vendors (with class and terms lookups resolved), then inventory items (with class and UOM conversions), then contacts and addresses, then transactional records (AR/AP invoices), then production orders (with BOM and Routing links verified). Each entity group is a discrete migration pass. We log every record inserted into Acumatica with its source Deacom ID (pr_id, cu_id, etc.) preserved in the corresponding legacy-ID custom field. A delta-pickup window (24–48 hours) captures any records created or modified in Deacom during the cutover window.
Deliver audit log and reconciliation report
After the migration completes, we generate an audit log mapping every Acumatica record to its source Deacom table and primary key. A reconciliation report compares record counts by entity between Deacom and Acumatica, surfacing any gaps (e.g., five AR invoices in Deacom that did not insert into Acumatica). We also run a post-migration validation query in Acumatica's Generic Inquiry tool to confirm totals—AR open invoice amount sum, vendor payable balance, and inventory quantity on hand by warehouse. One-click rollback is available within 48 hours of go-live if reconciliation reveals discrepancies exceeding your agreed tolerance threshold. The FlitStack team stays engaged through the delta-pickup window to capture any last-minute Deacom changes.
Platform deep dives
Deacom 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 Deacom 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
Deacom ERP: Not publicly documented for external use. Internal rate limiting was introduced in version 17.04.008..
Data volume sensitivity
Deacom 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 Deacom ERP to Acumatica migration scoping. Not seeing yours? Book a call.
Walk through your Deacom 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 Deacom 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.