Shared vs managed hosting: budgeting for small organisation websites
Shared hosting describes how server resources are shared; managed hosting describes how much operational work the provider takes on. Compare the scope, labour, recovery risk and migration costs—not just the monthly price.
Start with the right comparison: shared and managed are not exact opposites
Shared hosting and managed hosting answer different questions. Shared hosting describes how infrastructure resources are allocated: many websites use the same server and share resources such as CPU, memory and storage. Managed hosting describes how much operational work the provider performs for you. A managed service can still use shared infrastructure, and a shared hosting provider can still manage the physical server and operating system.
This matters for budgeting because the cheapest-looking plan can be expensive if your team must spend time on updates, restores and troubleshooting. The reverse is also true: a more expensive managed plan is poor value if you pay for services you do not need. AWS's web-hosting overview defines shared hosting by shared server resources, while the UK's National Cyber Security Centre (NCSC) explains that responsibility shifts between customer and provider depending on the service model in its shared-responsibility guidance.
What the hosting labels do—and do not—tell you
| Label | What it usually tells you | What you still need to verify |
|---|---|---|
| Shared hosting | Your site shares underlying server resources with other customers. | Resource limits, isolation, backup policy, support, application updates, security features and performance controls. |
| Managed hosting | The provider takes responsibility for some operational tasks. | Exactly which tasks: server patches, CMS updates, plugin/theme updates, backups, restores, monitoring, malware response, performance tuning and migrations can all have different boundaries. |
| VPS or cloud hosting | You normally receive a more isolated or configurable compute environment than basic shared hosting. | Whether the service is self-managed or managed, how scaling works, and which infrastructure and application tasks remain yours. |
The useful question is therefore not “shared or managed?” in isolation. Ask: what am I buying, what work disappears from my team, and what risks still remain with us?
Diagnose the website before comparing plans
Start with the business impact of the site, not with a host's feature grid. A five-page brochure site that changes twice a year has a different risk profile from a membership site, an ecommerce store or a campaign site that receives sudden traffic spikes.
- Business criticality: If the site is unavailable for two hours, do you lose sales, leads, bookings or only convenience?
- Change frequency: How often are the CMS, plugins, themes, integrations or application code changed?
- Internal capability: Who can restore a backup, diagnose a server error or recover from a failed update when the usual developer is unavailable?
- Traffic pattern: Is demand steady, seasonal or driven by campaigns, launches or press coverage?
- Recovery expectation: How much data could you afford to lose, and how quickly would the site need to be restored?
- Support window: Do you need help only during working hours, or could a weekend outage materially affect the organisation?
- Portability: Can you export the site, database, DNS records and backups without depending on a proprietary workflow?
If these questions expose a gap in ownership, treat that gap as a cost. A low monthly hosting fee does not remove the need for someone to be responsible for the website.
Map the responsibility boundary before you price the plan
“Managed” is only useful when the contract or service documentation says what is managed. Before comparing prices, create a simple responsibility sheet for each candidate provider.
| Task | Questions to answer |
|---|---|
| Backups and restores | How often are backups taken? How long are they kept? Are they stored independently? Who performs a restore, and is restoring included in the plan? |
| Security updates | Who patches the server and runtime? Who updates the CMS, plugins, themes or application dependencies? What remains your responsibility? |
| Monitoring and incidents | Does the provider monitor availability or only the infrastructure? Who responds to malware, compromised accounts or application errors? |
| Performance | What resource limits apply? Are caching or a content delivery network included? What happens when CPU, memory, visits, workers or bandwidth exceed the plan? |
| Support | Which channels are available, at what hours, with what response targets, and does support cover your application or only the hosting platform? |
| Migration and exit | Is migration included? Can you export a complete copy? Are there cancellation, transfer or emergency-migration charges? |
The NCSC's guidance on choosing a managed service provider recommends making roles, responsibilities, service levels, incident handling, backup and disaster-recovery arrangements explicit. Hosting contracts vary, so treat the provider's documented scope as the source of truth.
Calculate total cost instead of comparing subscription prices
A useful hosting budget separates predictable operating cost from risk. Start with costs you can measure:
- hosting subscription at the normal renewal price, not only an introductory offer;
- taxes and billing-period effects where relevant;
- backup, security, CDN, staging, email or support add-ons;
- premium CMS extensions or licences required by the hosting setup;
- agency, freelancer or internal staff time spent on maintenance and incidents;
- planned migration or platform-change work, spread over the period you expect to use the service.
If you want a compact model, use:
predictable monthly cost = hosting + add-ons + maintenance services + (internal hours × loaded hourly cost) + amortised migration cost
Then keep incident exposure visible as a separate decision factor: emergency developer work, recovery time, lost transactions or enquiries, and staff time during an outage. Do not pretend you can predict those costs precisely if you do not have reliable incident data.
For example, suppose a hypothetical shared plan costs £15 per month and requires two hours of website administration at an internal cost of £45 per hour. Its predictable operating cost is £105 per month. If a hypothetical managed plan costs £65 and reduces that work to 30 minutes, the comparable figure is £87.50. The numbers are illustrative, not market prices; the point is to price labour alongside the subscription.
Also check the surrounding stack. Domains, DNS, email, certificates, monitoring, premium plugins and backup services may be bundled with one provider but separate with another. The ScanMySEO guide to hidden infrastructure subscriptions can help you identify those adjacent costs without double-counting them.
Treat backups as a recovery capability, not a checkbox
A plan that says “daily backups” still leaves important questions unanswered: retention period, storage location, restore access, database coverage and who performs recovery. The NCSC's current small-organisation guidance says organisations should back up important data, know how to restore it and check that the backup contains what they need. See its backup and restore guidance.
For budgeting, assign a cost to recovery ownership. If your host provides backup files but your team still has to rebuild the site, reconnect services and validate the result, the service is less managed than the phrase “managed backups” might suggest.
Performance and SEO do not depend on the hosting label
Do not buy managed hosting because of a vague promise that it will “improve SEO”. A hosting label is not a Google ranking guarantee. What matters operationally is whether the site stays available and responds fast enough under real load, alongside the many other factors that affect page experience and search visibility.
Time to First Byte (TTFB) is a useful diagnostic measure of how quickly a server begins responding, but it is not a score for choosing between hosting categories. A slow CMS query, uncached page, overloaded account or distant origin can all affect response time.
Google's guidance on changing hosting without changing URLs focuses on keeping the new infrastructure accessible and avoiding serious slowdowns. It also notes that Googlebot's crawl rate can dip temporarily after a hosting move before increasing again. That is a migration consideration, not evidence that one commercial hosting label inherently ranks better than another.
Budget for the move—and for the exit
A cheaper plan can become expensive if moving to it requires unplanned technical work. Before switching, include the one-off cost of:
- creating and testing a complete backup;
- copying the site and database to the new environment;
- recreating DNS, email-routing, certificates, scheduled tasks and environment settings where needed;
- testing forms, payments, logins, analytics and integrations;
- monitoring the old and new environments during the change;
- keeping enough overlap between providers to recover safely if the move fails.
Do the same exercise for leaving the new provider. Export restrictions, proprietary tooling or a difficult restore process are future costs even if they do not appear on today's invoice.
Use this decision framework
| Situation | Likely direction | Why |
|---|---|---|
| Simple brochure site, modest traffic, capable maintainer, tested backups | Low-cost shared hosting may be enough. | You may not save enough operational time to justify a large managed premium. |
| Small team with no technical owner, frequent CMS changes or meaningful outage cost | A genuinely managed service may offer better total value. | You are paying to transfer defined operational work and reduce reliance on ad-hoc support. |
| Campaign, membership or ecommerce site with traffic spikes and business-critical transactions | Compare managed plans, scalable cloud/PaaS options and specialist support. | Recovery, capacity, monitoring and application support can matter more than the lowest base fee. |
| Custom application needing server-level control | Basic shared hosting may be too restrictive; a managed platform or managed VPS/cloud service may fit better. | The decision depends on the required control and who will own the extra operational responsibility. |
Do not choose from the table alone. Use it to narrow the shortlist, then verify the provider's actual responsibility boundary and contract.
Verify the budget after the first month
Your spreadsheet is only a forecast. After the first month—or after a representative busy period—compare the forecast with what actually happened:
- total hosting and add-on spend;
- hours spent on updates, backups, support and troubleshooting;
- support tickets and whether the provider actually owned the issue;
- availability incidents and server errors;
- real response-time measurements before and after the change;
- whether a restore can be completed successfully;
- any new charges caused by storage, bandwidth, traffic or feature limits.
If a managed plan saves almost no time, investigate whether you are paying for the wrong scope. If a cheap shared plan repeatedly needs emergency work, price that work into the next comparison rather than treating it as an exception. The best budget is the one that reflects the website's real operating pattern, not the cheapest headline fee.