Migrate from ManEx to Microsoft Dynamics 365 Business Central

ManEx Customer records include contact details, account assignments, and address data in a flat, stable schema. We extract via direct DB query or ManEx's UI export function and map to D365 CustTable (Finance and Supply Chain Management) or the Customer table (Business Central). The customer's account group maps to a D365 Customer Group; the payment terms map to D365 PaymentTermId. Address data maps to the LogisticsPostalAddress structure with the primary address flagged for invoice and delivery roles. All Customers migrate before any related Sales Orders to satisfy parent-record lookup requirements.

Vendor master data in ManEx is a distinct entity from Customer and includes PO history and RMA associations. We preserve the vendor-supplier relationship separately during migration to avoid merging suppliers with customers. The vendor group maps to D365 Vendor Group, and the primary address maps to LogisticsPostalAddress. Vendor payment terms and currency codes migrate as explicit field values to prevent default-to-system settings in D365.

ManEx GL accounts use standard account types (asset, liability, equity, revenue, expense) with a flat numbering structure. We map each ManEx account code and type to D365 MainAccount with the corresponding account type, and map any active dimensions (Cost Center, Department, Business Unit) to D365 FinancialDimensions or Business Central's dimension sets. Inactive or suspense accounts are flagged and set to blocked status in D365. This entity migrates before AP/AR ledger entries because those records reference account codes.

ManEx PO records include line items tied to BOMs, vendor assignments, and receiving status. We preserve the full PO lifecycle including partially received orders, mapping their status flags explicitly to D365 PurchTable status (Draft, Submitted, Invoiced, Cancelled). Partially received POs represent a common gotcha in manufacturing ERPs because the receiving status must map precisely to D365's PO status flags or the receiving team will see incorrect open-PO quantities post-migration. This is one of the first objects we validate post-import against ManEx's receiving report.

ManEx SO records include pricing, customer linkage, and fulfillment status. Multi-price-list pricing on SOs requires explicit value-mapping in D365 because ManEx price list IDs are not portable across ERP systems. We map price list names to D365 Trade Agreement price groups or customer-specific price lists and flag any pricing rule that cannot be directly translated. SO status (Open, Shipped, Invoiced, Cancelled) maps to D365 SalesTable status. SOs are imported after Customers to satisfy the CustAccount foreign key.

ManEx BOMs include multi-level component structures and routing data. Complex multi-level BOMs with phantom assemblies require decomposition during migration; we evaluate each BOM for level count and phantom assembly flags and decide whether to flatten into a single-level D365 Production BOM or preserve the multi-level hierarchy using D365's BOM versioning and approval workflow. Route operations from ManEx map to D365 ProdRoute with work center and operation time data. BOM decomposition is the most time-intensive planning step for manufacturing ERP migrations because the production scheduling logic in D365 depends on correct BOM and Route structures.

ManEx real-time shop floor data tracks labor time, machine cycles, and material consumption per work order. This transactional data is timestamped and contextual; we map it to D365 production journal entries (ProdJournalTable and ProdJournalTrans) which represent the production postings for the corresponding work orders. We preserve the original transaction timestamp and map the employee or work center reference to the D365 worker or work center. Large shop floor transaction histories may require batched import with Bulk API or staging table approach.

ManEx inventory quantities, locations, and lot or serial data are extracted from the materials management module. We handle multiple warehouse locations and on-hand quantities, preserving lot traceability and serial number records. Each ManEx warehouse location maps to a D365 Site and Warehouse combination (InventDim), and the on-hand quantity maps to InventSum. Lot and serial number data migrates to D365 InventBatch and InventSerial tables with full traceability lineage. This entity migrates before any inventory transactions (SOs, POs, shop floor journals) to establish correct on-hand starting points.

Open payables and receivables migrate with their current status, aging buckets, and payment terms. Historical transactions require special handling because ManEx may store them in archived or compressed tables that are not surfaced in the standard application export. We flag historical AP/AR as a scope item during discovery and assess whether the customer needs historical ledger data included. If included, we negotiate additional extraction and transformation time, and evaluate D365's ledger entry capacity for high-volume historical records. Payment terms from ManEx may be informal or non-standard; we map them to D365 PaymentTermId values and flag any ManEx-specific terms that lack a D365 equivalent for the AP/AR team to resolve before migration.

RMAs represent return or repair states tied to original SOs or POs. Their status codes (open, in-progress, closed) require explicit value-mapping because the RMA state machine differs between ManEx and D365. We map RMA status to D365 ReturnOrder status and preserve the link to the originating SO or PO. RMA disposition codes (repair, replace, scrap, return to stock) may not map directly; we create a disposition code mapping table during scoping and flag any disposition that requires a custom D365 return reason code.

Document attachments stored within ManEx's document management module are not accessible via a public API and may use proprietary formats. We do not migrate document attachments as part of standard scope. We deliver a manifest of all document references with their original storage paths and a recommendation for re-uploading them into D365 SharePoint Online or Dataverse as part of the customer's post-migration document strategy. Document relocation is a manual step outside the data migration pipeline.

The ManEx Project Management module is optional and not always activated. During discovery we identify whether it is active and, if so, what schemas it uses. If active, we scope project header records (ProjTable), project transactions (ProjJournalTrans), and billing lines for migration to D365 Project Operations or Business Central Jobs. If the module is inactive or the schemas are undocumented, it is excluded from migration scope and flagged in the handoff document.

The ManEx Repair module is optional and additive to the core ERP schema. If active, repair orders, associated BOMs, and labor tracking migrate to D365 Service Management or Business Central Service Orders. Repair status codes require explicit value-mapping to D365 ServiceOrder status. If the Repair module is not active, it is excluded from scope. This module's presence or absence is confirmed during discovery before migration planning finalizes.

Time entries from the optional Time and Attendance module are tied to employees and work orders. During discovery we confirm whether this module is active and what fields are populated. If the destination is D365 Finance and Supply Chain Management, time entries map to HcmAttendanceTrans and the corresponding worker record. If the destination is Business Central with a payroll extension, entries map to the Time Registration entity. If the destination ERP has no HR module, we map time entries to the corresponding employee or worker record and flag any unmatched entries for the customer's HR team to resolve.