How to prove a Dynamics 365 performance fix actually worked (instead of assuming it did)
The "it feels faster" trap
A team spends two days investigating a slow process, applies an index change or a configuration tweak, and someone opens the form the next morning and says it feels faster. That sentence ends most D365 performance investigations. It should not, because "feels faster" is a subjective impression collected from one person, at one moment, under conditions nobody measured.
The absence of a complaint is not proof the problem is gone. It might mean the fix worked. It might mean nobody hit the same edge case this week, or that today's data volume happened to be lighter, or that the person who normally notices is on leave. Without a measured before and after, there is no way to tell the difference, and the same issue tends to resurface a month later with no memory of what was tried or what changed, which means the whole investigation effectively starts from zero again.
Why this keeps happening even in mature IT teams
It is not a discipline problem, it is a tooling problem. Capturing a proper baseline requires having the right metric already being recorded before anyone knew there would be a problem to fix. Most teams only start measuring once something is already painful, which means the "before" picture is reconstructed from memory, a support ticket timestamp, or a vague sense that things used to be faster. None of that holds up when someone asks for evidence six weeks later.
What a real comparison requires
Proving a fix worked means comparing the same metric, under comparable conditions, across two points in time: before the change and after it. That sounds simple, but three things routinely go wrong.
Different metrics
The team measured CPU before the fix and query duration after it. The two numbers cannot be compared, even if they both look better, because they are not describing the same thing. This mismatch is easy to miss in the moment and impossible to fix retroactively once the "before" window has passed.
Different conditions
The "before" measurement was taken during a quiet period and the "after" measurement during a busy one, or vice versa. Load, not the fix, explains the difference. A fair comparison needs a similar time of day, a similar day of the week, and ideally a similar data volume on both sides of the change.
No baseline at all
The team never captured the original numbers, so there is nothing concrete to compare the improvement against beyond memory. This is the most common failure mode, and it is entirely preventable if the metric was already being tracked continuously rather than measured on demand.
Building a baseline before you touch anything
The discipline that fixes all three problems is simple to state and easy to skip under deadline pressure: capture the metric you plan to change, across a representative time window, before you make the change. That baseline becomes the reference point. After the fix ships, the same metric, over a comparable window, either matches the baseline improvement you expected or it does not.
This is exactly what a continuous monitoring layer gives you that a one-off test does not: the baseline already exists, because it was being captured the whole time, not just on the day someone remembered to check. Nobody has to predict in advance which query will regress next month, because the data for every query, every AOS metric and every batch job is already there when the question comes up.
What this looks like in practice
A regression appears after a One Version update. Instead of applying a change and hoping, the team pulls up the exact SQL and AOS metrics from before the update, compares them to the days immediately after, isolates the specific query or process that changed behavior, and after applying a fix, checks the same metric again over the same kind of time window. The fix is either confirmed with numbers or it is not, and either way, the answer takes minutes instead of a guessing game that resurfaces next quarter.
The organizational payoff of proof
Beyond the technical satisfaction of knowing a fix worked, there is a quieter benefit: a documented before and after builds a record that survives staff turnover, vendor changes, and the natural fading of institutional memory. Six months later, when someone asks "didn't we already fix this once," the answer is a chart, not a shrug.
If your team is still relying on "it feels faster" to close performance tickets, it's time for a baseline that's already there when you need it. Performance Monitoring by XPLUS continuously captures SQL, AOS and batch job metrics across your D365 environment, so every fix can be measured against real before-and-after data, not memory.