Migrate from Pilot ERP to Microsoft Dynamics 365 Business Central

Pilot ERP Customer records map to D365 Account with Customer type = Company. The customer name, address, payment terms, credit limit, and contact information migrate as structured fields. D365 separates the address into Address (Street, City, State, ZIP) and country/region; Pilot ERP's single address block is split accordingly. Active/inactive status maps from Pilot ERP's isactive flag to the Blocked field in D365. We resolve the sales tax ID or registration number into the Tax Registration ID field in D365.

Pilot ERP Vendor records map to D365 Vendor directly. Address, payment terms, and currency code migrate with the same field-level mapping logic as Customer. Any outstanding Bills linked to the Vendor are resolved after Vendor import so that the Vendor account is guaranteed to exist before AP records reference it.

Pilot ERP Items map to D365 Item or Product depending on the chosen D365 product tier. The item number, description, unit of measure, costing method (standard, average, FIFO), and current stock level migrate. For items with barcode-labelled inventory in Pilot ERP, we map to D365 Item Tracking (batch or serial) rather than a separate barcode field, which requires WMS configuration in D365 F&O or item tracking setup in D365 BC. Every barcode-labelled record is audited for a valid Item reference; orphaned barcode records are flagged for resolution before inventory migration.

Pilot ERP Work Orders map to D365 Production Order. Each Work Order carries a reference to the finished Item (BOM component) and optionally to a Purchase Order for raw material reservation. We resolve the Item-to-BOM link during migration by looking up the corresponding Bill of Materials in D365. Open Work Orders migrate with status = Started or Scheduled; closed Work Orders are migrated as history with status = Completed. Orphaned PO links (Work Order referencing a closed or voided PO) are flagged in the pre-migration audit and resolved by the customer before transactional load.

Pilot ERP Purchase Orders map to D365 Purchase Order with vendor, line items, quantities ordered, and open status preserved. Partially received POs migrate with the received quantity and remaining balance updated to reflect the current state. We audit all PO-to-Work-Order references during the migration audit and flag any stale or invalid links that would cause inventory discrepancies on receipt.

Pilot ERP Invoices map to D365 Sales Invoice records. Open invoices migrate with payment status and remaining balance; historical paid invoices migrate with full line-item detail for audit trail continuity. The Customer reference is resolved to the D365 Account at import time. Tax amounts are mapped to the D365 tax group and item tax group configuration established during schema design.

Pilot ERP Bills map to D365 Vendor Invoice with outstanding balance, payment terms, and vendor reference preserved. Partial-payment history on Bills migrates as separate invoice settlement records in D365's AP module. We verify that the originating Vendor record exists and is active in D365 before the Bill import phase begins.

Pilot ERP's Job Costing module breaks costs into material, labor, and overhead components per job or Work Order. D365 F&O handles this via production journal lines with cost categories; D365 BC uses Project transactions with categories. We build a costing matrix during discovery that maps each Pilot ERP cost type (material, labor, overhead) to a D365 cost category ID. The customer's operations team reviews the matrix before migration, and any cost types that do not map automatically are flagged for manual journal configuration in D365. Historical job cost totals are preserved as summed journal entries rather than individual component rows to maintain balance integrity.

Pilot ERP's Chart of Accounts maps to D365's Chart of Elements. We extract the full account structure including account number, name, account type (Asset, Liability, Equity, Revenue, Expense), and posting definitions. Accounts with transactions that do not match a D365-compatible account type are flagged for the customer to resolve in D365 before financial data load. We map Pilot ERP account segments to D365 financial dimensions (Cost Center, Department, Project) if the customer uses dimension-based reporting.

Pilot ERP's barcode data collection module links barcode scans to Items by part number. We migrate barcode-labelled inventory records as D365 Item Tracking entries (batch or serial numbers) rather than as separate barcode fields, which requires the WMS module in D365 F&O or item tracking setup in D365 BC to be configured before inventory migration. Every barcode-labelled record is audited for a valid Item reference; orphaned barcode records referencing non-existent Items are flagged for correction before inventory import.

Pilot ERP supports user-defined custom fields on standard objects but provides no documented schema export or API endpoint for custom field definitions. We inventory custom fields during the discovery call by reviewing Pilot ERP's field configuration screens with the customer. We then recreate these as custom fields in D365 using the Power Apps metadata editor or the D365 extension model, matching the data type (text, number, date, picklist) as closely as possible. Mapping records during the load phase carry the custom field values against the corresponding D365 record ID.

Pilot ERP's user manual references document attachment capability on Work Orders, Customers, and Items but does not expose a documented public API endpoint for binary file export. We cannot programmatically extract attachments. We document every attachment reference encountered during discovery as a named item in the migration deliverable, flagging each as requiring manual export from Pilot ERP or database-level extraction. The customer provides these files directly or configures SharePoint or Common Data Model document storage in D365 for re-attach after migration. We do not migrate attachments as binary records within the migration scope.