NetSuite closed 2015 with roughly $741 million in revenue, up about a third year over year. For a company that had spent seventeen years arguing that ERP belonged in a browser, the number settled an argument that had been running since the late 1990s. Cloud ERP was not a small-business curiosity or a departmental workaround. It was a category with real scale, real mid-market adoption, and a growth rate the incumbent vendors could not match on their own installed bases. What made the milestone interesting was not the revenue itself — it was a fraction of what the established vendors booked — but what it proved about buyer behaviour. Companies were now willing to run the general ledger, the subsidiary consolidation and the order-to-cash process on infrastructure they did not own, operated by a vendor they could not audit in the traditional sense, with upgrades applied on the vendor's schedule rather than their own. A decade earlier, every one of those conditions had been described as unacceptable.
What the growth actually demonstrated
Three things, and the third is the one that mattered most commercially. The first is that the multi-tenant model worked for financials. Sceptics had argued that accounting was too varied, too regulated and too jurisdiction-specific to run on shared code. The counterargument — that most of the variation lives in configuration rather than in the fundamentals of double-entry bookkeeping — turned out to be largely correct for the mid-market. Where it was not correct, the gap was covered by a platform layer for customisation rather than by modifying the core. The second is that multi-subsidiary capability was the wedge into larger organisations. The ability to run several legal entities with different currencies, tax regimes and reporting calendars on one instance, with consolidation built in rather than assembled in spreadsheets, was the feature that turned a small-business product into a credible option for groups. That capability is also what made the two-tier pattern viable: heavyweight ERP at corporate headquarters, cloud ERP in the subsidiaries, consolidation upward. The third is that the economics of the model were still unproven. The company was growing rapidly and still not consistently profitable at that point, which is the standard subscription trade — acquisition cost paid upfront against revenue recognised over years. Buyers rarely examined this, and they should have, because vendor financial sustainability determines whether the product you are standardising on gets invested in, sold to a larger vendor, or wound down. The eventual acquisition by a much larger incumbent the following year answered the question for this particular vendor and raised a different one for its customers.
The trade every cloud ERP buyer makes
The genuine decision in a cloud ERP evaluation is not features. It is control, and the trade is specific. You give up upgrade timing. The vendor updates the platform on its cycle, and you test against it rather than deciding when to move. For most organisations this is a net gain — it eliminates the pattern of running five-year-old versions because upgrades are too disruptive — but it requires a permanent regression testing capability that on-premise buyers only needed episodically. You give up unrestricted modification. Customisation happens through a supported extension framework, and anything the framework does not permit is not available at any price. This is the constraint that most frustrates organisations coming from a heavily modified on-premise system, and it is also the reason their upgrades are now feasible. You give up infrastructure control, which means data location, access and continuity become contractual questions rather than engineering ones. What you get is a shorter implementation, a predictable cost profile, functionality that arrives without a project, and — crucially — an end to the accumulation of technical debt that makes on-premise estates progressively harder to change. The organisations that were disappointed by cloud ERP are overwhelmingly those that tried to reproduce their existing customised system in the new platform. The ones that succeeded changed their processes to match the software for everything that was not genuinely differentiating, and spent their customisation budget only on the parts that were.
Practical Guidance for Cloud ERP Evaluation
- Evaluate against your process requirements, not against a feature matrix. Run your five most complex real transactions through the demonstration environment. Feature checklists are answered "yes" by every vendor and tell you nothing.
- Test the multi-entity and consolidation model early if you have one. Intercompany, multi-currency, differing fiscal calendars and statutory reporting per jurisdiction are where mid-market cloud products are most likely to be thin.
- Assess the extension framework as carefully as the application. What you can customise, what you cannot, and what happens to your extensions at each upgrade. This determines your long-term flexibility.
- Cost the full term, not the first year. Subscription escalation, user tier changes, sandbox and integration charges, implementation partner fees, and the internal testing capability you will now need permanently.
- Examine the vendor's financial position and ownership. Growth-stage vendors get acquired, and acquisition changes roadmaps, pricing and support. Ask what happens to your contract on a change of control.
- Settle data extraction rights before signing. Full export in a usable format, on demand, at no additional cost. This is the clause that determines whether you have an exit.
- Confirm data residency and sub-processor locations in writing. Where the production data sits, where backups sit, where support staff access it from, and which regions are actually available.
- Choose the implementation partner with more care than the software. Product selection failures are recoverable; implementation failures are what produce the cost overruns and the abandoned projects.
The Regional Dimension
Cloud ERP adoption across the Gulf followed a different curve from Europe or North America, and the reasons still shape evaluations today. Localisation was the early blocker and remains the decisive test. A mid-market cloud product must handle UAE VAT, corporate tax, and — for Saudi operations — e-invoicing with clearance and reporting obligations on the regulator's technical specification and timetable. It must produce Arabic-language documents where required, handle bilingual master data, and support the payroll mechanics that regional employers actually run: wage protection file generation, end-of-service gratuity accrual and calculation, and social insurance contributions with nationalisation reporting for Saudi entities. Some of this is delivered natively, much of it comes through partner-built localisation modules, and the distinction matters enormously. A localisation owned by a local partner rather than by the vendor is a dependency on that partner's continued existence and on their pace of updating when a regulator changes a format. The question to ask directly: when the e-invoicing specification changes, who ships the update, how quickly, and is it included? Data residency was the second blocker and it has substantially eased. The arrival of UAE and Saudi cloud regions, plus sovereign-operator arrangements for the most sensitive workloads, removed the objection that blocked cloud ERP in government-adjacent, banking and healthcare buyers for years. It has not removed the need to verify: availability of a specific application in a specific region is a product decision, not a platform guarantee, and backups and support access frequently sit elsewhere. Structure favours the model. Regional groups are typically multi-entity by construction — mainland companies, free-zone entities, a Saudi subsidiary, sometimes an offshore holding company — each with its own licence, registration and reporting obligations. Consolidating those onto one instance with proper intercompany handling is exactly the problem cloud ERP multi-subsidiary capability was built for, and it is the strongest regional argument for the category. The common alternative — separate systems per entity with consolidation in spreadsheets — is still widespread and still the source of most month-end pain. Finally, the delivery market. Implementation capability across the region is concentrated in a partner ecosystem of variable quality, and the same partner frequently supplies the localisation, the implementation and the ongoing support. That concentration is a commercial risk worth managing explicitly: separate the implementation contract from the support contract where possible, insist on documentation and configuration ownership, and confirm that your data and customisations transfer if you change partner.
The objection worth taking seriously
The strongest criticism of the cloud ERP case is that it substituted one form of lock-in for another and marketed it as freedom. An on-premise system is unpleasant to upgrade and expensive to maintain, but the organisation holds the database, the licence is perpetual, and a vendor's pricing decision cannot switch the system off. A subscription product reverses all three. Pricing changes at renewal, and the leverage sits entirely with the vendor once the business runs on the platform. Contract terms, data location and roadmap are all subject to change, including change through acquisition, as the customers of this particular vendor discovered a year after the milestone in question. The upgrade argument also deserves scrutiny. Mandatory vendor-scheduled upgrades eliminate version stagnation and introduce a different burden: continuous regression testing, occasional forced behaviour changes, and a loss of control over timing that matters in regulated reporting periods. "You are always current" and "you are always testing" are the same statement. The balanced conclusion is that cloud ERP is the right default for mid-market organisations without genuinely unusual process requirements, and that the buyers who get hurt are the ones who treat the subscription as low-commitment. It is not. Once financial operations run on a platform, the switching cost is comparable to any on-premise migration, and possibly higher because you do not hold the database. Negotiate the exit terms, the data rights and the price escalation at signature, because that is the only moment you have leverage.
Common Questions
Is cloud ERP suitable for large enterprises?
Increasingly yes at the divisional and subsidiary level, and the two-tier pattern — heavyweight ERP at corporate, cloud ERP in operating units — remains the most common enterprise adoption route. Full replacement of a large, deeply customised core is a different proposition and is decided by the complexity of the processes rather than by the size of the company.
How should we compare total cost against our current system?
Over at least five years, including the internal costs each model imposes: infrastructure, database licences, upgrade projects and administration on one side; subscription escalation, permanent testing capability and integration charges on the other. Comparing an annual subscription against a maintenance line is the most common costing error in these evaluations.
What is the most common implementation failure?
Attempting to replicate the legacy system's customisations in the new platform. It produces a heavily modified cloud system with all the upgrade pain the move was meant to eliminate, at a higher price. The discipline is to change the process wherever it is not a source of competitive advantage.
How should AI capability factor into the evaluation?
Ask what runs on your data, where, and under what terms — not what is on the roadmap. The practical questions are whether AI features are included or separately priced, whether your transactional data is used to train anything, where inference is performed relative to your residency requirements, and what audit record exists when a system proposes or posts an entry. The more useful structural point is that cloud platforms accumulate clean, consistent transactional data in a way that heavily modified on-premise estates do not, which is why the same organisations that struggled to get value from analytics will struggle again. Data quality, not model access, is the constraint.
Cloud ERP Evaluation — the subscription looks like a low-commitment purchase right up to the moment your ledger runs on it, so negotiate the exit and the escalation before you sign.