When a Business Central environment has grown for years, it is common to end up with dozens of small extensions, each one built to solve the problem in front of you at the time. That is exactly where our client found itself: 45 individual extensions, built up over several years, covering everything from AR collection tracking to real-time sync with their own customer-facing platform.
Why extension sprawl happens
Nobody sets out to build 40-plus extensions. It happens one requirement at a time: a new field here, a workflow tweak there, each one small, focused and correct on its own. The problem is cumulative. By the time we reviewed this client’s environment, the Purchase Line table alone was being extended by nine separate packages — understanding the full data model for a single table meant opening nine different projects.
Every extension also carries its own version, publisher and release cycle, so co-ordinating upgrades across 40-plus moving parts gets riskier with each one added. And as Business Central itself evolves release to release, verifying compatibility gets harder the more extensions there are to check.
What was already working
It’s worth saying clearly: this client’s extensions already delivered real value. A fully automated commission approval and settlement workflow replaced a manual chain of approvals. Real-time sync kept customer and vendor records current on their own web platform. Role centre cues gave management same-day visibility into open orders, purchase order ship dates and AR collections. The goal of a consolidation isn’t to undo any of that — it’s to keep it while making the platform underneath it easier to maintain.
Mapping a path to about 8 packages
Our proposed architecture replaces the 42 client-owned extensions with a shared Data Layer — one package holding every custom table and table extension, with no pages, logic or reports of its own — plus one focused extension per functional area: Sales, Purchase, Inventory/Items & Warehouse, and Role Centre. Each of those depends on the Data Layer, so when a new field is needed anywhere in the system, only the Data Layer changes, and every consuming extension sees it automatically.
Two third-party integrations stay exactly as they are, outside this dependency, since they’re maintained and published by other vendors rather than owned in-house.
| Proposed Package | Replaces | Extensions Saved |
|---|---|---|
| Data Layer | Field definitions pulled from every current client-owned extension | Shared foundation |
| Sales Package | ~14 current extensions (orders, AR, commissions, customer master) | ~13 |
| Purchase Package | ~11 current extensions (POs, AP, vendor master) | ~10 |
| Inventory, Items & Warehouse Package | ~8 current extensions (items, pricing, bins, archives) | ~7 |
| Role Centre Package | ~6 current extensions (cues, KPIs, navigation) | ~5 |
| Unchanged (third-party) | Stays as-is, reviewed separately | 0 |
The net effect: roughly 42 extensions collapse to about 8 packages, eliminating around 35. No data migration is required — every field ID stays exactly as it is in the live database, so this is a structural and packaging exercise, not a rebuild.
What this means for businesses with growing extension lists
- One place to see every custom field on a given table, instead of nine
- Fewer moving parts to version, test and deploy
- A clearer line of ownership between the teams responsible for sales, purchasing, inventory and reporting
- Safer, easier upgrades as Business Central itself keeps evolving
Ready to audit your own extensions?
If your Business Central environment has grown the same way — one extension at a time, over several years — it might be time for the same kind of review. We’ll help you see the full picture before you decide what to simplify.
