Migrate from Kinetic to Microsoft Dynamics 365 Business Central

Kinetic Customer records map to D365 Customer records. Kinetic uses a unified party model where a Customer record may also carry vendor-like address data. We split the source record into a D365 Customer and a corresponding D365 Vendor record where the source carries both roles. Primary address, terms, and payment method migrate to the Customer record; shipping addresses migrate as delivery addresses on the Sales Order or Sales Agreement.

Kinetic Vendor records map directly to D365 Vendor records. VendorID maps to VendorAccountNumber. Multi-address vendor setups migrate to D365 addresses with a primary address flag. PO approval workflow assignments require the Vendor record to exist before PO header import can proceed.

Kinetic Part records map to D365 Released Products with type classification (Item, Service, BOM, Route). PartNum maps to ProductNumber; TypeCode maps to the D365 Product Type. Source UOMs migrate to D365 unit of measure sequences. TypeCode mismatches — common in source systems with incomplete type classification — are resolved against the Kinetic PartClass before migration to prevent D365 product type errors.

Kinetic BOM records map to D365 Bill of Materials with version control. The BOM revision chain — including approval states, effective dates, and superseded revisions — is preserved as BOM versions in D365. Where the source lacks revision tracking, we create a default version 1.0 and flag it for the customer's BOM administrator to approve post-migration. Multi-level BOM structures are resolved recursively so that sub-assemblies are loaded in the correct dependency order before their parent BOMs are activated.

Kinetic Routing records map to D365 Route records with Operation sequences preserved as OperationSeq values. Each Kinetic Step maps to a D365 Route Operation linked to a Work Centre Group. Work Centre ID resolution requires the Work Centre to exist in D365 before the Route is imported; we validate Work Centre existence during the dependency check phase. Invalid step sequences — missing OperationSeq values or duplicate step numbers — cause D365 to reject the route on insert and are remediated before the load batch runs.

Kinetic Sales Order records migrate to D365 Sales Order with header and line phases loaded sequentially. OrderHeader must complete and generate a D365 SalesId before OrderDetail can reference the parent. Site and Warehouse on the order line must reference an existing D365 InventSite and InventLocation. We resolve the Site lookup at migration time using the source site's configured D365 site mapping.

Kinetic PO records map to D365 Purchase Order. PO headers and lines require Vendor and Site records to be present first. PO approval workflow state migrates as the current document status; any PO in pending approval state is flagged for re-approval post-migration since workflow rules are not migrated as code.

Kinetic Work Order (Job) records map to D365 Production Orders. The dependency chain is strict: Part, BOM, and Routing records must exist and be approved in D365 before a Production Order can reference them. JobNum generation rules vary by Kinetic site configuration; we either map to D365's auto-numbering scheme or preserve the original JobNum in a custom field depending on the customer's requirements. Estimated hours and actual hours from the source migrate as production order route job hours.

Kinetic GL Account records must be loaded first — before any transactional record — because every transaction in D365 references a Main Account. Account structures differ significantly: Kinetic COA segments (natural account, department, division, site) map to D365 financial dimension framework dimensions. We map the source account segments to D365 dimension attributes during discovery, build the destination COA in D365's Chart of Accounts, then validate that every transactional record's account reference resolves to a valid D365 Main Account before the transactional migration phase begins.

Kinetic Site records and their associated Warehouses map to D365 Sites and Warehouses. Multi-site configurations are fully supported. Site-specific parameters — default warehouse, shipping calendar, inter-site transfer routes — migrate as site configuration data. For organizations with inter-company database structures, each Kinetic company database maps to a separate D365 legal entity.

Kinetic Employee records map to D365 Human Resources Worker records. User and Owner assignments on transactional records require the Employee to exist first; we load Workers before any transactional migration phase that carries an OwnerId or AssignedTo reference. Effective-dated employment status changes and department assignments are preserved. For organizations using D365 Talent or HR, the Worker record also enables the HR-employee integration; otherwise it functions as a personnel record for assignment purposes.

Kinetic user-defined fields (UD Fields) vary per tenant and per object and are not documented in public API references. We discover the UD field schema during discovery by querying the Kinetic API's UD field metadata, then build a custom mapping layer that targets D365 extension fields created for the same purpose. Each UD field's data type is mapped to the equivalent D365 field type (string to Text, number to Decimal, date to Date). UD fields without a matching D365 extension are held in a supplemental table for the customer's D365 administrator to configure and map post-migration.

Kinetic BAQ (Business Activity Query) reports are custom SQL queries defined within the BAQ framework and do not export as reusable artifacts. We do not migrate BAQ reports as code. We audit every active BAQ during discovery, document its data sources, filters, calculated fields, and output columns, and deliver a written report inventory specifying the recommended rebuild path in D365 — either as a Power BI paginated report connected to the D365 Data Lake, or as an embedded D365 financial report. The rebuild is the customer's Dynamics partner's scope.

Kinetic Work Center records map to D365 Work Centre Groups with capacity type and scheduling parameters. Work Center scheduling parameters (capacity, efficiency, queue time) migrate as Work Centre Group capacity settings. Each Work Centre Group is linked to the Operations Resource used for route scheduling. Invalid Work Centre IDs in source routing records are caught during routing validation and remediated before the routing load phase.

Open and in-process inventory transactions from Kinetic migrate to D365 inventory movement journals and adjustment journals. Lot numbers, serial numbers, and inventory status flags map to D365 Inventory Dimension combinations. For organizations using lot or serial tracking, the lot and serial number setup must be configured in D365 before inventory transactions can be loaded with dimension references.

Open payables and receivables migrate as open invoice records with current document status. The Vendor, Customer, GL Account, and Terms records must exist in D365 before these documents load. Document balance amounts migrate as-is; any currency revaluation or payment-term recalculation required after migration is flagged as a post-migration finance task.

Kinetic stores document references, metadata, and binary files in the EDM (Electronic Document Management) system and object-specific attachment tables. Binary file migration requires either a file share path migration to SharePoint or OneDrive, or re-upload via the D365 REST API. We map document metadata (filename, description, linked entity) to D365 SharePoint document locations attached to the corresponding record. File content transfer is a separate file-migration scope handled in parallel with the data migration.