Golden Configuration Environment Replicator

Every Dynamics 365 Finance and Supply Chain Management project runs the same losing race. A consultant sets up posting profiles in development. Someone else fixes a number sequence in the test environment because a test failed. A key user changes a warehouse policy in user acceptance testing on a Friday. By go-live nobody can say with confidence which of the three environments holds the truth, and the first production defect turns out to be a configuration difference nobody recorded.

The platform gives you the raw materials. The data management framework can export and import configuration through data entities. Data packages bundle entities with a manifest. Copy into legal entity moves company-specific setup. What the platform does not give you is the discipline layer: an ordered, curated definition of what a golden configuration actually contains, a comparison that tells you how two environments differ before you touch either of them, drift detection that notices when someone changes something out of process, an approval step before a write lands in a target, and an audit trail afterwards. That layer is what people build by hand, badly, on every project.

What ECOSIRE builds

We build a licensed extension for Dynamics 365 Finance and Supply Chain Management, written in X++ as extension models only. No overlayering. The extension sits on top of the data management framework rather than replacing it, so your existing data entities, custom entities and entity extensions are all in scope, and your platform updates are unaffected.

A golden configuration you can define

We build configuration profiles: named, versioned, ordered sets of data entities that together describe a working configuration. Order matters, because a chart of accounts has to land before posting profiles and a dimension set has to exist before anything references it. We seed the profiles from your actual implementation, split shared entities from company-specific ones, and mark which entities are legal-entity aware so a promotion into a new company does the right thing without a person remembering the rule.

Profiles are data, so your team can extend them after we leave. Adding a newly built custom entity to the golden configuration is a setup change, not a development request.

Compare before you promote

The comparison engine pulls the same profile from two environments and produces a difference report at entity and record level: records present in source only, present in target only, and present in both with differing field values, field by field. It runs across environments over authenticated service endpoints, so you can compare your sandbox against production without exporting anything to a laptop.

The report is the artefact people actually want. It answers the question asked in every cutover meeting, which is not what should be different but what is different right now.

Promote with control

Promotion takes a comparison result, lets an owner select what moves, and writes it into the target through the data management framework. Before anything is written, dry-run mode produces the full change report with record counts and field-level before and after values, without writing a single row. Nothing is promoted silently.

Promotions can be routed through workflow so a functional owner or a change manager approves the set before it executes. Every executed promotion is logged with the user, the profile and version, the source and target environment, the entity list, record counts and the resulting status, and the log is queryable long after the project team has moved on.

Drift detection

A scheduled batch job snapshots the configuration profile at whatever cadence you choose and compares it to the last accepted baseline. When something moves outside the process, you find out from an alert on Monday morning rather than from a failed test three sprints later. Business events are raised on drift, so the alert can land in whatever channel your team already watches.

Packages, pipelines and the asset library

Exported configurations are written as standard data packages with their manifest and package header, so they remain usable with the platform tooling you already have and are not trapped inside our extension. Where your tenant and permissions allow it, packages can be pushed to and pulled from the LCS asset library, and the promotion step can be triggered from an Azure DevOps pipeline so configuration promotion sits alongside your code release rather than in someone's calendar.

Awkward configuration, handled deliberately

Some configuration resists a naive export and import, and we deal with each case explicitly rather than pretending it works. Number sequences carry collision and continuation rules. Financial dimensions and dimension sets are sequenced ahead of their consumers. Security roles, duties and privileges are compared as a set so a partial promotion cannot leave a role half-assembled. Electronic reporting configurations and print management settings are included where your scope requires them. Where an entity genuinely cannot be promoted safely, the profile marks it as manual and the documentation says what to do instead.

Who it is for

Implementation teams running a multi-environment build who lose days to configuration drift. Organisations rolling the same template out to a second, fifth or twentieth legal entity. Support and application managers inheriting an environment estate they did not build. Internal audit and compliance functions that need evidence of who changed which setup, when, and with whose approval.

How delivery works

It starts with a scoping call. We look at your environment topology, your entity landscape including customisations, your legal entity structure, and how your release process runs today. You receive a written scope and a fixed quote before any code is written.

On acceptance we build against your version in our own development environment and deliver a deployable package, with source in your Azure DevOps repository if you want it. We install into your Tier-2 or higher sandbox through your LCS pipeline, build your first configuration profiles with your team against real data, run a comparison and a dry-run promotion together, and then deploy to production on your change window. Typical lead time from signed quote to sandbox install is two to four weeks.

What this is not

This is not available for instant download and there is no free trial. It is built for you after a quotation. It is not a Business Central app. It does not promote code: X++ customisations continue to move as deployable packages through LCS and your Azure DevOps pipelines, and this tool moves configuration data only. It is not a substitute for a database refresh when you genuinely need one, and it will not invent a golden configuration for you. It moves, compares and guards the one you decide on.

After go-live

The build ships with a support window covering defect fixes and compatibility with service updates released inside it, plus handover of the profile definitions so your own team owns them. Ongoing support is quoted annually if you want it.