Business Central on-premises or cloud: how to decide

Microsoft Dynamics 365 Business Central is sold in two deployments. Online, which Microsoft hosts, updates, and backs up, and on-premises, which runs on servers you own and maintain. Both are current products. Microsoft shipped a new major version of the on-premises edition in April 2026 and continues to ship monthly updates for it, so picking on-premises is not picking a dead end.

The two are close enough to look interchangeable and different enough that the choice reshapes the project around it. It changes which features you can use, who performs upgrades, what a partner has to ask before quoting, and what your team owns for as long as the system runs. It is worth settling early, because each path calls for a different discovery conversation.

What is the same either way

Start with the reassuring part, because it covers most of what an ERP evaluation is about. The core application is identical. Finance, sales, purchasing, inventory, projects, warehousing, and manufacturing all work the same way in both, and manufacturing sits in the Premium license tier in both.

Running several legal entities that trade with each other also works the same way in both. Intercompany posting and consolidated reporting are included in the lower Essentials tier rather than being Premium features or paid add-ons, and eliminations are a manual step in both. If your evaluation is mostly about whether the application fits how you run, the deployment question does not change that answer.

What you give up on-premises

This is the part that decides most projects, and the list is longer than people expect. Microsoft publishes its own account of features that either need extra work on-premises or are not planned for it at all. These are the ones that tend to matter.

Not available on-premises at all:

• Copilot and the AI features. Online only.
• The Business Central app for Microsoft Teams, including sharing a record into a Teams conversation. The app cannot connect to an on-premises deployment.
• Bank feeds. The built-in bank statement service works only online. On-premises you import statements yourself or commission custom code.
• The prebuilt Power BI report packs. You can still build your own reports against on-premises data, but the ready-made ones do not deploy.
• The Shopify connector, and the built-in company hub for working across several companies from one screen.
• Automatic backups with point-in-time restore, environment copies, and preview environments. Online keeps rolling backups and lets you clone an environment to rehearse an upgrade. On-premises you build the equivalents.
• The cloud migration tooling. It only moves data into the online service, so it is not a route into an on-premises deployment.

Available on-premises, with conditions attached:

• Power Automate, for workflow automation. There are two different connectors and the on-premises one is thin: five actions, no triggers, and still labeled preview. Nothing can start a flow from something happening inside on-premises Business Central. If automating approvals and hand-offs across your other systems is part of why you are replacing the ERP, this is the largest gap on the list.
• The standard web interface other software uses to talk to Business Central. It exists on-premises, but it cannot be reached through Microsoft's shared cloud address. Anything integrating with it connects directly to your servers, which means firewall rules, certificates, and a network path you own and monitor.
• The Excel add-in, Excel financial reports, and embedded Power BI. Each of these needs your on-premises servers wired into Microsoft Entra ID, the identity service behind Microsoft 365. Embedded Power BI also needs an application registration in Azure.
• The forecasting features. Sales, inventory, and cash flow forecasting need an Azure machine learning subscription of your own behind them.

What on-premises gives you that the cloud does not

The list runs the other way too, and one or two of these can be decisive.

• Direct control of the database. Table partitioning, compression, index and query tuning, and encryption at rest are all yours to set.
• Code that calls .NET directly. Extensions can call .NET components on the server when the deployment target is on-premises. In the cloud that route is closed and the equivalent is a small service running in Azure. For businesses integrating to plant equipment or older Windows components, this is sometimes the deciding capability.
• Traffic that never leaves your network. Intercompany transfers can move through a file share on-premises, which the cloud cannot do.
• Integration to an on-premises Dynamics 365 CRM deployment, which the cloud version does not support.
• No database size cap and no update you cannot postpone.

Updates are the difference people underestimate

In the cloud, Microsoft ships two major updates a year, in April and October, plus smaller monthly ones. You pick the date inside a window of roughly five months from release, then a one-month grace period where your options narrow, then Microsoft applies it. You can never fall more than one major version behind, and updates run inside a nightly window you set.

On-premises, the upgrade is yours to perform. Microsoft supports each version for about 18 months, with roughly three versions in support at any one time, so staying inside support means an upgrade project every 12 to 18 months. Monthly cumulative updates ship for on-premises too, and Microsoft's guidance is to install the latest one.

What on-premises asks of your infrastructure

An on-premises deployment has three required parts: a web server running Internet Information Services, the Business Central server itself, and SQL Server. They can share a machine or sit on separate ones.

Specifics worth checking against what you already own, for the version Microsoft released in April 2026:

• Windows Server 2022 or 2025. Windows Server 2019 and 2016 have dropped off the supported list. This one catches people out, because a server bought a few years ago may be running an operating system the current version no longer supports.
• SQL Server 2022 or 2025. Microsoft now states this as database compatibility level 160 or 170, which is what those two versions provide. SQL Server 2019 does not qualify.
• 16 GB of memory to run it, and 32 to 64 GB if you publish large customizations.
• Microsoft .NET 8 and .NET Framework 4.8 on the server tier.

One gap in Microsoft's documentation is worth naming. There is no published blueprint for making on-premises Business Central highly available. Microsoft documents splitting the web and application tiers across nodes and offloading read-only reporting, but designing failover is your work, using standard Windows Server and SQL Server tools.

