Cloud or On-Premise Hospital Software in India
Cloud based hospital management software or an on-premise server: what really happens when the internet drops, and what your own server actually costs.
Every Indian hospital loses its connection sometimes. That fact gets used to sell on-premise servers, and the argument sounds airtight until you look at what actually takes hospital systems down.
The short version:
- A cloud system needs a connection. Say so plainly and plan for it. Anyone who tells you otherwise is selling you something.
- A server in your building does not remove risk. It relocates it — onto your power supply, your hardware, your backups and one person who knows how it works.
- The cheapest real fix is a second internet line, not a server room. It costs a fraction of on-premise infrastructure and it protects everything else the hospital does online.
What actually takes a hospital system down
Ask around and the story is almost never “the data centre failed”. In Indian hospitals the recurring causes are:
- Power. The inverter covers the lights and misses the server rack, or the battery is four years old and holds twenty minutes instead of two hours.
- Hardware. A disk in a machine nobody has looked at since installation.
- The person. The one technician who set it up has left, changed jobs or is unreachable on a Sunday.
- Backups that were never tested. Backups running for three years and nobody has ever restored one. This is the most common serious failure, and it is silent until the day it is not.
- The link. Which is the one everybody worries about, and the one that is cheapest to fix.
Four of those five get worse when the server is in your building, not better. That is the part the on-premise argument leaves out.
The honest case for on-premise
There is one, and a vendor who pretends otherwise is not being straight with you.
- Your connection is genuinely poor and there is no second provider. In some locations this is simply true, and no amount of architecture argument changes it.
- A rule or a contract requires the data to sit in a named place. Some institutional and government arrangements do specify this. If yours does, that is the end of the discussion.
- You already run a competent IT function. If you have a server room, a maintenance contract and someone whose job this is, the marginal cost of one more system is small.
- Some machines only speak to a local network. Older laboratory and imaging equipment often expects to talk to something inside the building. This is usually solved with a small local bridge rather than by moving the whole system, but it is a real constraint.
If none of those apply to you, the on-premise case is usually nostalgia for a server you can see.
What “our software runs without the internet” actually means
Some products genuinely store data on the local machine and synchronise later. That is real engineering and it solves a real problem. It also brings its own: two copies of the truth that have to be reconciled, conflicts when the same record was edited in two places, and a synchronisation step that can fail quietly for days.
So when a vendor makes the claim, do not accept the headline. Ask:
- Which parts keep working without a connection, and which stop? Usually registration and billing continue and anything needing a shared resource does not.
- Where is the local copy stored, and what happens if that machine fails before it has synchronised?
- What happens to numbering? If two desks both issue receipts during an outage, how are the numbers kept from colliding?
- What does the staff member see when the connection returns and two versions disagree?
- Show me it. Ask them to pull the cable during the demo. It is a fair request and the reaction to it is informative on its own.
Arko Care is a cloud system and needs a connection. We would rather say that than sell you a capability and explain the asterisks later — which is the same test the demo questions apply to everyone else.
The three-year number, with nothing left out
On-premise quotes are usually compared against cloud subscriptions with half the on-premise costs missing. Put both on the same page for the same three years:
| On-premise, the full list | Cloud |
|---|---|
| Server hardware, and replacing it | Subscription |
| Operating system and database licences | Included |
| Power backup rated for the actual load | — |
| Air conditioning for the room | — |
| Someone to administer it | — |
| Annual maintenance on all of the above | Included |
| Backup storage, offsite | Usually included — ask |
| Upgrades, and the downtime to do them | Usually included — ask |
| Software licence | — |
The software licence is often the smaller half of an on-premise number. The rest is a building project.
What to do about the connection, whichever you pick
This is the practical part, and it matters more than the architecture debate.
Two links, two providers, automatic failover. A broadband line and a second line from a different company, with a router that switches between them by itself. One provider’s cable being cut does not then stop the hospital. This is the highest-value thing on the list and it is not expensive.
A mobile connection as the third fallback. A phone hotspot covers the desk for the length of most outages.
Power for the network, not only the computers. An inverter that runs the billing machine but not the router has not helped anybody. Put the modem, the router and the switch on backed-up power, and test it by pulling the mains for ten minutes on a quiet afternoon.
A written paper fallback, agreed in advance. One page: which register the desk writes in, what the patient is given, who enters it afterwards and by when. Print it and put it in the drawer. Most hospitals discover they need this during the outage.
Ask your vendor what they do at their end. Where is the data stored, in which country and region? How is your hospital’s data kept separate from every other hospital’s? How often is it backed up, and when did anyone last restore from one?
Arko Care’s own answers: Google Cloud in the Mumbai region, so data stays in India; patient, outpatient and billing records isolated per hospital at the database level; access enforced on the server by role; every change to a patient record recorded with who made it and when. The detail is on the security page.
Deciding
Cloud, unless one of the four on-premise cases above is genuinely yours. The reason is not fashion — it is that a cloud system moves four of the five real failure modes onto somebody whose full-time job is preventing them, and leaves you with the one you can fix cheaply.
If what you actually want is to stop running a server at all, that argument is made properly on why Arko Care. If you are still working out what the words mean, start with the terms. And whichever way you go, ask the data-exit questions in how to switch hospital management software before you sign — on-premise feels like ownership and is not the same thing as it.
Arko Care is an AI-native, white-label hospital management system for Indian hospitals, with no server for you to run. Book a demo and pull the cable on us.
Common questions
What happens to cloud hospital software when the internet drops?
The system becomes unreachable until the connection returns. Work in progress may be lost depending on how the software saves, and the desk falls back to paper for the duration. The honest questions to put to a vendor are how much of a half-finished bill survives, whether a receipt number is consumed by an interrupted transaction, and what the receptionist is told to do with the patient standing in front of her. A vendor who has no specific answer has not been in enough hospitals.
Is an on-premise server safer than the cloud for a hospital?
It is differently risky, not safer. A server in your building removes the dependence on an internet link and replaces it with dependence on your power supply, your hardware, your backups and one person who knows how it works. Most hospital outages in practice come from power, disk failure and nobody having tested a restore, not from a data centre going down.
Do I need two internet connections?
Two links from two different providers, with automatic failover, is the single most effective thing you can do for uptime — and a mobile connection as a third fallback covers most of what remains. It costs far less than a server room and it protects every online thing the hospital does, not only the software.
Is my hospital's data safe in the cloud, and where does it live?
Ask every vendor two specific questions: in which country and region the data is stored, and how each hospital's records are kept separate from every other hospital's. Arko Care stores data on Google Cloud in the Mumbai region, so it stays in India; patient, outpatient and billing records are isolated per hospital at the database level, access is enforced on the server by role, and every change to a patient record is recorded with who made it and when.
Which is cheaper, cloud or on-premise?
Compare the same three years on both sides and include what an on-premise quote usually leaves out: the server and its replacement, the operating system and database licences, a power backup that actually carries the load, air conditioning for the room, somebody to administer it, and the annual maintenance on all of it. The software licence is often the smaller half of the number.
Can we start on the cloud and move to our own server later?
Ask before you sign rather than assuming. Some products are built for both and some only run one way, and a vendor who offers both may be offering two different codebases with different features. Either way, the clause that protects you is the data-export clause, not the deployment promise.
