Cloud, Private Hosting or On-Premise: The UAE Version of the Question

There is a server in a cupboard behind the accounts office in Al Quoz. It has a UPS that was last tested when it was installed, a backup drive that somebody swaps when they remember, and it runs the system that decides whether the factory gets paid this month. Everyone knows this is not ideal. Nobody has changed it, because the alternative was presented as "moving to the cloud" and the discussion stopped at the price comparison.

At the other end of the argument is a company that did move, signed for a service described as regional, and found eighteen months later that the database sits in another country. Fine for them. Not fine for the healthcare distributor down the road.

The hosting decision gets argued as cost and settled as ideology. Four questions decide it, and only one is about money.

The three shapes, honestly described

The word "cloud" covers two arrangements that behave very differently, and lumping them together causes most of the confusion.

Vendor multi-tenant SaaS. You use software the vendor operates. You do not control the version, the patch schedule, the database or the infrastructure. Cheapest to run, least negotiable.

Single-tenant hosted, or private cloud. Your own instance of the application, on infrastructure operated by the vendor, a partner or a hyperscaler, usually with your own database and some control over when things change. A large share of mid-market ERP in the UAE sits here, described in proposals as simply "cloud", which hides the distinction that matters.

On-premise, or colocation. Your hardware or virtual machines, in your building or in space you rent, administered by you or by a firm you pay. Maximum control, and every obligation that comes with it.

Name which of the three you mean in an RFP, or bidders will price different things.

Question one: where the data has to live, and who says so

The UAE does not have one answer. It has a federal baseline, sector rules that override it, and two financial free zones with their own regimes. Getting this wrong is not a technical error; it is a licensing one.

The federal baseline is Federal Decree-Law No. 45 of 2021 on the Protection of Personal Data. It does not impose blanket localisation. It restricts cross-border transfer of personal data, permitting it where the destination provides adequate protection or where appropriate contractual safeguards are in place. The executive detail has taken time to settle, so verify the current position with counsel rather than relying on any summary — including this one.

The sector rules are where the hard constraints are. Health data is the clearest case: Federal Law No. 2 of 2019 concerning the use of information and communications technology in health fields restricts the storage and processing of health data outside the country, with defined exceptions introduced by Ministerial Resolution No. 51 of 2021. If you distribute medical devices or run any part of a clinical operation, that rule is not a preference and it is the first thing to establish, not the last — one reason medical device distribution tends to have a shorter hosting shortlist than its peers.

Financial institutions sit under the Central Bank's outsourcing framework, which among other things requires that the institution retains ownership of and unfettered access to its data, and that the regulator can reach the service provider, including on site. That last clause quietly eliminates any arrangement where you cannot say precisely which company holds the data and in which building.

DIFC and ADGM each operate their own data protection regimes with their own transfer mechanisms. If one of your entities is registered in either, its obligations are not the federal ones, and a group hosting decision made for the mainland entity may not cover it.

Then there is the constraint nobody legislates: your customers. Government and semi-government contracts in the Gulf increasingly carry residency clauses in the tender documents. A trading company that hosts wherever is cheapest can find itself unable to bid.

The test is short. For each category of data you hold — personal, health, financial, government-related — name the rule and name the country the data will sit in, the second answer coming from the vendor in writing with the region specified. Not "the Middle East". The region.

That distinction is not pedantry. The major hyperscalers have arrived in the country at different times and with different footprints: Microsoft opened Azure regions in Dubai and Abu Dhabi in 2019, AWS opened its Middle East (UAE) region in August 2022, and Oracle has operated a Dubai region since 2020. Google's nearest region is in Dammam, in Saudi Arabia — which is why Odoo's announcement in April 2024 that its MENA cloud customers would be hosted from Dammam was regional news rather than local news. For most UAE companies that is entirely acceptable. For a healthcare business it is not, and the difference is a border.

Question two: latency where the work happens

Head office does not notice latency. The factory floor does, the site cabin does, and the warehouse at four in the morning does.

