Two hosting offers offer similar storage space and the same number of mailboxes. Nevertheless, they can differ significantly in everyday life. One website loads slowly under load while the other remains stable. A backup is available, but you can only restore it yourself at additional cost or not at all. The crucial difference is often not in the first price line.

Companies should view hosting as an operational service. This includes resources, responsibilities, protective measures and a resilient path back after a disruption. The right environment depends on the application, data and consequences of failure. A small public appearance has different requirements than a customer portal through which business transactions are processed on a daily basis.

Shared hosting: shared basis

With shared hosting, several customers share a technical platform. The provider usually manages essential server components. For many smaller websites this can be economical and sufficient. The decisive factors are the actually available resources and the limits of the offering, for example for processes, databases or background tasks.

Not every limitation is a disadvantage. A standardized environment can simplify operations as long as it fits the application. It becomes problematic when a website requires special extensions, permanent processes or special configurations. Such requirements should be checked with a small technical proof before the contract is concluded, instead of only being noticed during the productive move.

VPS: more freedom, more responsibility

A virtual server provides a isolated virtual environment. Companies can often configure the operating system and services there in a more targeted manner. This opens up possibilities for individual applications, but also means additional tasks. Updates, monitoring, backup and recovery do not disappear with the deployment of a virtual machine.

In addition, the guaranteed performance must be understood. Virtual resources can be reserved or shared in different ways. A memory number does not explain disk performance or platform availability. For a business-critical application, measurable requirements and a realistic test are more important than the mere name VPS.

Managed hosting is a scope of services

Managed hosting means that a provider takes over certain operational tasks. What these are must be specifically described in the offer. Operating system maintenance, web server maintenance, monitoring and backup are possible. The maintenance of an individual application or its plugins is not automatically included.

Ask about the boundary between infrastructure and application. Who responds to a full database and who responds to an error after a CMS update? Are malfunctions only reported or also corrected? A comprehensible responsibility matrix prevents several parties involved from referring to each other in an emergency. The term managed alone does not answer these questions.

Dedicated servers and their limitations

A dedicated server provides physical resources for a customer. This can be useful for special performance or insulation requirements. However, a single device is still a potential point of failure. Hardware exclusivity is not synonymous with high availability or a suitable backup strategy.

Here too, tasks arise for operation and replacement. What happens if there is a disk defect? How quickly is hardware deployed? Is reconstruction documented? For some applications, a smaller, well-maintained environment is a better choice than a large server with no clear responsibilities. The architecture must match the actual consequences of an interruption.

Measure backups against restores

The question is not just whether to secure, but what and how consistently. A dynamic website usually requires database, uploaded files and configuration. If these parts are captured at different times, a recovery can produce conflicting states. The scope of security must match the application.

Important planning variables are the tolerable data loss and the tolerable recovery time. They are often referred to as RPO and RTO. In the worst case scenario, a daily backup can leave many hours of new data missing. An existing backup is also of little use if there is no practice in restoring it or if the same compromised credentials allow access to all copies.

Storage and separate filing

Backups require defined rotation and appropriate access protection. An additional copy in the same directory does not protect against all relevant failures. Depending on the risk, separate accounts, other storage locations or copies protected against subsequent changes may make sense. Which combination is suitable depends on the protection requirement and the restart concept.

Performance is more than bandwidth

Perceived speed depends on application, database, disks, caching and network. A large nominal connection does not compensate for slow database queries. Likewise, a powerful server cannot speed up an overloaded website at will. Measurements should therefore take typical processes and realistic load into account.

For example, registration, document search and download can be relevant for a portal. For a shop, the shopping cart and order completion are added. These operations are tested with representative data and without sensitive production information. In addition, it should be monitored whether background tasks affect public use. A single quick page view is not yet reliable proof of capacity.

Organize security and access

Company access, application administration and customer access should be treated separately. Not every editorial person needs server rights. Technical accounts need regulated responsibilities and appropriate protection. Updates and security notifications must be integrated into a recurring process.

The location is also only part of the data protection consideration. The service providers involved, access options, contracts and actual data flows are crucial. A server in Germany, for example, does not say anything about where an additional email or analysis service processes data. The specific processing should be documented in a comprehensible manner, without deriving a blanket promise of conformity from a country specification.

Evaluate support in the event of a malfunction

A contactable telephone number is helpful, but the service must match the needs. Which response times apply, for which severity levels and at what times? A confirmed message does not mean that the problem has been resolved. For important applications, an escalation path should be established.

The comprehensibility of communication can also be tested. Can the provider explain what backups exist and how a restart takes place? Are any changes announced? Are there comprehensible protocols and contact persons? Transparent answers are often more valuable to companies than a long list of technical-sounding features.

Use the move as a small recovery test

A change in hosting provides an opportunity to document actual operational needs. This includes PHP or runtime environment, database, extensions, background tasks and writable directories. Not every dependency is in the source code. A locally set up cron job or a server-specific redirect can be just as important for the process.

Before switching, the application should be tested in the target environment with a consistent copy. Test forms must not trigger any productive notifications and background tasks must not start any real external processes. Appropriate separation and deliberately disabled integrations are part of the preparation.

After the change, the certificate, domain assignment, file rights and important functions are checked. A successful call to the homepage is not enough. Login, document access, and writing operations may have different technical requirements. Error messages and logs must also be accessible and appropriately protected at the new location.

The old environment only remains available for a defined transition. New data must not be created uncontrolled in two places at the same time. If DNS caches or external systems still use old targets, a coordinated procedure is required. Only when data flow and operation are clear will the old infrastructure be decommissioned in a controlled manner.

Check an offer in a structured manner

  • Record application requirements and permissible consequences of failure.
  • Compare resources, constraints and operational responsibilities.
  • Clarify backup scope, restore duration and testing procedures.
  • Have security, data protection and support services specifically described.
  • Plan a technically supported move with a return route.

GRITTMANN can look at hosting and application operations in context. The goal is an environment that fits the website or individual software and whose limitations are understandable. It is also worth taking a look at for new applications Containers and Docker, whereby security and responsibilities must also be explicitly planned there.

Sources and further documentation

Technical basics and additional information from the respective editors. Links last checked on 21.07.2026.