Our position

Cloud is not a matter of belief

Forcing the cloud and refusing it share one mistake: both settle the question before anyone has looked at the application.

Our position

We decide cloud or on-premise per application, not per company — and the first question is always what happens when the line goes down.

Cloud or your own server — which one is right?

As long as the question is answered for an entire company, it is the wrong question. An order-processing system, a shared file store, a machine controller on the shop floor and a mailbox differ in who needs access from where, how much data moves, and how much downtime a working day can absorb — so they have different right answers. NDVDL walks through the applications one at a time and asks the same three things about each: who needs access, from where, and what the business does if the internet line is gone for half a working day. Only then does it become clear what belongs outside the building, what stays in it, and where the two have to meet. Deciding the matter in advance saves that work, and the saving shows up later as an operational problem nobody connects back to the decision.

01

One company does not have one requirement

A business rarely runs a single application. There is the system the order flow depends on. There is the store where drawings, quotes and contracts live. There may be a controller in production whose only job is to keep running. These differ in almost everything that matters to the decision: where people work from, how much data moves, how fast a fault has to be answered, how badly a standstill hurts.

A decision made in principle assigns all of these the same answer before any of them has been looked at. Sometimes that fits. More often one application ends up in a place that does not suit it, and the consequences surface later as day-to-day friction that nobody traces back to the original choice.

02

The line becomes part of the installation

The moment an application runs outside the building, the connection to it is part of the application. That is not an argument against the cloud; it is an item that belongs in the plan. You need to know which applications can sit out an outage and which cannot — and whether the second group has a second route to the network, or a way to keep working without one for a while.

The same holds in reverse for your own server room. Things fail there too; the difference is that you carry them yourself — power, cooling, hardware, restoring from backup. The honest question is not which option never fails, but which failures the business can absorb and who is fixing them while it waits.

03

Data control mostly means being able to leave

Day to day, data control is less about location than about mobility. Who holds administrative access. In what format do you get your data back if you want it back. How much work is a move, and was one ever anticipated. These are questions to settle before moving in, not on the way out.

For some data there are operational or contractual reasons to keep it in the building. Whether such reasons apply to you is a question for your legal advisers, not for us. Our job is to build the technical side so that the decision you make stays workable — and can still be reversed later without starting from nothing.

The case for picking one side and staying there

There is more to be said for a single, company-wide commitment than we would like. A business that works consistently outside its own walls, or consistently inside them, has one kind of login, one kind of backup, one kind of fault report — and after a short while everyone knows where to look without anyone explaining the architecture. Mixed setups produce interfaces instead, and interfaces are exactly where responsibility goes missing: when the link between two systems stalls, each side can point at the other with good reasons, and the business is left between two explanations that may both be true. Committing once and sticking to it avoids buying that grey area at all — a real advantage rather than a failure of nerve, and in a small company with no dedicated IT staff it often outweighs the technically better-fitting split.

What this means in practice

  • We work through your applications one by one before quoting, instead of offering a standard architecture — which takes longer and makes our proposals harder to compare, because each one looks different.
  • Where a mixed setup is the answer, we name the interfaces and put in writing beforehand who is responsible for which kind of fault and who you call first.
  • We do not build something we can simply reuse at the next client — what fits you gets re-examined elsewhere, and that effort is ours to carry.

Does that sound like your situation?

Then let us talk about what it concretely means for your business.

Server room
Follow-ups

What we get asked about this

Neither, not by itself. In both cases security comes from the same things: accounts issued carefully, two-factor sign-in, systems kept current, backups that have actually been tested, and someone who looks regularly. A neglected server in a basement and a carelessly configured cloud tenant are both exposed, just in different ways.

Usually not. Existing hardware is normally there for good reasons and often has service life left. We look at what runs on it and move only what gains something identifiable from moving. The rest stays where it is and is looked after properly.

Yes, they are. Every link between two systems is one more thing that can fail and has to be maintained. So we propose a mixed setup only where there is a concrete reason for it — and when we do, the question of who is responsible goes into the same document as the technical design.

With a list. Which applications exist, who works with them, from where, and how long each one could stand still before it hurts. That list takes only a few conversations to produce, and it answers most of the cloud question on its own.

Better to talk before the decision than after it

We will go through your applications with you and tell you where each one belongs in our view — including when the answer is that everything can stay exactly where it is.

Request a first consultation+43 800 007075