The mechanism is round trips. A user filling in a form and pressing save makes one round trip and cannot tell you whether it took 30 milliseconds or 200. A storekeeper scanning goods receipts makes a round trip per scan, sometimes several — the lookup, the validation, the write, the label print. Multiply a two-hundred-millisecond penalty by ten round trips per line and forty lines per delivery and you have added minutes to a task that is measured against a truck waiting outside.

The second mechanism is the link itself. Round trips within the Gulf are typically in the low tens of milliseconds; to Western Europe they typically sit above a hundred. Those are good-day averages, and a good day is not what breaks operations. What breaks operations is the site with one mobile connection, the warehouse where coverage dies behind the racking, and the fibre cut that takes out an industrial area for six hours.

So the honest question is not what the latency is. It is what happens when the link is gone.

Ask every bidder to demonstrate it. What does the scanning application do offline — queue, or refuse? Can a delivery note be printed if the connection drops mid-shift? Can the production line record output and reconcile later, or does it stop? Does the point-of-sale keep trading? Answers differ enormously between products and are almost never in a proposal, and a company running plastics manufacturing with continuous shifts has a different tolerance here than a professional services firm whose worst outage costs an afternoon of timesheets.

Then measure. Put a stopwatch on your highest-volume transaction, from the location where it is performed, on that network, at that time of day. An afternoon of this settles arguments that otherwise run for weeks.

Question three: who is accountable when it is down

This reveals the real difference between the three shapes, and it is almost never asked in the form that produces a useful answer. The useful form is not "is it reliable". It is: on the 28th of the month, when the invoice run fails at nine in the evening, whose phone rings, what have they contractually promised, and what happens if they do not answer.

Responsibility	Multi-tenant SaaS	Single-tenant hosted	On-premise
Hardware and facility	Vendor	Hosting provider	You
Operating system and database patching	Vendor	Depends entirely on the contract — check this line	You
Application version and patches	Vendor, on their calendar	Negotiated, usually with a window	You, when you choose
Backups taken	Vendor	Usually the host	You
Backups proven by restore	Nobody, unless you ask	Nobody, unless you ask	Nobody, unless you insist
Disaster recovery, with a stated recovery point and recovery time	Published, read it	Contracted, or absent	Yours to build and fund
Security monitoring and incident response	Vendor	Split, and the split is where incidents live	You
Regulator or auditor access to the environment	Via the vendor's certifications	Contract clause required	Direct
The 9pm call on the 28th	A support queue	A named account team, if you bought it	Somebody you employ

Two rows in that table decide more than the rest combined.

The first is the restore test. A backup that has never been restored is a belief, not a control. Put a restore rehearsal in the annual calendar with a named owner and a written result — the date, the elapsed time, what was found. It is the cheapest piece of IT governance available and it is skipped almost everywhere.

The second is the split-responsibility row. In single-tenant hosting, the gap between "the host looks after infrastructure" and "the partner looks after the application" is where outages become long: everything works and nothing is anyone's problem. Insist on one contractual throat to hold, even if that party subcontracts.

Question four: what five years actually costs

The cost comparison people run is capital expenditure against subscription, and it is the least interesting version of the calculation.

On-premise carries hardware with a refresh cycle, typically in the four-to-five-year band, which puts the second hardware purchase inside a five-year model rather than outside it. It carries a second site, or at least a second copy, for disaster recovery — the line most often deleted to make the comparison look better. It carries power, cooling and floor space. Above all it carries an administrator: someone who patches, monitors, restores and is reachable at nine in the evening on the 28th. In a mid-market UAE company that is rarely a full role, so it becomes somebody's second job and is done to the standard of one.

Subscription carries none of those and instead carries a compounding annual figure, priced per user, that grows with your user count and with the uplift. Over five years that compounding is larger than most models allow for — the arithmetic set out in the total cost of ownership question.

