TL;DR
- At 50–200 employees you usually need someone else to run patching, backup and incident response — but you still own architecture and vendor choices.
- “Managed cloud” is not hosting with a logo swap: insist on SLAs, restore tests, security baselines and a named escalation path.
- Compare total cost: monthly fee + projects + egress + your internal time reviewing tickets.
- If a proposal cannot explain restore time, on-call coverage and who holds admin keys — keep shopping.
A manufacturing director called us last quarter with a familiar story. Revenue was growing, the ERP was creaking, and the IT manager — excellent at keeping the business running — was drowning in vendor tickets. “We need cloud,” the board said. “We can’t hire five DevOps engineers,” the IT manager replied. Both were right. Companies with 50 to 200 employees sit in an awkward middle: too big for “a one-person IT shop”, too small to fund a platform team that invents its own Kubernetes distributions on their own initiative.
Managed cloud is often the rational answer — but the label is worn thin. Every hoster, MSP and integrator claims it. This article is for owners, CFOs and operations leads who need to compare offers without becoming cloud architects overnight.
What changes at your size
Below fifty people, a generalist plus a good MSP can still cover servers, mail and backups. Above two hundred, you often justify dedicated infrastructure roles and formal change management. In the middle band, complexity arrives faster than headcount: hybrid work, more SaaS, customer portals, maybe a warehouse system or production data — while compliance questions (NIS2, customer audits, insurance questionnaires) start landing in your inbox.
You do not need a “digital transformation programme” with steering committees that meet about meetings. You need predictable operations: known monthly cost, backups that restore, security that survives a serious questionnaire, and a partner who answers the phone when something breaks on a Sunday.
Managed cloud vs hosting vs “we’ll figure out Azure”
Classic hosting gives you a VM or cabinet. You patch it, or you pay extra per ticket. Scaling and security architecture are mostly your problem.
DIY public cloud (you click in AWS/Azure/GCP) is flexible and can be cheap at small scale — until someone leaves the storage bucket public, nobody owns tagging policy, and three departments each spin up “temporary” environments that run for years.
Managed cloud, done properly, means a provider operates a defined scope: baseline hardening, monitoring, backup and restore, patch cycles, incident handling within SLA, and often a landing zone or reference architecture so new workloads do not start from a blank account. You still decide what runs there and what it costs commercially; they own how it stays up and defensible.
At QData we see the best fit when internal IT is strong on business applications (ERP, CRM, line-of-business) but thin on 24/7 infrastructure — exactly the profile of many companies.
Five questions every serious proposal should answer
1. What exactly is in scope? Patch management for OS only, or applications too? Database admin? Network firewall changes? List it. “Managed” without boundaries ends in disputes after the first outage.
2. What are the SLAs — and what happens when they break? Response time for severity-1, not just “best effort”. Credit mechanics matter less than honesty: if they cannot do true 24/7, say so and design escalation with your internal team.
3. When did you last restore a backup for a client like us? Not “we have backups”. A date, a duration, a signed test report. RPO/RTO in writing, tied to your tier-1 systems.
4. Who holds admin access? Break-glass accounts, MFA, PIM/JIT if cloud-native. You should own the tenant; they operate it with least privilege — not the other way round.
5. How do you charge when we grow? Per VM, per workload, per project? Egress and storage growth destroy flat “all inclusive” deals. Ask for a worked example at +30% capacity.
Red flags we see in RFP responses
Vague “cloud transformation” slides with no runbook. Unlimited support that somehow excludes databases, firewalls and “third-party software”. No mention of data residency or subprocessors when you handle EU customer data. Proposals that list tools (Kubernetes, Terraform, AI ops) without saying who operates them day two. And the classic: monthly fee so low that migration is free — because the margin is hidden in professional services you cannot avoid.
Another warning sign: they cannot explain what happens in the first 90 days. Good providers have onboarding: inventory, landing zone, backup proof, access review, then migrate workload by workload — not a big-bang weekend.
Compare total cost, not the cover page
Build a simple table. Columns: monthly managed fee, expected project days in year one, internal hours (your PM, app owners in testing), connectivity/egress, licences you still pay directly, and exit cost if you leave. A higher monthly fee with fewer project days and a clear scope often beats a cheap base rate that invoices every change request.
One logistics client saved money not by picking the lowest bid, but by choosing the offer that included restore drills and a single on-call path. Their previous “cheap” host had backups; nobody had tested restore in three years. That is not insurance — it is hope.
When managed cloud is not the first step
Sometimes the answer is boring on-prem hygiene first: AD cleanup, MFA on mail, offline backup, then migrate mail and file to SaaS, then lift a few workloads to managed cloud. If your ERP cannot tolerate downtime or your plant network is flat Layer-2 chaos, fix the riskiest items before marketing “we are in cloud”.
Equally, if you have no internal owner who can say “yes, this application may move” — pause. Managed cloud multiplies capability; it does not replace product owners.
A one-page checklist you can use Monday
- Named internal sponsor (not only IT).
- List of tier-1 systems with RPO/RTO expectations.
- Three vendor answers compared on scope, SLA, restore proof, admin model, growth pricing.
- 90-day plan: onboard, prove backup, migrate one non-critical workload, review.
- Exit clause understood (data export, DNS, keys).
What to do next
If you want a second opinion on proposals you already have — or a neutral scope document before you send an RFP — our Cloud Services team works from operations and architecture, not slideware. We help mid-market firms land managed environments they can actually run, audit and afford twelve months later.
Want to discuss a project?
Contact us
