Who this is forIT directors, procurement leads and business owners who are deciding what to hand to a hosting or managed infrastructure supplier, what to keep in house, and how to question a supplier and a contract before signing, including how the relationship ends.
“Managed” is not one thing. It describes a boundary, and the boundary is drawn differently by every supplier and every contract. Two proposals that both say “managed servers” can differ by whether anyone patches the operating system, whether anyone watches the backup jobs, and whether anyone will answer the phone at three in the morning. This guide gives you a way to draw that line yourself, the questions that surface the difference, how to read an availability promise without being misled by it, and how to plan the exit that nobody wants to discuss at the start.
Draw the boundary layer by layer
Take the stack from the building up and ask, for every layer, who owns it, who performs the work, and who is accountable when it fails. Put the answers in a table and have the supplier fill in their column.
| Layer | What the question really is | You | Supplier |
|---|---|---|---|
| Facility: power, cooling, physical security | Who runs it, and what do you get to inspect? | ||
| Network: connectivity, firewalling, DDoS handling | Who owns each device, and who changes the rules? | ||
| Hardware: servers, storage, replacement of failed parts | Who holds spares, and who authorises a swap? | ||
| Virtualisation or platform layer | Who patches, upgrades and monitors it? | ||
| Operating system: patching, hardening, access | Who has administrative access, and who applies updates? | ||
| Application and database | Who is on call when it breaks? | ||
| Backup and recovery | Who runs it, where are copies held, who tests restores? | ||
| Identity and access | Whose directory, and who can remove an account? | ||
| Security monitoring and incident response | Who watches, and who decides to isolate a system? |
The two failure patterns are visible straight away. A layer with no owner is a gap, usually found during an incident. A layer with two owners is a conflict, usually found when each side assumed the other had patched it. The table makes both obvious before the contract is signed.
Questions that separate suppliers
Ask in writing, and keep the answers with the contract. A good supplier answers precisely and sometimes says “that is not included”. Treat vagueness as an answer. The questions below ask for processes and facts; none of them presumes a particular answer is right, and you should compare answers between suppliers rather than looking for a perfect score.
Facility and network
- In which physical locations will my systems and my backups be held, and can that change without my agreement?
- Who operates the facility, and is it theirs or a third party’s? What independent assurance reports exist, and can I read them?
- What is the power and network design, in terms of the number of independent feeds and carriers, and what has actually failed in the past two years?
- What protection exists against volumetric attacks, and who decides when to apply it?
Hardware and platform
- If a part fails, what is the replacement process, who starts it, and what is the committed response, stated in the contract and not a brochure?
- Is the hardware dedicated to me, or shared? If shared, how is isolation enforced and verified?
- Who patches the platform layer, on what calendar, and how do I learn about maintenance that affects me?
Support and operations
- What is covered by the support commitment, at what hours, through which channels, and what happens when a ticket is not answered in time?
- Who will have administrative access to my systems, how is that access controlled and logged, and can I see the log?
- How do you handle changes: who approves, how is a change communicated, and how is a bad change reversed?
Security and data
- How is my data separated from other customers’, and encrypted at rest and in transit? Who holds the keys?
- What is your incident notification commitment, in time and in content?
- Which subcontractors touch my systems or data, and which can you change without telling me?
- What happens to my data and my backups on termination, and how is deletion evidenced?
Commercial and exit
- Which charges are fixed and which are variable? What does it cost to add capacity, remove it, or leave early?
- What is the minimum term, and how does renewal and price change work?
- In what format, and how quickly, can I extract my data and configuration, and have you done it for another customer?
A supplier that cannot answer these precisely is not necessarily a bad one, but you have learned that you would be doing the finding out yourself, later, under pressure.
Reading an availability promise
An availability percentage is a statement about measured downtime over a period, and the arithmetic is simple. A 30-day month has 43,200 minutes.
| Availability | Allowed downtime in a 30-day month |
|---|---|
| 99% | 432 minutes, which is 7.2 hours |
| 99.9% | 43.2 minutes |
| 99.95% | 21.6 minutes |
| 99.99% | 4.32 minutes |
| 99.999% | about 26 seconds |
The percentage tells you less than four other details do.
- What is measured. Availability of the network port, of the virtual machine, or of your application? A server that is powered but whose database is down may still count as available.
- What is excluded. Scheduled maintenance, customer-caused faults, third-party failures and events outside the supplier’s control are commonly excluded. Read the exclusions as carefully as the percentage.
- What the remedy is. Service credits are commonly the only remedy, and they are capped. A credit against next month’s bill does not compensate for lost business, and the contract may say it is your sole remedy.
- Who measures, and how you claim. If the supplier measures and you must apply within a fixed window, check that the process is realistic.
A high availability figure on a single server is a statement about the supplier’s service, not about your application. If your design has a single point of failure inside it, the percentage on the contract does not remove it. Resilience is an architecture question first, and backup, high availability and disaster recovery explains why.
What to keep in house
Even with a fully managed service, some things are cheaper and safer to hold yourself.
- Domain names and DNS control. Registered in your own account, so moving suppliers does not depend on theirs.
- Backups you can reach independently. At least one copy stored under your control, separate from the supplier’s credentials.
- Encryption keys and secrets, where the service allows it.
- An up-to-date inventory and architecture record, so you are never wholly reliant on the supplier’s documentation.
- Someone accountable internally who can read the contract and challenge a report. Outsourcing the work does not outsource the responsibility.
Exit planning: do it before you sign
Every relationship ends, and the date is rarely your choice. Plan the exit when you have maximum leverage, which is before you commit.
- Data and format. Ask for a description of the export, in formats you can use without the supplier’s software, and, where practical, test it on a sample at the start.
- Time. Work out how long extraction takes, using your own figures. For example, 20 TB over a 1 Gbit/s link at 70% usable is 20,000 x 8,000 / 700 = 228,571 seconds, a little over 63 hours, before verification and with the link used for nothing else. That is the minimum time your data is at risk during an orderly exit. Server migration covers the method.
- Notice and overlap. Check how much notice you need, whether you can run in parallel with the new platform, and what it costs.
- Dependencies on proprietary features. Anything that only exists on the supplier’s platform has to be rebuilt, not moved. List it now.
- Deletion. Ask for written confirmation that your data and backups have been deleted after exit, and what evidence will be provided.
- Rehearsal. The only way to know an exit works is to have done a small version of it. A restore of a representative workload into somewhere else is a useful proxy.
Trade-off accepted. Insisting on an easy exit can cost something, whether in price, in the use of platform features that speed delivery, or in time. It is a judgement about how much optionality is worth. Make it deliberately, and record it, because the absence of an exit plan is also a decision, just one that is usually made by default.
How this goes wrong
- Assumed coverage. The contract said managed, and nobody patched the application layer, because that was never in scope.
- A percentage mistaken for protection. The supplier met its availability figure on its own measurement, and the business still lost a day of trading.
- The only copy was the supplier’s. The backups were in the same account as production, and both were affected by one incident.
- A key person left. The documentation lived in one person’s head at the supplier, and in nobody’s at the buyer.
- Locked in by a feature. A convenient proprietary service became the thing that made leaving cost more than staying.
- Exit never rehearsed. The first attempt to extract the data discovered a format nobody could read.
What to do next
Fill in the layer table for your current arrangement, or for the proposal on your desk, and notice which cells are blank. Use the architecture comparison matrix to judge which operating model matches your requirements, and the migration readiness planner to estimate what leaving, or arriving, would involve.