Microsoft's enterprise software pitch in 2008 was not that Dynamics was more capable than SAP or Oracle. It was that your finance team already knew how to use it. That sounds like marketing, and partly it was. But it described a genuine strategic bet: that the cost of an ERP programme is dominated by change, training, customisation and consulting rather than by the software licence, and that a system which looked and behaved like Office would reduce all four. The bet was half right, and the half that was wrong is still costing buyers money today.
What Microsoft Was Actually Selling
Microsoft did not build its ERP business. It bought it — Great Plains in 2001, Navision the following year, and with them Solomon and Axapta. That produced four separate products with four separate code bases, four partner ecosystems, and four different answers to the question "which Dynamics should we buy?" The original plan was to converge them into a single next-generation product. That programme was rescoped and effectively abandoned, replaced with shared user experience and shared Microsoft technology across products that remained fundamentally distinct. By 2008 the branding said one family; the reality was a portfolio. For buyers this mattered enormously, because the choice between the mid-market product and the enterprise product was not a question of size. It was a question of which architecture you would be tied to for the next decade, and vendors on the channel side had strong incentives to recommend the one they sold.
The Market Was Never a Two-Horse Race
The most useful correction to the enterprise software conversation is that the giants have never owned the market. Panorama's long-running selection research has put SAP at around 22 percent and Oracle at 15 percent, with Microsoft near 10 percent — while second-tier vendors took roughly 16 percent and everyone else accounted for over a third of implementations. In other words, the majority of ERP projects run on systems that are never mentioned in the boardroom discussion. That has been consistently true for two decades, and it should inform how selection committees weight brand.
The Speed Claim, Tested
Microsoft's channel sold implementation speed relentlessly: faster to deploy, faster to value, less disruption. The independent data was more nuanced. Dynamics implementations did tend to run shorter than the tier-one average — and they also missed their deadlines at broadly comparable rates. That combination is the interesting finding, and it has an obvious explanation once you have run a few programmes. Schedule overrun is not primarily caused by software complexity. It is caused by decisions that do not get made, master data that turns out to be unusable, scope that expands during design workshops, and business stakeholders who are unavailable because they still have day jobs. A lighter product shortens the build. It does nothing about the three things that actually consume the calendar. So the honest version of the pitch is: a mid-market ERP will likely cost less and take less time than a tier-one implementation, and it will still overrun if you run it the way most organizations run these programmes.
The Channel Is the Product
The most important practical consequence of Microsoft's model is one that rarely appears in evaluation scorecards: you do not buy Dynamics from Microsoft. You buy it from a partner, and that partner — not the vendor — determines the outcome. The same product, implemented by two different partners, produces two completely different experiences. Partner quality varies more than product capability does, and partners carry their own vertical intellectual property, their own add-on modules, and their own consulting bench depth. This changes what diligence should look like. Most selection processes spend eighty percent of their effort on functional fit and twenty on the implementer. For channel-delivered ERP, that ratio should be close to inverted.
Choosing Well in This Segment
- Evaluate the partner harder than the product. Named references in your industry and country, the specific consultants who will be assigned, their utilisation on other projects, and turnover on their delivery team. Ask to speak to a client whose project went badly.
- Map the add-on stack explicitly. Mid-market ERP achieves functional coverage through third-party modules — for tax, payroll, warehousing, reporting, industry processes. For each one, establish who supports it, how quickly it certifies against new platform releases, and what happens if the publisher is acquired or discontinues it. Upgrade pain usually originates here, not in the core product.
- Test localisation before you test features. Statutory reporting, tax treatment, e-invoicing mandates, multi-currency handling, Arabic and bilingual document support, and local payroll and wage-protection requirements. For groups operating across the GCC and beyond, this is the sharpest differentiator in the mid-market and the one most often assumed rather than verified.
- Choose by process complexity, not revenue. The tiering language of the industry sorts buyers by company size. That is the wrong axis. A $200 million manufacturer with multi-plant planning and complex costing has heavier requirements than a $2 billion services firm with simple revenue recognition. Assess the complexity of what you actually do.
- Insist on the extension model. Customisation inside the core is what made older implementations impossible to upgrade. Modern platforms support extensions that survive updates — make it a contractual standard that all customisation follows that model, and require an inventory of every deviation.
- Own your configuration and data. Configuration documentation, integration specifications and data models should be deliverables in your possession, not artefacts in the partner's methodology folder.
- Model total cost over seven years. Licences or subscriptions, implementation, add-ons, integration, annual upgrade effort, and the internal team. Products that win on licence cost frequently lose on the other five lines.
Where This Ended Up
The lineage survived the strategy. Navision became Business Central; Axapta became the enterprise-tier Finance and Operations applications; the older mid-market products persisted far longer than anyone predicted, which tells you how sticky a working ERP is. The single-product convergence never happened, but the underlying bet — that familiarity, integration with productivity tools and channel delivery could win a third of the market — largely did. The buyer lesson from 2008 has not aged at all. The brand on the box is a small part of what determines success. The implementation partner, the add-on dependencies, the localisation coverage and your own decision-making discipline are most of it.
Common Questions
Is a mid-market ERP genuinely faster to implement?
On average, yes — shorter builds and lower cost. But research shows comparable rates of missed deadlines, because overruns are driven by decision delays, data quality and scope, not by the product's weight.
How should we choose between mid-market and tier-one ERP?
By process complexity and regulatory scope rather than revenue. Complex manufacturing, multi-entity statutory reporting and heavy compliance requirements justify a tier-one platform; many large but operationally simple businesses do not need one.
Why does the implementation partner matter so much?
Because channel-delivered ERP is configured, extended and supported by the partner. Outcomes vary more between partners implementing the same product than between competing products.
What is the main hidden cost in mid-market ERP?
Third-party add-on modules. They fill functional gaps at purchase and then govern your upgrade timeline, support model and total cost for the life of the system.
Dynamics Fit Assessment — Outpace evaluates ERP options against the complexity of your actual processes, scrutinises the implementation partner and add-on stack, and models seven-year total cost before you commit.