Migrate your Kinetic data

Customers maps 1:1 via DMT or REST API. Standard fields (CustID, Name, Address, Terms) are stable across Kinetic versions. We migrate customer records as the first step since Sales Orders depend on them.

Vendor records transfer cleanly via DMT. Primary key is VendorID. We handle multi-address vendor setups and preserve PO approval workflow assignments.

Parts have the largest field surface in Kinetic — PartNum, TypeCode, UOMs, Cost, Class, COMCAT behavior. Source systems frequently use different part-numbering schemas or omit the TypeCode entirely, which we remap during staging.

BOMs are migration-critical because Kinetic enforces BOM revision and approval states. We preserve the BOM revision chain, and where the source system lacks revision tracking, we create a default revision 1 at migration time.

Routings reference Operations, Work Centers, and Sequences. Dirty data — missing step sequences or invalid Work Center IDs — causes Kinetic to reject the routing on load. We validate Work Center existence before inserting routing records.

Sales Orders have phased loading: Header first, then Details, then releases. Order type, terms, and ship-from site must exist in Kinetic before order lines can be added. We sequence the load to respect this dependency order.

PO headers and lines require Vendor and Site records present first. We handle PO approval workflow state by migrating the current status and flagging any that need re-approval post-migration.

Work Orders depend on Part, BOM, and Routing records. JobNum generation rules vary by site configuration. We map source JobNum patterns to Kinetic's auto-numbering scheme or preserve original IDs where the customer requests it.

Chart of Accounts must exist before any transactional records load. Account structures differ significantly between source systems and Kinetic's COA layout. We handle natural account vs segment mapping and validate account type codes.

Site records and their associated Warehouses transfer cleanly. Multi-site configurations are supported. We preserve site-specific parameters like default warehouse, shipping calendars, and inter-site transfer rules.

Employee records map to Kinetic's Employee table. User/Owner assignments on records require the Employee to exist first. We handle effective-dated employee status changes and preserve department and location assignments.

Kinetic supports user-defined fields (UD Fields) on most business objects. These fields vary per tenant and per object. We discover the UD field schema during discovery, then map source custom fields into the correct UD column names at migration time.

Kinetic stores document references and metadata in EDM and on object-specific attachment tables. Binary file migration requires either a file share path migration or re-upload via the Kinetic API. We flag binary attachment volume early so the customer can decide on a path.

Open payables and receivables require the Vendor/Customer, GL Account, and Terms records to exist. We migrate current open document balances and flag which records need payment-term recalculation post-migration.