The fundamental distinction: architecture and address
These two concepts are constantly mentioned together, but they are not the same kind of thing. The difference between them is the distinction on which this entire page rests.
Being web-based
Is an architectural decision.
It determines how the software is built. It lies in the deepest layer of the product and cannot be changed afterwards — except by rewriting from scratch.
You do not choose it; the vendor chose it years ago.
Being in the cloud
Is a deployment decision.
It determines where the server sits and who operates it. It lies at the surface and can be changed at any time.
You choose it; and you can change your mind.
Being web-based is architecture; the cloud is an address.
And the real link between them is this: if you choose the architecture correctly, you can change the address whenever you wish. If you choose it wrongly, changing the address becomes a separate project every time.
This is why we have divided the page into two parts. First we discuss the architecture — because that is what is irreversible. Then deployment — because that is where the real flexibility emerges.
What does web-based mean, and what does it not mean?
On the market, phrases like “web-based,” “web-accessible,” “runs in the browser,” and “remotely accessible” are used interchangeably. Yet behind them lie three separate generations, and in terms of user experience there is a chasm between them.
Client-server: the installed desktop application
The classic structure. The program is installed on every user’s computer. When a new version is released, the installation is repeated. Working remotely requires a VPN, and if the connection is weak the application becomes unusable.
Published desktop: remote desktop, terminal server, virtual desktop
This is where the most misconceptions arise. The desktop application is run on a terminal server, and the screen image is streamed to the user. Because the user can access it remotely, this is frequently called “web access.”
But the application is still a desktop application. Every concurrent user consumes a separate session and separate resources on the server. Scaling it is expensive; an additional terminal server license is needed for every user. On a weak connection the screen freezes, because what is transmitted is not data but an image. On tablets and phones the experience is impractical.
Browser-native: the truly web-based system
The application generates HTML; the browser displays it. Nothing is installed on the user’s computer. There is no plug-in, no runtime, no virtual machine. What is transmitted is not an image but data — which is why it works on weak connections too.
Minerva belongs to this generation. Screen and printer outputs are generated as HTML; the system runs through the browser.
The one-question test
When a vendor says “we are web-based,” the question to ask is: “What will be installed on the user’s computer?” If the answer is not “nothing” — a client, a plug-in, a runtime, an agent, anything at all — the system in front of you is not web-based; it is published over the web. Let the second question be: “Can someone using a Mac or a tablet log in to the system?”
The plug-in graveyard: the lesson of history
To understand why this distinction matters so much, it is enough to look at the last twenty years. For a period, the way to run rich applications in the browser was to use plug-ins. Hundreds of enterprise applications were built on these technologies.
Java Applet
Browser support removed
Applications built on it were rewritten
Adobe Flash
Completely discontinued at the end of 2020
Browsers refused to run it
Microsoft Silverlight
Support ended
Enterprise portals became unusable
ActiveX
Does not work in modern browsers
Survived only in legacy browsers
All of these technologies were considered “web-based” in their day. None of them survived. The only thing that survived was the browser’s own standards: HTML, CSS, and JavaScript.
This is the clearest example of why technology choice is an architectural decision. Applications built on a plug-in died along with that plug-in — regardless of the quality of the product.
Being built on standard browser technologies is not a fashion choice but longevity insurance. Whatever browser you use today, whatever device appears ten years from now, HTML will keep working. This is one of the most stable bets in the history of computing.
The concrete payoffs of being web-based
Instead of slogans, let us write down what changes in daily work.
Distribution cost drops to zero
In a system with an installed client, every release means as many installations as there are users. In an organization with four hundred users, this is an operation that must be planned and executed.
In a web-based system, the server is updated and the job is done. The user is on the new version at their next login and does not even notice.
Version fragmentation disappears
This is the most insidious problem of installed systems. Some users are not updated; some stay on the old version. Over time, “which version are you on?” becomes the first question of every support call. The same operation gives different results on different computers.
Because there is a single server version, everyone uses the same system. Support calls start with the problem, not with identifying the version.
Device and operating system independence
The design team may be using Macs, the field team may be carrying tablets, the manager may want to give approvals from their phone. In systems with installed clients, each of these is a separate problem, and usually goes unsolved.
Any device with a browser can log in to the system. When a new type of device appears, you do not wait for an adaptation from the vendor.
Old hardware lives on
In a web-based system, the heavy lifting is done on the server. The user’s computer has a single job: displaying HTML.
A five-year-old computer or a thin client is sufficient. When the software is renewed, there is no pressure to renew the hardware fleet.
Adding a new user or a new branch takes minutes
When you open a new branch, what is needed is an address and an authorization definition. The IT team does not need to go there and perform an installation.
Your pace of growth is not limited by your IT capacity. When you take on temporary staff at a new warehouse, that person starts working the same day.
Every record gets an address
This is a rarely discussed feature with a big impact. In a web-based system, every record has a link. When discussing an order, instead of telling your colleague “look at that order,” you can send the link to that record directly.
The link can be put in an e-mail, a message, a meeting note, or even a request record. Desktop applications have no equivalent of this; everyone searches for the record by hand.
Opening up beyond the wall
The above are important, but the most strategic consequence of being web-based deserves its own heading: you can include people outside your company in your system.
In a system with an installed client, this is practically impossible. You cannot install a program on your customer’s computer; you cannot ask your dealer to set up a VPN; you cannot buy a terminal server license for your subcontractor. This is why classic ERPs stay inside the wall.
In a web-based system, on the other hand, access restricted by authorization definitions is possible:
- Customers — order status, shipment tracking, account statements, outstanding balance, opening requests.
- Suppliers — open orders, delivery schedule, quality feedback, invoice status.
- Dealers and distributors — stock visibility, order entry, campaign information.
- Field teams — service records, closing work orders, material requests, location-based transactions.
- Subcontractors — the jobs assigned to them and delivery notifications.
- Financial advisors and auditors — read access within a limited scope.
This changes the nature of the system. It ceases to be an internal record-keeping system and turns into a business network. Instead of asking about their order status by phone, your customer looks it up themselves; every query stops being a phone call.
The prerequisite of this expansion is a robust authorization model. Every access opened to the outside requires who can see what to be defined precisely.
What does cloud mean, and what does it not mean?
“Cloud” is not a single thing but the answer to three independent questions: where does the server sit, who operates it, and how do you pay. Because these three get mixed up, the discussion usually starts from the wrong place.
| Deployment | Where the server is | Who operates it | Typical reason for choosing it |
|---|---|---|---|
| Your own server | On your own premises | Your own team | Existing investment, full control, regulatory obligation |
| Hosting | In a data center, dedicated to you | Service provider | Getting rid of the server room burden while retaining control |
| Private cloud | On cloud infrastructure, dedicated to you | Provider, or jointly | Flexibility plus isolation; control over data location |
| Public cloud | On shared cloud infrastructure | Provider | Lowest entry cost, fastest start, highest flexibility |
Three common misconceptions
- “Cloud means renting.” No. The deployment location and the payment model are separate matters. Working on your own server with a subscription, or in the cloud with a license, is technically possible. These are negotiated separately.
- “Cloud means the data is abroad.” No. The geographic location of the data center is a separate choice and is set out in the contract.
- “Cloud means backup.” Absolutely not, and this is the most dangerous misconception. A system being in the cloud does not mean your data is backed up. Backup and disaster recovery are separately defined services. If you do not see them in the contract, they do not exist.
The concrete payoffs of the cloud
The hardware renewal cycle disappears
If you run on your own server, server renewal comes up every four or five years. This is an item that must be planned and budgeted, is usually postponed, and whose risk grows the longer it is postponed.
In the cloud, this cycle is the provider’s problem. The infrastructure is renewed behind you; you do not need to make an investment decision.
Business continuity: the most underestimated benefit
Most mid-sized businesses have no real disaster recovery plan. The server room is usually in a corner of the building. Fire, flooding, theft, prolonged power outages, and ransomware — all of these can halt the business for days.
Ask yourself honestly: if your server became unusable tonight, at what time tomorrow morning could you enter an order?
In a professional data center, redundancy, geographic replication, and recovery times are defined by contract. This is a capability a mid-sized business cannot build on its own.
Capacity is adjusted to need
Most businesses have irregular loads: the start of the season, year-end inventory, campaign periods, month-end closing. On your own server, you buy capacity for the busiest day, and that capacity sits idle for the rest of the year.
In the cloud, capacity can be adjusted to need. Preparing for the busy period is not a purchasing process but a configuration change.
Geographic expansion becomes easier
When a new branch, a new country, or an acquired company is involved, the own-server model brings separate infrastructure and separate maintenance for each location.
In a centralized deployment, a new location is not new infrastructure but a new authorization definition. This is the prerequisite for the centralized business model described in the previous sections to work in practice.
The maintenance and update burden is handed over
Operating system patches, database updates, security fixes, and backup checks are tasks that demand constant effort. In a small IT team, these are usually the last things done — which means they usually do not get done.
In the cloud, these tasks are part of a defined service. Your team deals with the business’s own matters, not with infrastructure.
From capital expenditure to operating expense
Servers, storage, licenses, and installation are a large one-off investment and carry a depreciation burden. In the cloud, this becomes a predictable operating expense.
In terms of cash flow, the difference is significant; for a business in a growth phase in particular, not tying up capital in servers is a direct advantage.
The security paradox
The reservation most frequently voiced about moving to the cloud is security: “our data will be outside.” This reservation is understandable, but it usually rests on the wrong comparison.
The right comparison is not between the cloud and perfect security, but between the cloud and your own current situation. Ask yourself:
- Who can physically enter your server room?
- Where are your backups kept, and when was a restore last tested?
- How often are security patches applied?
- Would you notice an unauthorized access attempt on your system?
- In a ransomware attack, how many hours would it take you to get back up?
If you cannot give clear answers to most of these questions — and the majority of mid-sized businesses cannot — professionally operated infrastructure is more secure than your current situation. A data center’s security investment is not on a scale a single company can afford.
But this does not mean the cloud solves every risk
The cloud does not eliminate risks; it relocates them. Physical security and infrastructure risk decrease; in return, identity management, authorization, and access security become even more critical. Weak passwords and overly broad permissions are more dangerous in a cloud system than on your own server. Multi-factor authentication and regular permission reviews are not a preference but a necessity.
Where the two meet: freedom of deployment
Let us return to the distinction at the top of the page. Being web-based is architecture; the cloud is an address. When these two come together, what emerges is more than the sum of their individual benefits: the freedom to decide where you will run — and the freedom to change that decision later.
Moving a desktop application to the cloud
Because the application cannot run in the browser, a terminal server or virtual desktop layer is set up.
Additional licenses, additional server resources, additional complexity follow. The user experience usually deteriorates.
Result: you moved to the cloud, but it got more expensive and slower. Moving back is a separate project, too.
Deploying a web-based system
Nothing changes on the user side. The same browser, the same screens, the same habits.
The only thing that changes is the address. The user usually does not notice the move.
Result: you can start on your own server, then move to the cloud, and move back if necessary.
This flexibility is not theoretical; it is a commercial value. Because the conditions affecting the deployment decision change over time:
- Today you may have a newly purchased server; you want to amortize it.
- Three years from now, when that server needs renewing, moving to the cloud may make more sense.
- A regulatory change in your industry may require the data to be kept domestically.
- You may acquire a company abroad and need a centralized deployment.
The deployment that is right today may not be right five years from now. What matters is being able to change the decision when that time comes — and not having to retrain your users to do so.
The global picture: a debate already settled
The cloud-versus-own-server debate is now largely closed in the industry. The figures show this clearly.
- (cite index="12-1">As of 2025, approximately 70 percent of ERP installations are cloud-based; among new installations, the preference for the cloud stands at 78.6 percent and is rising.
- (cite index="13-1">Cloud ERP adoption rose from 44 percent in 2020 to 64 percent in 2024. Gartner puts the compound annual growth of the cloud segment at 17.4 percent and that of the on-premises side at 2.3 percent — roughly a seven-and-a-half-fold difference.
- (cite index="19-1">Small and mid-sized businesses are the fastest-growing segment of cloud ERP; annual growth of around 21 percent is projected through 2030.
- (cite index="12-1">Mainstream support for SAP’s on-premises ECC product ends in 2027, and this is expected to create a broad wave of migration to the cloud.
But it would be wrong to say “your own server is dead”
The same sources also state the limit of this: (cite index="10-1">on-premises installations continue to hold a share of roughly 30 percent in regulation-sensitive organizations. These are not a negligible minority; they are organizations with concrete reasons, such as banking, healthcare, defense, the public sector, and certain manufacturing fields.
The conclusion to be drawn from this picture is
the cloud is the right choice for most businesses, but it is not “right for everyone.” A vendor who tells you “the cloud is better in every case” is not advising, but selling. The right approach is to make the deployment decision together, according to your own circumstances.
The honest side: the price and limits of the cloud
A page that lists only the benefits inspires distrust in an experienced reader. Let us write down the costs as well.
Dependence on the internet
When the connection drops, you cannot access the system. This is a real risk and should not be ignored.
The counterpart: a redundant line, a second connection from a different operator, and a mobile fallback. These are reasonable costs for a mid-sized business today. And let us remind you: even if you run on your own server, the system still stops when your local network goes down. The difference is in the location of the risk, not in its existence.
Points that must run without interruption
A terminal on the production line, a barcode-scanning station in the warehouse, or a remote facility with a weak connection may not be able to tolerate even a few minutes of downtime.
These points require a hybrid design. Whether critical stations run with local buffering, or a local deployment is preferred at that facility, is evaluated during the project. Giving a single answer to every scenario would not be right.
Long-term total cost
The subscription model is markedly cheaper in the early years. Over a seven-to-ten-year window, however, the total payment can exceed an own-server investment.
We do not hide this. The value of the cloud does not always lie in absolute cost; it lies in the transfer of risk, in flexibility, and in not tying up capital. When making the comparison, hardware renewal, electricity, cooling, personnel, and downtime costs must also be taken into account — and usually they are not.
Exit and dependency
If you part ways with the cloud provider or the software vendor, what happens to your data?
Minerva runs on an Oracle database. Your data sits not in a closed format but in a standard, documented relational database. This is a concrete assurance in terms of portability, and it should be stated explicitly in the contract.
Latency in heavy batch operations
Very large data transfers or heavy batch operations can be slower when run over the network than when run locally.
In practice, the solution is to run these operations on the server side — rather than downloading data to the user’s computer and processing it there. Minerva already works this way; reports can be prepared in the background and the result delivered to the user.
Data location, KVKK, and cross-border transfer
For a business operating in Turkey, this is the most concrete legal dimension of moving to the cloud, and it is usually not discussed enough. Let us summarize briefly.
In 2024, Article 9 of the KVKK (Turkey’s Personal Data Protection Law), which governs transfers abroad, was amended, and (cite index="23-1">the Regulation on the Procedures and Principles Regarding the Transfer of Personal Data Abroad was published in the Official Gazette on July 10, 2024 and entered into force. Under the new framework, the appropriate safeguards that can be relied on for a transfer include (cite index="22-1">the standard contract announced by the Board, binding corporate rules to be signed by the companies of a group of undertakings and approved by the Board, and a written undertaking providing adequate protection together with the Board’s permission.
There are three points to watch out for in practice:
- There is no adequacy decision for any country. (cite index="22-1">Since the Law entered into force, no country has been the subject of an adequacy decision by the Board. In other words, you cannot rely on the justification that “that country is considered safe.”
- The standard contract is the most common route, but notification is mandatory. (cite index="25-1">The signed standard contract must be notified to the Authority within five business days; an administrative fine is prescribed for those who fail to fulfill the notification obligation. (cite index="20-1">In 2024, 1,345 standard contracts were notified to the Authority, and 3 undertakings were approved.
- The undertaking route is narrow in practice. The number of approved applications remains extremely low alongside the number of notified standard contracts.
Practical conclusion
The country in which your data will be kept is not a technical preference but a legal decision, and it must be written explicitly in the contract. When domestic deployment is preferred, a significant part of these obligations never arises at all. This is one of the most concrete benefits of Minerva’s deployment flexibility: you can choose the data location according to your needs.
This section is for general information purposes; you should evaluate your own situation together with your legal counsel.
Minerva deployment options
Because Minerva is web-based, it works in the same way in all four deployment options. The user experience, screens, training, and habits do not change. The choice is made on commercial and legal grounds, not technical ones.
| Your situation | Usually suitable option | Why |
|---|---|---|
| You recently invested in a server | Your own server | Amortizing the existing investment makes sense; you can migrate later |
| Your IT team is small or nonexistent | Cloud or hosting | The burden of infrastructure maintenance, backup, and security is handed over |
| Multi-location or international structure | Cloud | Centralized access; no separate infrastructure needed for each location |
| You are growing fast or opening branches frequently | Cloud | Capacity and the time to open a new location are reduced |
| Your industry is restricted on data location | Domestic cloud or your own server | Cross-border transfer obligations do not arise |
| You have remote facilities with weak connections | Hybrid design | A separate solution for critical stations; the rest centralized |
| You do not want to tie up capital in hardware | Cloud | Capital expenditure turns into operating expense |
No row in this table is a permanent verdict. Starting on your own server today and moving to the cloud three years later requires no change whatsoever on the user side in Minerva. This is the concrete thing the architectural choice earns you.
Eight questions to ask your vendor
Let this page not try to convince you; let it give you a yardstick. Ask these questions of every vendor you evaluate — including us — and request the answers in writing.
Questions for testing the web and cloud claim
Do not settle for general answers; every question has a concrete counterpart
- What will be installed on the user’s computer? A client, a plug-in, a runtime, an agent — is there anything at all?
- Can I log in to the system from a Mac or a tablet? Meaning the system itself, not a limited mobile app.
- Is an additional infrastructure license required to increase the number of concurrent users? If a terminal server or virtual desktop license is requested, the system is not browser-native.
- Can I give my customer or dealer limited access? Do I need to buy a separate portal product, or is it an authorization definition in the same system?
- If I move from my own server to the cloud, what changes for my users? If the answer is not “nothing,” the move is a project.
- In which country will my data be kept, and is this written in the contract? If abroad, which KVKK safeguard is used and who makes the notification?
- Are backup and disaster recovery included in the service? How often are backups taken, how long are they retained, and when was a restore last tested?
- If I stop working with you, in what form do I get my data? A standard database, or a closed export file?
The first and third questions alone distinguish the web-based claim. The fifth and eighth questions show whether you are being sold flexibility or dependency.
Summary comparison
| Topic | Installed desktop application | Application published via terminal | Minerva: browser-native |
|---|---|---|---|
| Client installation | On every computer | Client or plug-in required | None |
| Version management | As much work as there are users | Single on the server, separate on the client | A single server version |
| Operating system | Usually Windows only | Usually Windows only | Irrelevant |
| Tablet and phone | None | Impractical | Native |
| What is transmitted | Application data | Screen image | Only the data needed |
| Weak connection | Difficult over VPN | The screen freezes | Keeps working |
| Access for external users | Practically impossible | Expensive and risky | Possible with an authorization definition |
| Sharing a record link | None | None | Every record has an address |
| Moving to the cloud | Requires a rewrite | Requires additional licenses and layers | Only the address changes |
| Impact on the user side | Reinstallation and training | The experience deteriorates | No change at all |