Migrate from ERP Mark 7 to Microsoft Dynamics 365 Business Central

ERP Mark 7 Customer records map to Dynamics 365 Customers V2 (which covers both legal entities and contact persons). Address, contact details, payment terms, and credit limits transfer as standard fields. We use the customer number as the Account Number and the customer name as the Primary Name. 1099 and tax-exempt flags are not present on ERP Mark 7 Customers (those live on Vendor) but we check during scoping and flag any customer-side tax settings for the destination Tax Exempt field.

ERP Mark 7 Vendor records map to Dynamics 365 Vendors V2. W-9 status, 1099 settings, and payment terms migrate as native fields. Vendor address and contact detail structure matches the D365 Vendor schema without transformation. We flag any ERP Mark 7 vendor-specific custom fields during the schema audit phase and map them to custom fields on the Vendor or to a related contact record.

ERP Mark 7 Items (products, raw materials, services) map to Dynamics 365 Released Products. Item type (inventory, non-inventory, service) maps to Product Type. ERP Mark 7 custom properties per item type (e.g., machine-specific flags, lot tracking preferences) require explicit mapping to D365 product attributes or to custom fields on Released Products. We run the schema-discovery pass against ERP Mark 7 to enumerate per-item-type custom properties before field mapping begins.

Standard ERP Mark 7 account numbers and names map directly to D365 Main Accounts. ERP Mark 7's configurable COA segments (e.g., department, cost center, region) map to D365 financial dimension sets, which must be configured in the destination before account import. We flag any non-standard segment structures during scoping and document the dimension set configuration required in D365; manual recreation of segment structures is performed by the customer admin before we load account data.

Open receivables and payables require careful sequencing. We migrate open invoices as Customer Transaction or Vendor Transaction records with aging buckets preserved via Due Date and Payment Terms fields. Paid status, payment method, and partial payment history migrate as distinct transaction lines. We chunk by invoice date and payment status to avoid duplicate posting and load before any new transactions are entered in D365. ERP Mark 7 AR/AP custom fields (e.g., invoice reference numbers, PO numbers) map to the corresponding D365 invoice custom fields.

ERP Mark 7 Work Orders map to D365 Production Orders with BOM and routing steps carried forward. We map ERP Mark 7's BOM version and routing step references to D365's BOM and Route entities. Custom fields on work orders (e.g., machine center, priority flags, work center assignments) require explicit mapping to D365 production attributes or to user-defined fields. ERP Mark 7 does not publish a documented production data schema, so we enumerate BOM and routing structures during the schema-discovery phase against the live instance.

ERP Mark 7 BOM structures map to D365 BOM and BOM Version entities. Each BOM header links to the Released Product (from the Item mapping), and BOM lines link to component items (also mapped from ERP Mark 7 Items). BOM versions for multi-phase production migrate as distinct BOM Version records. We resolve component item references at migration time using the previously loaded item mapping.

Historical journal entries and transaction lines migrate as General Ledger Journal Batches with journal lines. We segment migration into pre-close and post-close batches: closed-period transactions load as locked journal batches with posting dates preserved and the D365 posting layer bypassed for historical accuracy; the current fiscal year loads with posting enabled for live reconciliation. The customer must confirm fiscal year boundaries and close-date records before we begin. Transactions older than the retention threshold the customer specifies (typically five to seven years) can be archived as a read-only file rather than loaded into D365 to keep the live database lean.

Documents stored as attachments in ERP Mark 7 (on transactions, items, customers) export in their native format. We re-attach them to the corresponding D365 records using either D365's native document handling or Azure Blob Storage with SharePoint integration if the customer licenses Microsoft 365. Binary attachments are chunked to avoid size limits during the transfer. We flag any attachment type that D365 does not support natively for a separate handling decision.

ERP Mark 7 allows user-defined fields on most standard objects, but these are not catalogued in any external metadata API. We cannot enumerate the full custom property set until we have a live authenticated session. During the schema audit, we export a sample record set per object and diff it against the standard ERP Mark 7 field definition to identify all custom properties. Each discovered custom property maps to a D365 extension field (custom field on the same entity). Any custom property that has no D365 equivalent is flagged for the customer admin to decide whether to create a matching custom field or drop the data.

ERP Mark 7 User records (name, email, role, department) map to D365 Workers (in Human Resources) or to D365 Users (in Finance and Operations) depending on whether the customer licenses the Human Resources module. Role names do not map 1:1 to D365 security roles, so we match by permission level and flag roles that require manual reassignment. Users without a matching D365 identity go to a reconciliation queue for the admin to provision before record import resumes.

ERP Mark 7 Departments map to D365 Operating Units or to financial dimension values (Cost Center type) depending on the D365 edition and configuration the customer has chosen. Nested department hierarchies from ERP Mark 7 flatten into D365's flat dimension structure; we document the flattening rule during scoping so the customer admin can validate the result before production migration.

ERP Mark 7 Tax Codes map to D365 Sales Tax Groups and Item Tax Groups. Active tax codes transfer with their jurisdiction and rate settings. Deprecated or jurisdiction-specific codes that cannot be replicated in D365 are flagged and left unmigrated; the customer admin recreates them in D365's Tax configuration page post-migration.