Will Your ERP Still Fit When You Double in Size?

What ERP Scalability Actually Means

ERP scalability is a system's ability to accommodate growth — in users, transactions, data volume, entities, or business processes — without performance degradation or fundamental rearchitecture. Vendor marketing uses the word loosely, so it helps to break it into three distinct layers that scale independently.

Technical scalability is infrastructure elasticity: more CPU, RAM, or app-server instances behind a load balancer. Functional scalability is the ability to add new modules, entities, or legal structures through configuration rather than a rebuild. Operational scalability covers workflows, governance, and reporting — can you onboard a new subsidiary, a new currency, or a new warehouse without a project every time.

SMEs typically outgrow an entry-level tool like QuickBooks or Xero on complexity rather than raw size. QuickBooks Online Advanced caps at 25 billable users per company, and Intuit's own Enterprise documentation notes that list-based performance degradation becomes likely as you approach the platform's roughly one-million-name and one-million-item list thresholds — not a fixed megabyte ceiling. Multi-entity consolidation in those tools requires separate subscriptions or files with no native intercompany eliminations or real-time consolidated reporting. Those are the signals that 'scalability' has stopped being abstract and started costing you hours.

• →Technical scalability — vertical (scale-up: add CPU/RAM to one instance) and horizontal (scale-out: add more instances behind a load balancer). ERP databases tend to scale vertically; application tiers scale horizontally.
• →Functional scalability — add modules, companies, or entities through configuration, not reimplementation.
• →Operational scalability — workflows, approvals, multi-company governance, and consolidated reporting that survive adding subsidiaries, currencies, or locations.

How Microsoft Dynamics 365 Scales

Microsoft positions Business Central as the business management solution for small and mid-sized organizations, with Finance plus Supply Chain Management (F&O / F&SCM) as the enterprise tier above it. Critically, there is no published numeric threshold that forces an upgrade from Business Central to F&O — larger organizations typically scale Business Central by adding environments rather than migrating.

Business Central online has no fixed operational limit on the total number of users. Microsoft's service-scalability telemetry states the average customer runs 20–30 full users, that thousands of customers have more than 100 users, and that some run well over 1,000 — with 105% year-over-year growth in the >100-user customer segment in 2023. Real per-environment throughput examples from the same telemetry page include 5,000 sales invoices posted in one hour, 52,500 sales invoices posted in a single day (2.6 million item lines), 256,000 general journal lines posted in one day, and 10 million web service calls in a single day peaking at one million per hour. Microsoft is explicit that these are sample measurements, not published upper bounds or service limits.

Capacity is governed, not unlimited. The hard ceiling most SMEs hit first is 300 companies per environment — organizations needing more distribute companies across multiple production environments, a common pattern for branch or country rollouts. Tenant storage starts at an 80 GB base plus per-license allowances (2 GB Essentials, 3 GB Premium, 1 GB Device, 5 GB Partner Sandbox), with a 3 TB per-environment compressed data cap. Exceeding tenant quota blocks new environments and copies but does not interrupt live transactions. On the API side, per-user limits rolled out starting late December 2023 cap OData at 5 concurrent requests and 6,000 requests per 5-minute sliding window, with a roughly 100-connection ceiling, an 8-minute operation timeout, and a 350 MB max payload.

For multi-site and international growth, Business Central supports a hub-and-spoke model via Company Hub, intercompany postings, and financial consolidation from multiple companies — even mixed systems — with 40+ localized country/region versions available as extensions. Dynamics 365 Finance adds 'Consolidate online' (rolling daily balances into a consolidation company), Financial reporting with drill-down and multi-currency hierarchies, and elimination rules processed during consolidation or via proposals. The move from BC to F&O is a functional-fit assessment, not a limit-driven trigger.

• →No fixed user cap — real customers run 1,000+ users on Business Central online (Microsoft telemetry sample).
• →300 companies per environment — distribute across environments to grow beyond it.
• →80 GB base tenant storage + per-license add-ons; 3 TB per-environment data cap.
• →Per-user API limits: 5 concurrent OData requests, 6,000 per 5-minute window, ~100 connections, 350 MB max payload.

How Odoo Scales Across Three Tiers

Odoo runs the same Enterprise core across three deployment tiers, and choosing the right tier is the single biggest scalability decision an Odoo customer makes. Each tier has a different ceiling and a different set of constraints.

Odoo Online is the managed SaaS entry tier. Per-database storage is capped at 100 GB under Odoo's documented storage limits, external API access (JSON/XML-RPC) is restricted to the Custom plan, and custom modules or non-standard Odoo Apps Store apps are not allowed. It is the fastest path to live but the least flexible at scale. Odoo.sh is the PaaS tier for Custom-plan users who need custom modules, community apps, or Apps Store apps: GitHub integration, dev/staging/production branches, SSH access, automated CI testing on every commit, database replication, backups, and email gateways. Odoo.sh storage caps at 512 GB on shared hosting and 4 TB on dedicated hosting. On-premise is the self-hosted tier with no Odoo-imposed storage caps — scaling is bounded only by your hardware, PostgreSQL tuning, and architecture choices.

