Two quotations both say “managed hosting.” One includes application updates and recovery assistance. The other includes a virtual machine and a support address. Comparing the monthly prices tells you almost nothing about the difference.
Before you choose a provider, ask for a second page. It should explain what is managed, when help is available, and what the business must still do for itself.
Name the layers
A website can depend on a domain registrar, DNS, a hosting account, an operating system, an application, a database and an email provider. Different companies may look after different layers.
Write one responsible party beside each layer. Add a backup contact where appropriate. If a row says “the developer” or “the host,” replace that description with a specific role and contact process.
Pay special attention to renewal notices. An expired domain can make a well-maintained server irrelevant. Confirm where notices go and who is expected to act on them.
Separate an alert from a response
Monitoring means a problem can be detected. It does not necessarily mean somebody will investigate immediately. Ask what is checked, where the alert goes, and during which hours it is acted on.
Use an example: a contact form stops submitting while the homepage remains available. Would the agreed monitoring detect that? If not, decide whether that business action needs a check of its own.
Google's SRE guidance distinguishes the measurement of a service, the target set for it, and an agreement with consequences. Those distinctions are useful when reading hosting promises. Ask what is measured, over which period, and what happens if the target is missed. Service level objectives.
Ask for the recovery arrangement
Avoid accepting “daily backups” as a complete answer. Ask which data is covered, how long copies are retained, who can initiate a restore, and how recovery is tested. Establish whether the price includes the work of restoring the application as well as access to the backup.
Some changes need a maintenance window. Agree how it is proposed and approved, who tests afterward, and how a failed change is reversed. A record of changes helps the next person investigate a problem without guessing what happened yesterday.
Put the exclusions next to the inclusions
| Ask about | Get a concrete answer |
|---|---|
| Application updates | Which components, how often, and who checks compatibility? |
| Security incidents | Initial response, investigation scope, and additional costs |
| Content changes | Included edits versus separate development work |
| Support | Hours, contact route, severity definitions and escalation |
| Capacity | What triggers an upgrade and who authorizes the cost? |
| Third-party failures | Who communicates and coordinates when another supplier is involved? |
An exclusion is not automatically a reason to reject a quotation. It is a reason to assign the responsibility elsewhere. An unspoken exclusion is much harder to manage.
Check the exit before signing
Ask how you receive your data, application files and configuration if the relationship ends. Confirm whether the business controls its domain and important accounts. Record any notice periods, migration assistance and export costs in the agreement.
An export that cannot be used without an undocumented application is a limited escape route. Ask what form the export takes and whether a replacement supplier would have the information needed to use it.
Compare the same responsibility, not the same label
Take both quotations and fill in the same responsibility table. Highlight the blank cells. You may find that the cheaper option is perfectly suitable because your own team covers the rest. You may also discover that nobody has been assigned the most important job.
Make that comparison before buying. It is much easier to discuss support hours and restore responsibilities calmly than during an outage.
Have a version of this problem?
Let’s talk it through.