Migrate from Access ERP to Microsoft Dynamics 365 Business Central

Access ERP maintains a flat chart of accounts with nominal ledger codes that embed cost-centre and department suffixes used across all modules. D365 separates MainAccount (the nominal code) from FinancialDimension values (cost centre, department, business unit, project) stored in a DefaultDimension attached to each transaction. We extract the Access account structure preserving every cost-centre and department suffix, provision the corresponding MainAccount records in D365, build the Dimension hierarchy in D365 Financial Dimension framework, and attach DefaultDimension values to each migrated record at insert time. This restructuring step is the most time-intensive part of an Access ERP migration and must complete before any transaction data can be posted.

Access ERP customer masters carry address books, payment terms, credit limits, and currency assignments. We map these to D365's CustCustomerV3Entity which uses DirParty for the party name and address structure. Multi-currency customer accounts require that the D365 Ledger currency and exchange rate provider are configured before customer import. Customer balance forward (AR aging) is preserved as an opening transaction posted on the cut-over date rather than as a live aging balance.

Access ERP vendor masters mirror the customer master structure with supplier-specific fields including payment terms, bank details, and W9/tax registration. These map to VendVendorV2Entity in D365 using the same DirParty address and contact pattern. Vendor outstanding invoice references (open AP) migrate as posted VendorInvoice records rather than as a running balance, requiring that the AP aging is converted to individual invoice records at migration time.

Access ERP item records carry warehouse-specific quantities, reorder levels, BOM structures, and unit-of-measure conversions. D365 separates the product definition (EcoResProduct) from the inventory storage (InventTable) and warehouse configuration (InventLocation). We extract the Access item master and BOM header, create EcoResProduct variants for size/color/dimension if applicable, populate InventTable with warehouse-specific planning and costing data, and attach BOM components to D365 Bill of Materials lines. Item transactions (on-hand quantities per warehouse) are migrated as opening inventory transactions on the cut-over date rather than as live on-hand updates.

Open purchase orders from Access ERP migrate to D365 PurchTable and PurchLine. We preserve order number, supplier reference, expected and received quantities, pricing, and delivery address. Status mapping resolves Access order states (raised, confirmed, part-received) to D365 PurchaseOrderStatus values. Closed purchase orders with outstanding received-but-not-invoiced lines are migrated as receipt transactions; fully closed orders are documented as historical records in the migration inventory rather than as active D365 entities.

Open customer invoices from Access ERP migrate to D365 CustInvoiceJour as posted invoices with full line detail in CustInvoiceTrans. We preserve invoice number, customer reference, invoice date, due date, currency, tax amounts, and outstanding amount. Historical paid invoices migrate as closed records with their original payment references and bank statement lines for audit trail. The AR aging at cut-over date is converted to individual open invoice records in D365 so that the customer's collections team works from the same open-item view they had in Access.

Open vendor invoices migrate to D365 VendInvoiceJour and VendInvoiceTrans. We preserve vendor invoice number, invoice date, due date, currency, tax amounts, and outstanding amount. Historical paid invoices carry their original payment references and bank statement lines. The AP aging at cut-over date converts to individual open vendor invoice records so that the AP team continues from the same open-item view. Vendor payment runs do not migrate as recurring schedules; those are documented in the automation inventory for the customer's D365 partner to rebuild.

Access ERP bank account masters and cash book balances migrate to D365 BankAccountTable with bank currency, reconciliation limits, and the account number. Outstanding unreconciled transactions migrate as BankTrans records so that D365's bank reconciliation module starts from the same open-item list as Access. The bank reconciliation cut-over date is agreed with the customer during migration planning and documented in the runbook; we do not allow D365 bank reconciliation to run on data that overlaps with Access live posting.

Access ERP stores document attachments at transaction and master-record level in a file store tied to the database. We export attachments in their native format, provision a SharePoint document library connected to D365 via the Office 365 integration, and reattach documents to the corresponding D365 records using DocuRef. We validate that all attachment file types are supported by SharePoint and flag any that exceed SharePoint's 250 MB per-file limit for the customer's admin to store externally.

Access ERP's high configurability means the live database routinely contains custom fields on standard tables and user-defined tables not part of the standard installation. We run a targeted discovery query against the Access live database that enumerates every non-standard field and user-defined table before building the extraction spec. Custom fields on customer, vendor, item, and transaction tables map to D365 Extension fields (which add to the standard entity without modifying the base table). User-defined tables migrate to D365 custom tables created via the Microsoft Dataverse layer or as Azure SQL tables depending on the complexity of the relationship structure.

Access ERP user accounts carry role-based permissions, department assignments, and workflow approval limits. We export user records and map them to D365 DirUser by email match. Security roles in D365 are not 1:1 with Access roles; we deliver a written role mapping document that pairs each Access role to the closest D365 SecurityRole and documents any permissions that do not have a direct equivalent so that the customer's D365 admin can complete the security design before go-live.

Access ERP BOM structures migrate to D365 BOMTable (the BOM header) and BOMVersion (the active revision) with component lines as BOMLine records. Multi-level BOM routing is preserved by migrating parent and child BOM structures in dependency order. BOM warehouse location and scrap percentage migrate to the corresponding D365 fields. We flag any Access BOM that uses non-standard unit-of-measure conversions for the customer's engineering team to validate before production migration.