Two different products share the name

Insights

The question is almost never "can this person write X++". It is whether the person you are about to hire, or the partner you are about to sign, understands a twenty-year-old application that you are not allowed to modify directly, that Microsoft updates on its own schedule, and whose most expensive defects look like perfectly correct code. Most of what goes wrong on a Dynamics 365 Finance & Operations project is decided at staffing, before anyone opens Visual Studio. Here is what that decision usually misses.

"Dynamics 365" spans at least two unrelated engineering worlds. On one side sits the Dataverse and Customer Engagement family: model-driven apps, C# plug-ins, solution files, Power Platform tooling, JavaScript in forms. On the other sits Finance & Operations: X++, the F&O development tools in Visual Studio, an application object server, Azure DevOps builds, deployable packages, Lifecycle Services. A genuinely strong developer on one side may never have opened the other.

Job adverts, CVs and agency shortlists mostly fail to distinguish them, because the product name does not. Keyword filters make it worse: both candidates match "Dynamics 365", "ERP", "Microsoft", and often "C#".

Screen on the vocabulary of the thing you actually run. For F&O, ask how they would extend a standard method, what chain of command requires of the class and the method, what database synchronisation does and when it hurts, how a deployable package reaches a sandbox. If the answer comes back in terms of plug-in registration steps and solution layering, you have found a capable Dataverse developer and the wrong person for this job. That is a screening failure, not a candidate failure, and it is entirely avoidable.

X++ is a small language. A competent C# developer can read it in days and write it acceptably in a few weeks. Treating that as the hire is the most common mistake in this space.

What takes months is the application. The value in an experienced F&O developer is almost entirely knowledge of how the standard product already behaves, and most of it is unwritten:

Since roughly 2018 you cannot overlayer standard application code. Customisation happens through extension classes, chain of command, event handlers, delegates and table or form extensions. This was a real improvement. Two consequences still surprise people who budgeted on the strength of it.

First, extensibility is not guaranteed. If the standard code does not expose the seam you need, because the method is private, the class is sealed, or the logic you care about is a local variable halfway down a long routine, the sanctioned route is to ask Microsoft to add a hook and wait for a release. That is a schedule dependency you do not control. In planning it tends to appear as "we will find a way", which in practice often means a copy of the standard routine with one line changed. That copy is now yours forever, and it stops tracking the original.

Second, the updates keep coming. Under One Version you take platform and application updates on Microsoft's cadence rather than yours. The extension model makes most of them uneventful. It does not make them free, because your handlers are attached to code that changes underneath them. The recurring cost is regression testing, and the teams that cope have automated it, typically by recording business processes and replaying them. The teams that do not cope are running manual user acceptance testing several times a year, indefinitely, and calling it bad luck.

Builds. Database synchronisation. Cross-reference updates. Package deployment. Service restarts. Refreshing data from a sandbox down to a developer environment. Each is individually unremarkable and together they set the pace of the team.

Development does not happen in production, and it does not happen in a shared multi-box sandbox. Developers need their own environment, which is a cost and an administrative dependency rather than a laptop. Getting production-like data onto that environment is a deliberate procedure, not a restore command. And there is no direct SQL write access to production, so the diagnostic reflexes a SQL-fluent developer arrives with do not transfer unchanged.

Do not take my word for the proportion, and do not trust anyone who gives you one. Have the team log time spent waiting on builds, syncs and environment operations for two weeks before you commit to a delivery rate. It is the cheapest measurement available and almost nobody takes it.

The most valuable person on an F&O team is often the one who can read the standard application and say: this already exists, you are describing the workflow engine, or trade agreements, or product variants, or the allocation rules.

Most organisations staff for people who can write X++ and not for people who can read it. The result is a bespoke approval flow next to the workflow engine, a custom price table next to the pricing one, a hand-rolled posting routine next to the framework that was going to do it correctly.

A code review that asks only "is this correct?" passes every line of that. The question worth adding is "what standard feature does this shadow?" Because each of those duplications carries the update cost forever, and quietly removes you from the product's own roadmap. When Microsoft improves the feature you reimplemented, you get the regression risk and none of the benefit.

Development work on a migration is estimable, roughly. The data work is where plans come apart.

Opening balances. Inventory on hand with cost. Open transactions. Dimension combinations that must exist before a single posting will succeed. Master data arriving from a system with a different key structure and no concept of legal entity. You load most of it through data entities, and entities behave like application code rather than like tables: validation runs, defaults apply, sequences are consumed, and throughput varies enormously from one entity to the next. The shortcut of writing directly to SQL is unsupported and bypasses exactly the logic that makes the data valid.

Plan for repeated loads rather than one. The first load's real output is a list of everything wrong with the source data, and the people who can fix that are the data owners, not the developers. That is usually the true critical path.

There is no honest general answer for how long this takes. It depends on the number of legal entities, the state of the source system, and how much history the business insists on carrying across. Anyone who quotes a duration before seeing your actual data is guessing, and you should treat the number accordingly.

Most F&O customisation is written by a partner. That is a reasonable model. It becomes a trap when the artefacts of the work stay on the partner's side, because then switching partners means rewriting rather than transferring.

Make these deliverables, in writing, from the start:

If you are making this decision now, do four things. Decide which Dynamics 365 product you actually mean and rewrite the role description so a keyword search cannot mislead you. Screen for the ability to read the standard application, not for years of X++ on a CV, and expect several months of application learning even from a strong general developer. Put maintenance in the budget as a permanent line rather than a project phase, because the update cadence is not yours to control and your extensions are attached to moving code. And start the data work before the development work, because that is where the schedule will actually be decided. We cannot tell you your numbers: how long your migration takes, how much of your developers' day disappears into builds, how much of your customisation the product already does. Those are measurable in your own environment within a fortnight, and measuring them is a better investment than any estimate someone hands you, including ours.

Talk to us about this