In the 82nd Areopa webinar, David Singleton takes a step back from the usual conversation about C/AL versus AL, web client versus Pages, or pipelines and automation, and asks a harder question: what really changes for a partner when the product moves from Dynamics NAV to Business Central? Moderated by Luc van Vugt, the session focuses on the partner business model — revenue, cost, repeatability and the journey from monolithic projects to recurring monthly services.
David is explicit about his audience: this is not a session for someone starting a brand‑new Business Central practice on a green field, nor for ISVs and vertical providers. It is aimed at partners who have a Navision customer base and are transitioning that base into Business Central while keeping the lights on.
Where the journey started
David traces his own “NAV in the cloud” story back to 2014, when the SQL team in the Middle East invited him to present at the Azure Summit in Dubai after they were unable to get the Navision group involved. Azure was new, Business Central did not yet exist, and the talk was largely a projection of where the product and the partner business might go. Some of those predictions held up, others did not — but the exercise of looking at the business model, not just the technology, set the pattern for everything that followed.
The dinosaur and the agile team
David’s first contrast is the people model. A classic Navision partner could be built around a “dinosaur” — a single, deeply experienced consultant who could analyse, design, develop, configure, train and support an entire implementation. That was viable because most consultants grew up with the product over many years and accumulated their skill set incrementally.
That model does not survive in a Business Central practice. Training one graduate to cover the full surface of BC fast enough to be profitable is, in his words, simply not financially possible. A BC practice needs a team of specialists, each with a narrow scope, working a much more automated process.
The other items in the comparison follow the same logic: large one‑off custom implementations versus repeatable solutions, upfront sales revenue versus recurring monthly revenue, on‑site one‑to‑one consulting versus automated online self‑service, 12–24 month deployments versus a target of around 30 days to first invoice, and heavy dependency on consulting services versus reliance on automation and self‑service. As David notes, none of this is really about the product — it is about how the business makes and spends money.
An interesting historical aside: Jesper Balser already demonstrated what we now call extensions in the DOS version of Navision in 1996 — separate tables, no fields added to base tables, no code modifications. Almost nobody used the pattern because modifying the base application was simply easier. The cost of that decision is exactly what the modern extension model is trying to pay back.
📖 Docs: Extension types and scope — Microsoft’s reference for global apps, AppSource apps and per‑tenant extensions, which is the structural foundation for the “repeatable solutions” David argues a BC practice has to build.
The audience: where partners actually are today
Rather than lecture, David uses Slido to survey the room across six dimensions: split between classic NAV license revenue and monthly BC user revenue, how consulting work is billed, time from project start to first customer invoice, share of implementation done by the customer themselves through self‑service, what version customers are on, and how testing is done. The answers confirm what the rest of the session will argue: most partners are doing both. They have a NAV practice and a BC practice running side by side, billing is still predominantly hourly, fully automated test coverage is rare, and the BC user base is still small.
Revenue and cost: the real lock‑in
David’s central claim is that the biggest difference between a NAV partner and a BC partner is not technology, it is cash flow.
In the NAV model, a partner typically grew out of consulting work, eventually landed a customer, sold a large license up front — perhaps a 30‑user system at around a hundred thousand euros — and lived off that initial chunk of revenue while the implementation was delivered over 12 to 24 months. There were small follow‑on bumps for new reports, annual maintenance or extensions, but the revenue shape is dominated by one large spike at the start.
A true Business Central practice cannot work like that. The partner is no longer selling services and a perpetual license; they are selling a product — apps, training courses, self‑service material — and the customer pays a monthly per‑user fee once they are deployed. That means the practice has to build the apps, the training and the automation before the customer revenue starts flowing, and then absorb roughly a year of zero income from each new customer before the monthly invoices catch up.
David’s illustrative graphs make the shape of the difference very clear. On the NAV side, monthly revenue spikes hard at the start, drops, and then shows small follow‑on bumps. On the BC side, monthly revenue is flat near zero for the first year and then climbs steadily as users and granules are added.
The cumulative view tells the same story differently: the NAV project banks a big chunk early and then flattens; the BC subscription starts at nothing and grows continuously.
When the same data is normalised to revenue per user per month, NAV starts high — well above a thousand dollars per user in the early months for the example shown — and decays over three years toward a few hundred. The BC line starts at zero and climbs into a comparable per‑user range. David is careful to flag that the absolute numbers are illustrative; the shape is the point.
Repeatability is the real key
If repeatability is the problem, recurring revenue is the solution. The economics only work for a BC partner because the same app, the same training course, and the same configuration pattern can be sold many times. That is also why a green‑field BC practice would need a substantial upfront investment — David’s rough estimate is on the order of 30 employees and several million euros in headcount to build out the full process from scratch. Most existing partners do not start from zero; they convert an existing NAV practice, but the apps, automation and self‑service material still have to be built and paid for somehow.
📖 Docs: Deploying a tenant customization — how per‑tenant extensions are uploaded, versioned and upgraded, which is the technical mechanic behind “we no longer change the base, we ship apps”.
Can we have both?
David’s answer, supported by his Slido results, is yes — and probably for some time to come. Almost no one in the room has switched off the NAV tap entirely. Most partners run both practices in parallel and migrate customers as fast as the customers themselves are ready. He pushes back hard against the social‑media narrative that “everything has to be in the cloud tomorrow”, and uses the petrol‑to‑electric car analogy to make the point: when capacity to switch is roughly 3% a year, it is more useful to build many small electric cars than to keep designing 900‑km range trucks that almost nobody actually needs.
What David does push as the first step is decoupling that question from billing. In 2017 he was averaging 148 hours per month of billed time. In 2018 he switched his customers to a fixed monthly recurring fee — the customer pays the same amount every month, no time sheets, no last‑minute rush jobs. By 2023 he was billing 19 hours per month on average. The customers paid the same total amount or less; what changed was the revenue shape and the operational overhead on both sides.
In his experience, partners who claim to have “moved to BC” but still sell a 70‑dollar license bundled with a hundred‑thousand‑dollar services project have only changed the product, not the model. Getting out of hourly billing is, in his view, the prerequisite for everything else.
The numbers
David’s biggest open frustration is the lack of clear public numbers on the BC install base. The figures on his slide — roughly 175,000 NAV customers and 2.7 million user licenses against perhaps 27,000 BC customers and 225,000 user licenses, with 3,500 NAV partners and around 2,200 BC partners — are pieced together from Microsoft comments at Directions and other sessions, and he is open that the exact figures may be off. The conclusion he draws is harder to dispute: if you want to build an app and make money on it, you need to know how big the market is. Today the BC market on its own is not yet big enough to support all the partners who have signed up to it, which is another reason that the NAV business and the BC business have to coexist for the foreseeable future.
📖 Docs: Migrate on‑premises data to Business Central online — the supported migration paths from NAV, BC on‑premises, GP and SL, including the requirement to come up through Business Central on‑premises before switching to online.
📖 Docs: Supported upgrade paths to Business Central releases — the version‑by‑version map showing that NAV 2015 through 2018 customers still have to come through Business Central Spring 2019 (v14) and convert C/AL to AL before landing on a current release.
Danger ahead — and the things that still have to be solved
David closes the main deck with a list of issues that the industry, in his view, still has to address: the App Store and recurring revenue model itself, the upfront investment it requires, in‑house training rather than poaching consultants from other partners, the reality that “quiet quitting” has changed what consultants are willing to do, repeatability and automation as non‑negotiables, the observation that customisations have to become apps, and finally an honest acknowledgement that the old monolithic model still works and that cloud is not automatically cheaper.
Are we there yet? No — not even close. But, David argues, that is fine, as long as partners keep selling, keep training people, and keep the product alive while the model catches up.
Q & A — the practical questions
The Q&A pulls out a few useful clarifications.
Ted Johnston describes a setup where a customer pays a monthly fee for a maintained, tested product and pays one‑off charges for genuinely customer‑specific work. David’s reaction is that this is the “perfect compromise” — exactly the kind of hybrid that the numbers in the session predicted partners would converge on.
Arthur van de Vondervoort raises two points. First, what about customers who simply refuse to pay services per month per user? David agrees this happens; the unit of recurring billing does not have to be users — it can be tied to sales people, customers, granules of functionality, or any other meaningful capacity metric. The key is that it is a fixed monthly fee, not an hourly invoice. Second, what about customers who feel they will pay more over the long term under a monthly model? The graphs answer that directly: the per‑customer total is lower because the same code is amortised across many customers, but the partner makes more because they sell the same tools many times.
Eric (the Danish “dinosaur” David name‑checks more than once) asks how to fit ad‑hoc customisations into recurring payment. David’s short answer is “they become apps”. Luc adds the practical extension: a customer on a monthly subscription can also simply call when they need something, with the same hourly ceiling discussion happening inside an existing relationship rather than as a separate sales motion.
Key takeaways
- The defining difference between a NAV partner and a BC partner is the revenue and cost model, not the technology stack.
- A Business Central practice has to invest up front in apps, automation, training material and self‑service before recurring revenue starts to flow — typically about a year of near‑zero income per new customer.
- Most partners today run a NAV practice and a BC practice in parallel, and the numbers suggest they will continue to do so for some time; there is no need to “switch off” Navision overnight.
- Getting off hourly billing and onto a fixed monthly fee is, in David’s view, the first concrete step toward a BC‑shaped business — and one that customers usually prefer.
- Repeatability is the real key. Customisations have to become apps; one‑off code is incompatible with the BC economics.
- The BC install base is still small relative to the partner population, which is another reason the old and new models will need to coexist.
References mentioned in the webinar
- Areopa Academy — webinar series host.
- Areopa Webinars on YouTube — full recording archive.
- Areopa Webinars newsletter — upcoming session announcements.
- Slido — used for the live audience polls.
This post was drafted with AI assistance based on the webinar transcript and video content.