How Epicor's development tooling — Solution Workbench packaging, EpicWeb-guided configuration, Task Agent scheduling and the habit of hot-fixing BPMs in production — maps to Visual Studio, Git, Azure DevOps build pipelines, deployable packages, the Power Platform admin center and the D365 batch framework; and why the change process itself is the hardest thing to migrate.
The previous two chapters covered what to build (the disposition framework) and how to write it (the X++ language). This chapter covers how to ship it — and for an Epicor team, the shipping process is the hardest thing to migrate.
D365 development happens in Visual Studio with the Finance and Operations developer tools extension. The development environment is a dev box — either a cloud-hosted Azure VM or a locally hosted VM — running a single-user instance of the D365 application stack (AOS, SQL Server, batch service, reporting services).
At build time, the pipeline compiles all models in the repository, links them into packages, and produces a single deployable package (a zip file). That zip is the artefact that flows through the deployment pipeline.
No production access. There is no RDP, no database query tool, no way to modify code or configuration that requires compilation in production. Diagnostic data comes from Trace Parser, SQL Insights, and sandbox environments refreshed with production data.
All X++ source is stored in a Git repository — typically hosted in Azure DevOps (Azure Repos) or GitHub. The repository contains the model folder structure: one folder per model, one sub-folder per metadata type, one file per object.
Epicor's DMT (Data Management Tool) provides bulk import and export via business objects — loading master data, transactional data and configuration without code. The D365 equivalent is the Data Management Framework (DMF).
Epicor's Task Agent schedules server-side processes — SSRS report bursts, MRP regeneration, custom batch operations, data cleanup jobs. The D365 equivalent is the batch framework.
D365 Finance and Operations receives service updates on a published cadence. At least two updates must be taken per year, and customers may pause one at a time. Each update applies Microsoft changes to standard code, metadata and platform components.
This deserves its own section because it is the single hardest cultural change for an Epicor team.
The tooling and process changes are as significant as the technical ones. An Epicor team moving to D365 is not just learning a new language — it is adopting a fundamentally different delivery model where every change is compiled, source-controlled, pipeline-built and sandbox-validated before it touches production.