Migrate from PILOT:Suite to Microsoft Dynamics 365 Business Central

PILOT:Suite Items map to Dynamics 365 Product2 records with the item number preserved as the source key. Unit of measure, item category, product type (inventory vs non-inventory vs service), and cost method (Standard, FIFO, Average) transfer to the corresponding Dynamics 365 fields. If PILOT:Suite uses variant dimensions (size, color, version), we map these to Dynamics 365 Product Variants with the variant dimension type configured in the destination before import. Item tracking (lot, serial) requires the inventory posting group and tracking policy configured in Dynamics 365 before item ledger entries load.

PILOT:Suite Warehouses map to Dynamics 365 Locations in Business Central or Sites and Warehouses in Finance and Supply Chain Management. We preserve the warehouse address, default bin structure, and any cross-docking flags. If PILOT:Suite warehouses have zone-level organization, we map them to Location zones in Business Central Premium or to Site-specific warehouse configurations in Finance and SCM. Location is loaded before any inventory transaction records so that item ledger entries reference valid locations at insert time.

PILOT:Suite Customer records map to Dynamics 365 Customer records, which in Business Central and Finance is an Account entity with a Customer role. We preserve the customer number as the source key, map the payment terms and credit limit to the respective Finance fields, and carry forward the price group to a Customer Price Group in Dynamics 365. Open AR balances at migration cutoff date load as Customer Ledger Entries with document dates set to the cutoff date and remaining open amounts reflecting post-migration activity. Ship-to and bill-to addresses migrate as address records on the Customer.

PILOT:Suite Vendor records map to Dynamics 365 Vendor records, which is an Account with a Vendor role. We preserve the vendor number as the source key, map payment terms, currency code, and any vendor-specific discount groups to the corresponding fields. Open AP balances at migration cutoff date load as Vendor Ledger Entries with open amounts carried forward. If PILOT:Suite maintains a unified party master (Vendor and Customer as one entity), we split by record type during transformation and create separate Account records with Customer and Vendor roles respectively.

Open Purchase Orders in PILOT:Suite map to Dynamics 365 Purchase Orders with status Open. We preserve order number, vendor reference, order date, expected receipt date, and line items with quantities and unit costs. If the PILOT:Suite PO has been partially received, the received quantity maps to a posted receipt and the remaining balance stays as open PO lines. Released versus draft PO status maps to the Dynamics 365 Released status. Fully received or closed POs in PILOT:Suite do not migrate as open documents; they are available in the historical reporting scope.

Open Sales Orders in PILOT:Suite map to Microsoft Dynamics 365 Sales Orders with status Open. We preserve the order number, customer reference, order date, shipment date, and line items with quantities and prices. If the PILOT:Suite SO has been partially shipped, the shipped quantity maps to a posted shipment and remaining open lines continue as order lines. Pricing, discounts, and line charges migrate from PILOT:Suite to Microsoft Dynamics 365 Sales Price and Line Discount records. Invoicing occurs post-migration through the normal Dynamics 365 order-to-cash cycle.

PILOT:Suite GL Accounts map directly to Dynamics 365 G/L Account records. We preserve the account number, account name, account type (posting, heading, total, and so on), and the account category (revenue, expense, asset, liability, equity). If PILOT:Suite uses a segment-structured account code (for example, 4-1-5100), we map the full segment string to the Dynamics 365 G/L Account number and configure any required dimensions for analytical reporting. The account type must be configured in Dynamics 365 before any ledger entries load.

Open AP and AR balances from PILOT:Suite at the migration cutoff date load as open Vendor Ledger Entries and Customer Ledger Entries in Dynamics 365 respectively. The entry date is set to the cutoff date, the remaining amount reflects the balance to be paid or collected post-migration, and the document type maps to Invoice or Credit Memo as appropriate. We flag any AP aging records with expired payment terms for the customer's accounts payable team to review post-migration. This step requires Finance or Business Central to be fully configured with the Chart of Accounts before it runs.

PILOT:Suite inventory quantities and valuations per warehouse map to Dynamics 365 Item Ledger Entries (quantity and location) and Value Entries (cost layers). We use a positive adjustment inventory journal to establish opening quantities at the migration cutoff date and carry forward any FIFO, Average, or Standard cost layers from PILOT:Suite. For FIFO and Average cost methods, the Dynamics 365 cost is set to the current unit cost from PILOT:Suite; Standard cost requires a Costing Version to be configured in the destination before the adjustment journal posts. Inventory transactions (receipts, shipments, adjustments) beyond the cutoff date migrate as a delta after go-live validation.

PILOT:Suite item-warehouse assignments (which items are stocked in which warehouses with what reorder point and safety stock) map to Dynamics 365 Item Stockkeeping Units (SKU). The SKU record combines the Item, Location, and variant dimension and carries the reorder point, reorder quantity, and default replenishment settings. SKU records are loaded after Location and Product2 exist so that the foreign key references are satisfied.

Historical vendor invoices in PILOT:Suite that fall within the agreed migration window (typically 12-24 months of open or recent closed history) load as posted vendor invoice records in Dynamics 365. We post each invoice with the vendor account, invoice number, invoice date, due date, and line items mapped to G/L accounts and items. This step requires G/L Account and Vendor to be loaded first. Closed invoices beyond the migration window remain available for reference in exported archives but are not entered as posted documents.

Historical customer invoices in PILOT:Suite within the migration window load as posted sales invoice records in Dynamics 365. We post each invoice with the customer account, invoice number, invoice date, due date, and line items mapped to G/L accounts and items. This step requires G/L Account and Customer to be loaded first. The posted invoices carry forward the original invoice amount and currency for financial reporting continuity. Invoices with partial payments are posted as open Customer Ledger Entries with the payment amount reduced accordingly.

PILOT:Suite BOM records (header with version, component lines with quantity per assembly) map to Dynamics 365 Production BOM records. The BOM number and version code preserve from PILOT:Suite, and component lines carry the item number, unit of measure, quantity per, and scrap percentage. Routing links for work-center assignments map to the Routing fields on the BOM version. We flag BOMs that reference discontinued Items for the customer's production team to review before the BOM version is certified. BOM structure is configuration-mapped, not migrated as transactional data; it is loaded before any production orders.

PILOT:Suite Work Orders map to Dynamics 365 Production Orders. We carry forward the production order number, item to manufacture, quantity, and status (Released, Finished, or part-finished). Component consumption and operation times from PILOT:Suite are preserved as comments or attachments on the production order since Dynamics 365 handles these through inventory journals and capacity journals respectively. Partially completed work orders at migration cutoff date load with the actual output quantity and remaining quantity to complete. Finished work orders that have no open quantity become closed production orders.

PILOT:Suite custom fields configured within its module structure map to Dynamics 365 extension fields on the corresponding entity. We identify each custom field during discovery by reviewing the PILOT:Suite field schema, map the data type to the nearest Dynamics 365 field type (text, decimal, integer, date, Boolean, option), and extend the destination entity schema before data migration begins. Custom fields that have no natural mapping to a Dynamics 365 entity are documented with field name, data type, and sample values for the customer to decide placement in a post-migration configuration session.

Trial balance and Chart of Account balances from PILOT:Suite at the migration cutoff date load as opening G/L Entries in Dynamics 365. We use the general journal with a dedicated opening balances journal batch, posting to each G/L account with the debit or credit amount that reflects the PILOT:Suite trial balance. Balance sheet accounts (assets, liabilities, equity) receive opening entries; income and expense accounts receive zero opening balances. The opening entry date is the business day before the go-live date. This step requires G/L Account configuration to be complete and locked before it runs.