How to inventory an Epicor Kinetic customisation estate — BAQs, BPM directives, Epicor Functions, UD tables, Application Studio layers and ERP 10 C# scripts — and map each surface to the D365 extension model, where all standard code is sealed and every change ships as a compiled, source-controlled extension.
Epicor Kinetic migrations to D365 Finance and Supply Chain Management are dominated by one reality: the customisation surface is the migration. The standard business processes — order-to-cash, procure-to-pay, plan-to-produce — have recognisable equivalents in both platforms.
The single biggest cultural shift for an Epicor development team is this: you cannot change the standard code. In Epicor, a BPM Method Directive fires inside a standard business-object method — it literally executes as part of the standard process. In D365, all standard metadata is sealed.
A BAQ is a saved query/dataset definition. It is the most pervasive customisation surface in any Epicor installation — a mid-sized manufacturing client may carry 200–500 BAQs, ranging from trivial single-table lookups to complex multi-table sub-query constructs with calculated fields.
A BPM Method Directive fires on a named Epicor business-object method — for example, SalesOrder.Update.Pre or JobEntry.CreateNewJob.Post. It can be implemented with the visual widget editor (condition blocks, set-field blocks, call-function blocks) or with custom C# code.
A BPM Data Directive fires on a database row event — insert, update, delete — either in-transaction (inside the committing transaction) or standard (after commit). It is used for validation, logging, field derivation and cross-record integrity enforcement.
Epicor Functions are the Kinetic-era replacement for embedding all logic in BPMs. They are versioned, callable from Application Studio, BPMs and REST, and encapsulate shared business logic in a testable, reusable unit.
Epicor's UD Tables (UD01 through UDxx, plus named user-defined tables) and UD Fields (custom columns on standard tables) are the mechanism for extending the data model at runtime, without code. They are exposed to BAQs, DMT, SSRS, BPMs and integrations.
Application Studio is Epicor's browser-based, no-code UI customisation tool — the Kinetic-era successor to the ERP 10 Smart Client customisation designer. It provides layers (overlay changes without modifying the base), client-side DataViews (data binding), and event-action rules (if/else logic, data assignments, BAQ/Function calls).
For clients still carrying ERP 10 C# client-side scripts, the situation is uniquely painful. These scripts run in the WinForms Smart Client — they execute events like BeforeAdapterMethod, AfterRowActivate and EpiViewNotification in a .NET desktop runtime. The Kinetic browser does not run them. They are already dead code in Kinetic.
For an estate of several hundred BAQs and dozens of BPMs, the triage must be systematic:
Epicor's reporting stack uses SSRS layouts driven by a Report Data Definition (RDD) that assembles data from BAQs, standard tables and UD fields. D365 also uses SSRS — but the data-shaping layer is different.
Solution Workbench packages customisations (BAQs, BPMs, dashboards, UD schema, Application Studio layers) for promotion between Epicor environments. In D365, this role is played by deployable packages promoted through Azure DevOps pipelines and the Power Platform admin center.
The Epicor Kinetic customisation surface is the migration. Standard business processes have recognisable D365 equivalents; the custom estate does not, and no mechanical conversion exists for any of it.