Four lines decide the comparison and are usually missing from it. Development and test environments, which are trivially cheap in a hosted model and a capital line on your own hardware — which is why companies that host their own frequently end up with one environment and test in production. Capacity, which flexes in one model and in the other is bought for the peak and idles the rest of the year. Your administrator, loaded honestly: salary, cover during leave, and the cost of the knowledge leaving with them. And the disaster recovery arrangement you would actually be willing to describe to the board.

Run five years with those four lines in it and the answer is far less obvious than either camp claims.

The real dividing line: upgrade cadence

If you strip away everything else, the decision comes down to who controls when the software changes.

On multi-tenant SaaS, the vendor decides. You get the change on their calendar, whether or not this month is your audit. The advantage is real and underrated: you are never four versions behind, the security posture is current, and there is no upgrade project to fund. The cost is that a change you did not ask for lands in a week you cannot absorb it, and any behaviour you depend on that was not contractually promised can move.

On-premise and most single-tenant arrangements, you decide. You can hold a version through your peak season, test properly, and move when the business can take it. The cost is that "when the business can take it" has a way of becoming never. Deferred upgrades compound into a version gap, and a version gap eventually becomes a re-implementation wearing a different name. That is the trap examined in why the next version might be the biggest mistake, and the deployment model is what decides whether you can fall into it at all.

There is a governance answer better than either extreme. Whichever model you choose, keep a register of every customisation and integration from week one, with its owner and what it depends on. In a hosted model it tells you whether the vendor's next release is a risk. On your own infrastructure it tells you whether an upgrade is a fortnight or a project. Without it, both models degrade to the same thing: hoping.

The exit question, which is the one to settle first

Whatever you sign, you will one day want to leave — for a better product, because the vendor is acquired, or because a partner relationship ends badly. Exit terms cost nothing to agree at contract stage and are impossible to obtain at the moment you need them, which is the one moment your counterparty has no reason to help.

Require four things in writing.

A full export in a documented, non-proprietary format — transactional data, master data, attachments and audit trail. Attachments are the line most often missing, and a decade of signed delivery notes living only inside a system you are leaving is a compliance problem as well as an operational one.

A stated timeframe and a stated cost for producing it. "On request" with no timeframe is not a term.

A transition period during which you retain read access after the subscription ends, so that you can answer an audit question about a period you can no longer transact in.

And a test, performed during the implementation rather than at the exit. Ask for the export in month three, open it, and see whether a competent person could reconstruct your ledger from it. That fifteen-minute exercise is worth more than any assurance in a contract, and it is also the honest answer to a related question — how you survive an FTA audit with the records you actually hold.

Where each model tends to land

None of this produces a universal answer, but the shapes are reasonably stable.

Your situation	What usually fits	The trap at this shape
Single entity, office-based work, no factory floor, standard processes	Multi-tenant SaaS	Assuming the vendor's residency is your residency without checking the region
Manufacturing or distribution with scanning, several sites, moderate customisation	Single-tenant hosted, in-country, with a named accountable party	Split responsibility between host and partner, discovered during an outage
Health data, financial institution, or contracts with residency clauses	In-country hosting with the region named in the contract, sometimes on-premise	Choosing on price and discovering the constraint after the licence is signed
Remote sites with unreliable connectivity	Whatever survives the link being gone — test this before anything else	A demonstration on head-office wifi
Strong internal IT with genuine 24-hour cover and a funded disaster recovery site	On-premise remains defensible	Deferring upgrades until the version gap becomes a re-implementation
No internal IT, and the server is in a cupboard	Almost anything else	Treating the cupboard as free because nobody invoices for it

The last row deserves the last word. On-premise is not cheaper because nobody sends you a bill for it. It is a set of obligations you have taken on and may not be discharging, and the cost shows up all at once, on the day the drive fails and somebody discovers the backup has been silently failing since March.

If you want the hosting question answered against your own sector rules, sites and connectivity rather than as a general argument, that assessment is part of an independent read of the systems you already run.