Business Central on-premises vs SaaS

Business Central is available in two deployment shapes: on-premises (you host it on your own hardware or in your own Azure subscription) and online / SaaS (Microsoft hosts and operates it). Both run the same product core, but the operational model, customisation model, and feature parity diverge in ways that matter to the buying decision.

SaaS (Business Central online). Hosted in Microsoft datacentres. Microsoft handles infrastructure, updates, backups, scaling. Customers configure and customise within the constraints of the SaaS model. Updates are continuous — minor monthly updates and two major waves per year, applied by Microsoft on a published schedule. The dominant deployment for new customers since around 2018.

On-premises. Installed on customer infrastructure — either physical, customer's Azure / AWS / Hyper-V, or a hosting partner's environment. The customer owns the SQL Server, the Business Central server, the management portal. Updates are applied when the customer chooses. The historical deployment model; still the choice for some regulated industries and customers with deep customisations.

Feature differences.

• Microsoft AppSource. SaaS-only — most ISV apps are SaaS-only since around 2022.
• Power Platform integration. Both, but SaaS has tighter, more automatic integration; on-premises requires hybrid configuration and a Power Platform Dataverse gateway.
• Copilot features. SaaS only — AI features depend on Microsoft cloud services.
• Embedded apps and Teams integration. SaaS only.
• C/AL on-premises legacy. On-premises can still run a hybrid C/AL + AL model if customers haven't fully migrated; SaaS is AL-only.
• Custom dev tools. SaaS has a sandboxed environment per tenant; on-premises has direct service tier access.

The SaaS feature set is broader and grows faster. Microsoft's investment is unambiguously SaaS-first.

Customisation model.

• SaaS — only extensions in AL. No direct database changes, no per-tenant code on the service tier. Per-tenant extensions deployable; AppSource for global ISV apps.
• On-premises — extensions, AppSource apps, and additionally direct service-tier modifications if the customer chooses. The freedom is wider but the maintenance burden is heavier.

The "no direct service tier" rule in SaaS is what enables continuous Microsoft updates without breaking each tenant — but it also means some legacy modifications (deep base-app rewrites) can't migrate as-is.

Cost.

• SaaS — per-user subscription, no infrastructure cost, no admin labour for hosting. Predictable, growing linearly with users.
• On-premises — perpetual licence (or BREP subscription) + SQL Server licence + infrastructure cost + admin labour. Lower marginal cost at scale but higher upfront commitment.

For most mid-market customers, SaaS is cheaper TCO once you account for admin labour and update overhead. For very large customers with existing infrastructure, on-premises can be cheaper at scale but requires real ops capability.

Update cadence.

• SaaS — automatic. Two major waves (April and October) with a one-cycle deferral option. Minor updates monthly.
• On-premises — customer chooses. Many run a major version behind to wait for ISVs to certify on the latest. Updates can be deferred indefinitely (within Microsoft's support window — typically Mainstream + Extended).

Performance and scale. Both can handle a few hundred concurrent users without issue. SaaS isolates each tenant in Azure SQL Database; on-premises shares SQL Server resources across tenants. Large customers running into SaaS limits are a known but rare scenario; Microsoft offers premium SaaS tiers and dedicated capacity for the largest.

Data residency. SaaS is hosted in Microsoft datacentre regions you select at provisioning. Some regions and some regulatory regimes still require on-premises (or a partner-hosted sovereign cloud). For most regions, SaaS data residency is sufficient.

Migration path on-premises → SaaS. Microsoft provides cloud migration tool moving data from BC on-premises (and NAV 2015+) to BC SaaS:

1. Install the on-premises cloud migration tool.
2. Authenticate against the SaaS tenant.
3. Replicate selected companies and data.
4. Validate; cut over.

Extensions must be re-deployed against SaaS. Custom modifications need rebuilding as extensions. Plan months for a real migration.

When on-premises still wins.

• Regulated industries with strict data sovereignty.
• Very deep customisations that haven't been refactored to extensions.
• Specific integrations to on-premises legacy systems that can't be opened up.
• Customers with strong opinions about cloud and a true on-premises ops capability.

When SaaS is the choice. Everyone else. New BC deployments default to SaaS unless there's a specific reason to do otherwise.

Common pitfalls.

• Lift-and-shift expectations. Customers expect on-premises customisations to "just work" on SaaS. They don't; refactoring is required.
• Update unpreparedness on-premises. Skipping updates for years; major version jumps become painful migrations.
• AppSource availability. Customers move on-prem to SaaS and discover the partner extension they relied on isn't certified for SaaS.

The strategic direction is unambiguous: SaaS is the future. New investments should plan accordingly.