Worker scaling follows a documented rule of thumb across all self-managed tiers: roughly one worker per six concurrent users, with a production worker count of (number of CPUs × 2) + 1. On-premise, multi-process mode plus Redis for caching and sessions, an nginx reverse proxy, and optional load-balanced multi-server or Kubernetes deployments push capacity much higher — Odoo is largely stateless at the web and application layer. The important caveat: adding workers does not automatically fix slow code. Scaling the application tier without addressing inefficient queries or custom modules just spreads the problem across more processes.

Functionally, Odoo supports multi-company configurations under one database with selective data sharing — partners and products can be shared while financials, warehouses, and taxes stay separated — and authorized users can access multiple companies simultaneously. Odoo supports 167 currencies with automatic conversion and exchange-difference entries, which matters for international SMEs.

• →Odoo Online (SaaS) — 100 GB database cap, no custom modules, external API only on Custom plan.
• →Odoo.sh (PaaS) — Git-based dev, CI, worker scaling; shared hosting 512 GB / dedicated hosting 4 TB.
• →On-premise — no Odoo-imposed storage caps; multi-process + Redis + nginx + optional load balancing.

Triggers That Signal You Have Outgrown Your Tier

Recognizing the trigger early is the difference between a planned migration and a panicked one. The signals differ by platform, but they cluster around the same themes: customization needs, integration pressure, storage growth, and multi-entity complexity.

On Odoo Online, the trigger to move to Odoo.sh or on-premise is well documented: you need custom modules or third-party Apps Store apps (forbidden on Online), you are pushing past the 100 GB database cap, you have heavy external API or third-party integrations, you need Odoo Studio combined with multi-company, or you want Git-based dev workflows with staging. Any one of these points to Odoo.sh at minimum. A critical migration constraint to plan for: Odoo Online's intermediary versions (for example 19.x where x is not zero) are not supported on Odoo.sh or on-premise — you must first upgrade to the next major version (x.0), waiting for its release if necessary.

On Dynamics 365, the trigger is rarely a hard limit. It is functional depth. When your supply chain, manufacturing, or global regulatory complexity exceeds what Business Central's multi-environment model can practically manage, an assessment with an implementation partner will point you toward Finance and Supply Chain Management. The decision is partner- and assessment-driven, not limit-driven, which is why early planning matters more than hitting a threshold.

On entry-level tools — QuickBooks, Xero — the triggers are blunter: user seat caps, list-size slowdowns, manual multi-entity workarounds, and the absence of native intercompany eliminations or real-time consolidated reporting. If finance is spending a week every month consolidating spreadsheets across entities, you have already passed the trigger point.

Planning for Scalability Before You Need It

Scalability is cheapest when you design for it on day one and most expensive when you retrofit it under pressure. The SMEs that scale cleanly share a few planning habits regardless of platform.

First, model your entity structure up front. Whether you end up with three Business Central environments for three countries, an Odoo multi-company setup with shared partners and separated financials, or a consolidated Finance instance, the decision drives licensing, integration, and reporting architecture. Second, instrument early. Per-user API limits, worker counts, and storage consumption are all observable before they become incidents — telemetry should drive capacity decisions, not gut feel.

Third, treat customization as a scaling decision. On Odoo Online, a single custom module forces a tier migration. On Business Central, extensions and per-environment company distribution let you grow without re-platforming. On both, keeping the core clean and pushing complexity into well-isolated extensions preserves your ability to upgrade. Fourth, build a refresh cadence into your ERP governance: capacity reviews every quarter, a documented migration trigger list, and a relationship with an implementation partner who can run an assessment before you hit a wall.

Finally, understand the difference between vertical and horizontal scaling for your specific workload. ERP databases scale more easily vertically; application tiers scale horizontally. Cloud ERPs like Business Central apply both automatically on Azure; self-managed Odoo deployments require you to make the call deliberately. A partner-led architecture review is the single highest-leverage planning step an SME can take — it surfaces the ceilings you have not hit yet and the ones you are about to.

1. 01
   Model your entity and growth structure

   Map subsidiaries, countries, and legal entities before you configure. This drives environment count, licensing, and consolidation architecture on both D365 and Odoo.

2. 02
   Instrument capacity from day one

   Track storage, API usage, worker load, and transaction volumes. Telemetry should trigger capacity decisions before users feel slowdowns.

3. 03
   Keep the core clean

   Isolate customization in extensions or custom modules. On Odoo, any custom code forces a tier choice; on BC, clean extensions preserve upgradeability.

4. 04
   Run quarterly capacity and trigger reviews

   Maintain a documented list of migration triggers per platform. Review against actual usage each quarter with your implementation partner.

5. 05
   Get a partner-led architecture assessment

   An experienced implementation partner surfaces ceilings you have not hit and recommends whether to scale in-tier or plan a tier migration.