Your shop floor, your machines, and the rest of your software

A single line from Microsoft's documentation settles most of this: Business Central online cannot reach into your local network. Equipment and systems in the plant call out to it, and it never calls in.

That is workable and common. Scanners, line computers, and machine software talk to a cloud tenant through published web addresses, or through middleware sitting between them. Barcode scanning is built into the mobile app. Shared stations are licensed per device rather than per person, so a station serves whoever is standing at it, with two caveats: a device user cannot be the first to sign in after a restart, and the number of device licenses you buy caps how many can be in use at once.

What Microsoft does not publish, in either deployment, is a reference design for plant equipment talking to Business Central. There is no first-party connector for machines or controllers. That integration is a design exercise involving middleware, an independent software vendor (ISV) product, or both, whichever path you pick. The real difference is direction of travel. On-premises the traffic stays inside your network and can use the .NET route. In the cloud, the plant makes outbound calls.

The same holds for CRM. Microsoft publishes no first-party HubSpot connector for Business Central in either deployment, and the connectors that do exist come from third parties. They are materially easier to work with against an online tenant, because the on-premises connector has no triggers and the shared web address is not available.

How the licensing differs

Full users come in two tiers, Essentials and Premium. Manufacturing is a Premium feature, and the choice binds per company: once a company is set to the Premium experience, an Essentials user cannot sign in to it. Alongside full users sit Team Member licenses for light use such as reading data and approving, device licenses for shared stations, and read-only access to Business Central data inside Teams for anyone holding a Microsoft 365 license. We cover that mix in more detail in Business Central licensing for manufacturing and in how Business Central licensing works.

One mechanic removes a common objection. Cloud subscription licenses carry what Microsoft calls dual use rights, which let you run an on-premises deployment on those same licenses instead of buying separate perpetual ones. Three conditions come with it: the rights end when the subscription ends, you can run the current version or up to two versions back, and Windows Server licenses plus their client access licenses are bought separately. There is a support consequence as well. Microsoft's own terms state that when you deploy under dual use rights, support for the on-premises deployment is not included, so support comes from your partner or from a support agreement you buy.

Microsoft publishes current per-user figures on its own pricing page, which is the right place to read them. On-premises figures are not listed there.

Where the cost lands

Microsoft publishes no cost comparison between the two, so treat any such comparison, including ours, as a model rather than a published fact. When we have priced both for a business of this shape, on-premises has come out higher, and the ERP licensing was rarely the reason. Two costs do most of the work.

The first is getting it running. An on-premises deployment adds server and database setup, identity wiring, certificates, a network path for every integration, and a backup and recovery design that the cloud service provides as standard. That is professional services time spent before anyone posts a transaction.

The second is keeping it running, for years. Operating system patching, SQL Server maintenance, backups somebody tests, an upgrade project every 12 to 18 months, and capacity planning as the database grows. That cost recurs for the life of the system, whether your own staff carry it or an IT partner does.

Set against that, the cloud subscription bundles the infrastructure, the updates, the backups, and the recovery.

Hardware you have already bought is a fair thing to weigh, and it deserves an explicit answer rather than a shrug. It is money already spent under either choice, though, and it rarely decides the question by itself. Servers and a database license do not remove the labor of running an ERP on top of them.

When on-premises is the right answer

None of this makes on-premises the wrong choice. It is the right one when something specific requires it:

• A contractual or regulatory obligation that data stays on hardware you control.
• An availability requirement tied to plant equipment, where a network outage cannot be allowed to stop production. This one is worth testing rather than assuming, because much of a shop floor keeps running on line computers through an internet outage.
• A dependency on something only the on-premises deployment can do, most often direct .NET calls or an integration that cannot make outbound connections.
• An internal policy you are not in a position to change.

If one of those applies, on-premises is a genuine option, and the work is to scope it properly rather than to argue you out of it.

A checklist you can take to a committee

1. Is there a hard requirement forcing data onto your own hardware? If yes, on-premises is on the table, and everything below is about cost rather than eligibility.
2. Do you want Copilot, the Teams app, bank feeds, or workflow automation reaching across your other systems? Each of those is cloud-only or materially reduced on-premises.
3. Who performs an upgrade every 12 to 18 months, and is that in their calendar and your budget?
4. Do your existing servers run Windows Server 2022 or 2025, with SQL Server 2022 or 2025? If not, hardware you already own may not qualify for the current version.
5. Who owns backups, recovery testing, and failover, and has that design been written down?
6. Which of your integrations need something to reach into your network, rather than call out of it?
7. Are you prepared to own operating system and database maintenance for the life of the system, or would you rather that sit with Microsoft?

If question one is a no and questions two through seven point at the cloud, the cloud service is usually the shorter and cheaper path. If question one is a yes, the job is to scope on-premises with clear eyes.

If you are weighing this yourself

The deciding factors are usually total cost over several years and who carries the upkeep, and both depend on specifics: your server estate, your integrations, and how much of your floor has to talk to the ERP. If you are sizing up an ERP move and cannot tell which door fits, bring us your current setup and the integrations you cannot give up, and we will walk through what each path would ask of you.