Gartner expects more than 70% of recently implemented ERP initiatives to fall short of their original business goals by 2027 (Gartner, “What IT Leaders Must Do to Avoid Disappointing ERP Initiatives,” analyst Denis Torii). The product is rarely the reason. ERP scalability gets decided when you choose the platform and the customization model — years before anyone in the business feels the strain. Six architectural decisions determine whether your system absorbs a doubling of volume, a new legal entity, or a new country. Each one is cheap to make at the start and expensive to reverse in year three.

Business Central online has hard quantitative limits, and Microsoft documents them openly. A single environment holds a maximum of 300 companies. One environment’s database holds up to 3 TB of compressed data, including keys, indexes, and BLOB content.

Storage capacity works on separate arithmetic: 80 GB per tenant by default, plus an allowance per licensed user — 3 GB for Premium, 2 GB for Essential, 1 GB for Device. That pool is shared across every environment in the tenant. Going over it doesn’t interrupt transaction processing in existing environments, but it does block creating new environments and copying existing ones until you free space or buy more capacity.

For a single-entity company, these numbers look unreachable. For a distribution group adding three to five legal entities a year and opening a market, the company limit becomes a landscape-design question before the first data migration. Finance & Operations was built on a different model — legal entities inside one application, with financial dimensions running across all of them. Choosing between the two products means choosing a load profile for the next five years, not comparing feature lists. Our detailed breakdown sits in Business Central or Finance & Operations?

The most expensive modifications aren’t the ones that cost most to build. They’re the ones built against the platform’s extensibility model.

In Finance & Operations that choice is gone. Overlayering Microsoft code isn’t supported; from version 8.0 every application model is hard-sealed, and overlayered code produces compilation errors. Extensions are the only supported mechanism. In Business Central, modifications live as per-tenant extensions or AppSource apps, and Microsoft places responsibility for keeping that code aligned with the product’s release rhythm squarely on the publishing partner.

FastTrack guidance states the consequence without softening it: many performance issues trace back to custom code or configuration that wasn’t optimized or properly tested. Every modification that routes around the extension model is a deferred invoice. It comes due not on release day, but on the day the business asks for a new country, a new sales channel, or a new warehouse — and the ERP implementation team answers that the old customizations have to be untangled first.

Microsoft sets the update rhythm for Finance & Operations, not the project team. Customers can take up to four service updates per year, a minimum of two are required, and pauses apply to one update at a time. Two of the annual updates are major releases tied to the spring and autumn release waves; the others carry mostly platform and regulatory changes. Updates maintain backward compatibility, so there’s no code to merge.

For each update, Microsoft offers two autoupdate windows four weeks apart — and the gap between them is your validation budget. The arithmetic follows. Custom code volume converts directly into regression-testing volume, and that testing happens several times a year rather than once every three. An architecture carrying 200 hours of modifications and one carrying 2,000 hours demo equally well, then diverge sharply on three-year cost of ownership.

“How much do we customize?” belongs in the same sentence as “who regression-tests it every quarter, and with what?”

The classic symptom of outgrowing an architecture is master planning that doesn’t finish before morning. Microsoft solved this by relocating the load rather than adding capacity: master planning calculation runs outside Supply Chain Management and its SQL database. The built-in master planning engine has been deprecated.

The consequence for planners is concrete. Planning runs are no longer tied to a nightly batch window — they can run during office hours, and planners can react to demand changes the same day.

The remaining bottlenecks stay on the design side, and Microsoft’s guidance is equally direct there: shorter transactions reduce lock escalation and increase user concurrency; as data volumes grow, the system needs tuning to hold the same response times. That second point rewards a second reading. Response time doesn’t hold itself — somebody holds it, and that work belongs in the operating model from day one, not from the first wave of user complaints.

Every process written into the ERP core raises the cost of the next update. The question isn’t whether to automate a new process, but which layer it belongs in.

Dual-write provides tightly coupled, near-real-time, bidirectional integration between finance and operations apps and Dataverse: a change in F&O writes to Dataverse, and a change in Dataverse writes back. That opens a separate development surface — processes that once had to be built inside the ERP can be built on Power Platform over the same data.

FastTrack states the principle briefly: use the right tool for the job. A product applied outside its intended profile creates performance problems regardless of code quality.

Expanding into a new country breaks an architecture when local requirements get their own system, or their own fork of the configuration.

Microsoft doesn’t ship localization for every market. Where it doesn’t, partners build localizations as apps on top of the international (W1) version of the product. The model is layered, and that matters: local requirements live separately from the core and separately from customer-specific customization. Each layer follows its own update cycle.

OntargIT’s Ukrainian localization is built exactly this way — base Dynamics 365 functionality, then Microsoft’s Eastern Europe localization pack, then the Ukraine package, and only then customer customization on top. The same discipline applies to any market where a partner layer is required.

None of the six decisions above is technically hard to make. What’s hard is undoing them. A company that picked its platform for today’s load profile, built modifications around the extension model, and pushed new processes into the core instead of Dataverse gets the bill later — when a new legal entity or a new market arrives. Check your current architecture against these six points. If two of the answers are unclear, start with an ERP audit rather than a new project.