Go-live day usually gets celebrated. The system is up, the migration held, nobody's screaming on the help desk line. Everyone shakes hands, the implementation partner sends a wrap-up email, and the project gets marked complete.
Eight weeks later, a finance manager is still keeping a personal spreadsheet "just to double check the numbers." A sales rep is creating quotes in a Word template because the Business Central screen "takes too long." A warehouse lead has gone back to a paper count sheet because the mobile scanning workflow never quite clicked.
Nobody reported any of this. There was no ticket filed, no escalation, no formal complaint. People just quietly did what was familiar instead of what was implemented — and the project that was marked "successful" is now running at a fraction of its actual capability, with nobody measuring the gap.
The metric every project report has, and the one almost none of them have
Every implementation wrap-up report has the same metrics: went live on date, came in within budget, system passed UAT, training was delivered. These are all real, all important, and all measure the project — not the outcome.
What almost none of them measure is adoption: are people actually using the system the way it was designed, six weeks or three months after go-live? Not "did they log in." Not "did training happen." Whether the actual day-to-day work — creating the quote, processing the purchase order, running the reconciliation — is happening inside Business Central or has quietly drifted back to whatever workaround existed before.
That gap matters enormously and gets measured almost nowhere, because it isn't a project milestone. It's a behavior that happens weeks after the project team has already moved on to the next client.
Why this blind spot exists
It's not that implementation partners don't care about adoption. It's that the standard engagement structure isn't built to catch it. A typical implementation runs through go-live plus a stabilization period, then closes out. The partner's success criteria — and often their final invoice — are tied to the system functioning correctly, not to whether the organization has actually changed how it works.
Measuring real adoption requires checking back in weeks later, looking at actual usage patterns, and asking uncomfortable questions about why certain features sit untouched. That's not glamorous work, it doesn't fit neatly into a project timeline, and it's easy for everyone involved to assume "no news is good news" when nobody's complaining.
But silence isn't the same as adoption. People who've quietly reverted to old habits usually don't complain — they just work around the system instead of with it, and the organization absorbs that inefficiency without ever seeing it on a dashboard.
What low adoption actually costs
The financial case for measuring adoption isn't abstract. A system running at partial adoption produces specific, calculable costs.
Data quality degrades when half your team enters information into Business Central and the other half maintains it in a spreadsheet that never syncs back. Reporting becomes unreliable because the numbers in the system don't reflect everything actually happening in the business. Decisions get made on incomplete data without anyone realizing it's incomplete.
There's also a direct ROI problem. Companies invest significantly in licensing, implementation, and configuration based on a specific set of capabilities. If a third of those capabilities are quietly unused because adoption never fully landed, that's a third of the investment generating no return — invisible on a balance sheet, very visible in how much friction still exists in day-to-day operations.
What measuring adoption actually looks like
Track feature usage, not login counts
Logging in tells you nothing. What matters is whether specific workflows — the ones training was built around — are actually being used. Are sales orders being created in the system, or is that team still emailing quotes from a template? Are bank reconciliations happening in Business Central, or is finance still doing it the old way and entering a summary number after the fact? This requires looking at actual transaction and usage data, not assuming the dashboard tells the full story.
Set a 90-day adoption checkpoint, not just a go-live checkpoint
Adoption issues rarely show up in week one — early on, people are still following training closely because it's fresh. The drift back to old habits happens once that initial discipline fades and the path of least resistance reasserts itself. A structured check-in at 60 to 90 days post-go-live, specifically looking at usage data and talking to frontline users, catches the drift while it's still a habit and not yet a permanent workaround.
Ask the question your team won't volunteer
Most employees won't proactively report that they've reverted to an old process — it can feel like admitting failure, or like more trouble than it's worth to flag. Decision-makers need to ask directly, by role: what are you still doing outside the system, and why? The answers are usually specific and fixable — a screen that's slower than the old process, a report that doesn't exist yet, a step that wasn't explained clearly. None of that gets fixed if nobody asks.
Adoption is the actual return on investment
A Business Central implementation that goes live successfully but sits at 50% adoption isn't a success story — it's a partially realized investment with a hidden maintenance cost in the form of parallel spreadsheets, manual workarounds, and data that doesn't fully reconcile.
The organizations that get the most value out of Business Central treat go-live as the midpoint of the project, not the end of it. They measure adoption deliberately, they check in well past the point where most partners consider the engagement closed, and they treat low usage of a specific feature as a signal to investigate rather than a detail to ignore.
If your implementation partner's final report doesn't mention adoption tracking past go-live, that's worth asking about directly. It's the metric that actually determines whether the investment paid off.