Building Scalable Business Central SaaS Solutions: Multi-Tenant Architecture, Data Isolation, and Performance Optimization for Managed Service Providers
If you are building managed services on top of Business Central, you face a recurring architectural tension. The platform wasn’t purpose-built for multi-tenant SaaS from the ground up the way pure cloud-native tools are. But it also cannot be treated as if each customer gets a separate on-premises deployment. The result is a set of hard choices about how to layer multi-tenancy, isolate data, scale databases, and manage performance when dozens or hundreds of customers share underlying infrastructure.
Most MSPs solve this by running one Business Central instance per customer (customer-dedicated), which is operationally simple but economically weak once you scale beyond a handful of tenants. Every new customer means a new database, new license costs, and new operational overhead. The alternative, true multi-tenancy (many customers in a single Business Central instance), unlocks economics but requires careful architecture to prevent performance collapse, ensure data isolation, and handle scaling.
The Multi-Tenancy Trade-Off
The starting assumption should be clear: Business Central’s native architecture is per-company, not per-customer. A Business Central instance can hold multiple companies, but the platform was designed for a single enterprise with multiple business units, not for multiple independent customers. Moving to true multi-tenancy (one instance, many isolated customer datasets) requires architectural work on top of Business Central, not within it.
The practical options are three. Customer-dedicated (one instance per tenant) is the operational baseline. Shared instance with logical isolation (one database, separate companies for each customer) reduces infrastructure costs but makes scaling harder and creates operational complexity around isolation enforcement. Shared database with custom isolation layer (true multi-tenancy, all customers in one company record with custom filtering) is the most economical and scalable but demands significant custom development and ongoing operational discipline.
Most established Business Central MSPs operate somewhere between the second and third model, typically starting with customer-dedicated and migrating to logical isolation as the customer base grows. The decision hinges on your customer profile. If you serve a small number of large enterprises, customer-dedicated is defensible. If you serve dozens or hundreds of small firms, the cost math favors shared infrastructure, but you must be willing to invest in isolation and multi-tenancy plumbing.
Data Isolation and Security Architecture
Once you commit to a shared instance, data isolation becomes your single largest technical and operational risk. A SQL query error, a batch job that doesn’t filter correctly, or a misconfigured permission can expose one customer’s data to another, which is a breach, a liability, and a loss of trust that no operational recovery can fully restore.
The first layer is at the database level. Even with logical separation (multiple companies), you are still operating within a single SQL database with a single set of users and roles. Business Central’s native security model (roles assigned to users, companies visible based on role membership) works for a single enterprise but is not designed to prevent a developer error from crossing company boundaries at the T-SQL level.
Practical isolation strategy: (1) All customer data must be tagged with a tenant ID, added to your core tables at the design stage, not retrofitted later. (2) Every report, batch job, form, and API call must filter on tenant ID at the table level before processing. This is not a UI-layer concern; it is a data-layer requirement. (3) Database permissions should be set so that application users and batch job service accounts have minimal direct SQL access. Most operations route through Business Central’s application layer and APIs, which give you a single enforcement point. (4) Audit and monitor large exports, bulk operations, and permission changes. (5) Separate test and production databases, and never allow production credentials to exist in test environments. (6) Document the isolation contract in your data model: which tables have a tenant ID column, which queries enforce it, which don’t (and why).
A common pattern is to add a TenantID integer to all major tables (Customers, Vendors, General Ledger Entries, Sales Orders), create a filtered view layer (SELECT * FROM Customers WHERE TenantID = @CurrentTenantID), and ensure all application code queries through views rather than directly against tables. This shifts isolation logic to a single place, making it easier to audit and less likely to be accidentally bypassed.
Database and Performance Scaling
When you share a database across many customers, performance becomes a shared-resource problem. One customer running a long-running batch job, generating a large report, or importing data can degrade responsiveness for all others if concurrency and resource contention are not managed.
Business Central sits on SQL Server, so conventional SQL scaling applies. For small deployments (under 20-30 concurrent users across all tenants), a standard SQL Server instance is adequate. Beyond that, you need active management. Index strategy matters more in multi-tenant contexts because a slow query now affects multiple customers simultaneously. Add a TenantID column to your major table indexes to ensure queries filtering by tenant are efficient. Monitor actual query plans and slow logs. Identify and tune the queries that run most frequently.
Connection pooling is critical. Each user session consumes a database connection. If you have 50 customers with 5 users each, that is 250 active connections under load. Business Central connection pooling can be configured via the Business Central configuration, but you should also run SQL Profiler periodically to verify connection reuse is actually happening and that idle connections are being recycled.
Workload isolation is the next tier. Business Central does not have native workload isolation (the ability to limit CPU or I/O consumed by one tenant’s queries). This means a misbehaving query from one customer can impact others. Some MSPs deploy a secondary read-only instance and route heavy reporting queries there, running the main instance for transactional work. Others implement query timeouts at the application layer, cancelling long-running operations before they escalate into broader performance problems.
For really high customer density, some MSPs partition data further, running multiple Business Central instances on different SQL databases, each managing a subset of customers, and routing traffic to the appropriate instance based on tenant ID. This increases operational complexity (monitoring, patching, deployment across multiple instances) but eliminates shared-resource contention. The right choice depends on your target customer density and the SLA you are committing to.
Operational Scaling and the Deployment Challenge
Multi-tenant architecture also changes how you deploy code. In customer-dedicated, you deploy customizations to each instance independently. In shared multi-tenant, you deploy once and all customers get the change. This is operationally cleaner but strategically riskier. A bug or incomplete feature benefits from being caught early and isolated to a small customer. Deploying to a shared instance means the bug affects everyone.
The mitigation strategy is staged deployment and extensive testing. (1) Maintain a canary instance that runs one real customer or a test customer. Deploy changes there first, run it for a period (days to weeks, depending on risk appetite), monitor, then promote to production. (2) Implement feature flags so you can deploy code without activating it for all tenants immediately. Roll out features to a subset of customers first, measure impact, then expand. (3) Develop a rapid rollback plan. If a deployment breaks, rolling back should take minutes, not hours. Keep a backup of the previous database state, have a tested restore process, and document it.
Operational Discipline and Monitoring
Multi-tenant architectures are only as strong as their operational discipline. Make tenant ID visible in monitoring and logs so you can isolate one customer’s database activity when they report slowness. Set up alerts on per-tenant CPU usage or transaction counts. Document your isolation assumptions, scaling limits (customers per instance, concurrent users), and escalation path. Communicate these limits to customers during onboarding so expectations are clear about when you may need to migrate a customer to a dedicated instance.
When to Re-Evaluate the Model
Multi-tenant architecture pays off when you have enough customers that the operational and infrastructure cost savings exceed the custom development and ongoing management burden. If you have fewer than 10 customers or expect to indefinitely, customer-dedicated is simpler. If you have 50 or more, multi-tenancy is almost certainly cheaper. The middle ground (10 to 50 customers) is where you need to actively decide, weighing your growth trajectory and engineering capacity.
The decision is also reversible. You can start customer-dedicated, measure actual growth, and migrate to multi-tenancy as customer density justifies the engineering investment. Many successful Business Central MSPs took this path, building the multi-tenancy layer only when economically justified.
Regardless of which architecture you choose, the foundation is the same: clear data isolation, disciplined code review, and monitoring that gives visibility into how each customer is using the system. These practices prevent the most common failure mode for SaaS businesses: one customer’s problem becoming everyone’s outage.
About Routeget Technologies: Routeget specializes in Business Central and Dynamics 365 implementation and managed services, working with MSPs to architect scalable SaaS solutions that operate reliably at customer densities of 50 to 500 tenants. Our architecture review and multi-tenancy design services help validate isolation assumptions and identify scaling bottlenecks before they impact customer experience.
#BusinessCentralSaaS #MultiTenantArchitecture #DataIsolation #CloudArchitecture #ManagedServices #BusinessCentral #Dynamics365 #SaaSArchitecture #DatabaseScaling #CloudComputing