Website Managed Services: What's Actually Included, and What Isn't

This page defines what "website managed services" should actually cover across infrastructure, platform, application and content, where hosting providers and build agencies each stop, and which inclusions and exclusions belong in the agreement. It is written for IT managers, digital leads and marketing managers who are buying or renegotiating an ongoing website arrangement.

What Buyers Mean by Managed Services, and What Vendors Usually Mean

When an organisation says it wants its website managed, it means something close to this: somebody else is accountable for the site being up, current, secure and fixed when it breaks, without the organisation having to work out whose job it is.

When a vendor says "managed", it usually means something much narrower. A hosting company means the server is patched and the disk has not filled up. A build agency means it will look at tickets during business hours if you have hours left on the retainer. A cloud platform means the runtime is abstracted away from you. All three are legitimate services. None of them is what the buyer described.

The gap is not usually dishonesty. It is that the word covers four different layers of a system, and most contracts silently apply to one of them.

The Four Layers of a Managed Website

Every website in production sits on four layers. Work that happens on one layer will not fix a fault on another, and each layer is typically owned by a different party unless you deliberately consolidate them.

The interesting layer is the second one. Platform maintenance is where almost every serious incident originates, and it is the layer with no natural owner. Your host will not upgrade a CMS major version. Your build agency will not do it unless someone raises a purchase order. So it sits, and the site drifts out of support until a penetration test or an insurance questionnaire forces the issue.

What a Hosting Provider Will and Will Not Touch

A competent hosting provider takes responsibility to the boundary of the operating system and, sometimes, the web server configuration. Inside that boundary they do genuinely useful work: OS package updates, resource monitoring, network level filtering, snapshotting the volume.

What they will not do, in almost every case:

• Update your CMS core, modules, plugins or themes
• Read an application error log and diagnose why a form stopped submitting
• Test that a backup actually restores into a working site rather than merely existing
• Change a PHP version, because it might break your application and that is not their risk to carry
• Review a CVE announcement and decide whether your specific configuration is exposed
• Touch code, ever

This is why "managed hosting" from a volume provider and managed hosting for an enterprise website are different products sharing a name. One manages a server. The other manages the thing the server exists to run.

What a Build Agency Will and Will Not Touch

The agency that built the site knows the codebase, which makes it the right party for application work. The problem is structural rather than technical. Build agencies are organised around projects: scoped, funded, delivered, invoiced, closed. Ongoing operational responsibility does not fit that shape.

In practice this means:

• No monitoring, or monitoring that pages nobody outside business hours
• No defined response or resolution targets, only "we will get to it"
• Dependency updates deferred because they are unbillable and invisible to the client
• The developer who knows your build leaves, and institutional knowledge leaves with them
• Infrastructure treated as somebody else's problem, because the agency has no server discipline

The Gap Between Them, and Who Pays for It

The gap is the platform layer plus everything time critical. It shows up at the worst possible moment: a critical vulnerability is announced for your CMS, and the host says it does not touch the application while the agency says it needs a scoped quote and has capacity next month.

The organisation pays for the gap three ways. It pays in unplanned emergency work at premium rates, it pays in accumulated upgrade debt that eventually becomes a re-platform project, and it pays in risk it did not know it was carrying. When an incident happens, the first hour is spent working out who is responsible rather than fixing anything, which is why break/fix and emergency support is so much more expensive than the maintenance that would have prevented it.

Scope Comparison: Hosting Only, Management Only, Full Managed Service

There are three coherent ways to buy this, and the right one depends on whether you already own infrastructure you intend to keep.

Inclusions Worth Writing Into the Agreement

Vague scope is the reason most managed arrangements disappoint. These are the clauses worth insisting on, each of which is falsifiable and therefore enforceable.

• Backup frequency and retention, plus a restore test cadence. A backup that has never been restored is a hypothesis. Ask how often a restore is actually performed into a working environment.
• Named response and resolution targets by severity. P1 through P4, in hours, with business hours and after hours defined separately. Vague "priority support" is not a target.
• Uptime commitment with a stated measurement method. A 99.9% figure means nothing unless you know what is being checked, from where, and how often. See how support SLAs for enterprise and government are typically structured.
• Security patching windows. Critical CVEs applied within a stated number of hours of a vendor release, with emergency patching outside the normal cycle for actively exploited vulnerabilities. Ongoing CVE scanning and vulnerability monitoring should be continuous, not annual.
• Platform currency. An explicit commitment that CMS, framework, runtime and database will be kept on supported versions, with major upgrades planned and budgeted rather than deferred indefinitely.
• Reporting. Monthly, showing uptime, patches applied, vulnerabilities found and closed, hours consumed and work completed.
• Escalation path. A named contact and a phone number, not a shared inbox.
• Exit terms. Data, code, configuration and credentials returned in a usable form within a stated period.

Exclusions You Should Expect, and Which Ones Are Reasonable

A managed services agreement with no exclusions is either mispriced or misleading. Reasonable exclusions include new feature development, design work, content production, third party licence fees, integrations with systems the vendor does not control, and faults caused by changes the client made without notice.

Exclusions that should concern you are the ones that hollow out the core service:

• Security patching listed as chargeable rather than included
• Incident response only during business hours on a site that transacts around the clock
• Major version upgrades excluded entirely with no plan for how they will ever happen
• Backups included but restores billed as project work
• Any clause that makes the vendor the sole judge of whether an incident is its fault

Third party plugin conflicts deserve a note. A vendor cannot be liable for a commercial plugin's defect, but it should be responsible for detecting the conflict, isolating it and telling you what to do next.

How Hours, Retainers and Fair Use Actually Work

Most agreements combine a fixed operational component with a pool of hours. The operational component covers monitoring, patching, backups and incident response, and it is not drawn from the hours. The hours cover discretionary work: content changes, small enhancements, integration adjustments, reporting requests.

Three questions decide whether the structure works for you. Do unused hours roll over, and for how long? What is the rate for hours beyond the pool, and is it the same rate as the retainer implies? Is proactive maintenance drawn from the pool, or funded separately? If patching consumes discretionary hours, your team will quietly deprioritise it, which defeats the purpose.

Fair use clauses are reasonable in principle. They should be expressed as a number, not as a mood. "Reasonable ongoing support" is not a scope. "Up to twelve hours per month, with additional hours quoted in advance" is.

Access and Handover: Secure These Before You Sign

The organisation should own the assets, and the vendor should have access to them. Arrangements often invert this, and it only becomes apparent when the relationship ends.

• Domain registrar account in the organisation's name, with the organisation as registrant contact
• DNS zone under the organisation's control, or transferable on request
• Git repository owned by the organisation, with full commit history
• Cloud accounts (AWS, Azure, Cloudflare, Vercel) billed to and owned by the organisation where the Management Only model applies
• SSL certificate ownership and renewal responsibility documented
• Third party licences held in the organisation's name, not the agency's
• Documented deployment process, environment variables and infrastructure configuration

If any of these are currently held by an incumbent who is not cooperating, that is a normal starting condition rather than a blocker. It is the ordinary first phase of a migration to a new vendor, and it is worth resolving before an incident forces it.

Frequently Asked Questions

What is included in website managed services?

A full managed service covers infrastructure (servers, backups, TLS, firewall, CDN, monitoring), platform maintenance (CMS core, modules, runtime and database versions), application support (bug fixes and small changes against defined response targets), and reporting. It should not usually include new feature development, design, content production or third party licence fees, which are scoped and quoted separately. If security patching or restores are chargeable extras, the agreement is a hosting contract with a support option rather than a managed service.

What is the difference between website hosting and website management?

Hosting covers the environment the site runs in: the server, operating system, network, backups and availability. Management covers the site itself: CMS and dependency updates, security patching, performance tuning, bug fixes and content support. They are frequently sold by different companies, which is why so many organisations have hosting and no management, and discover the gap only when a vulnerability is announced.

Who is responsible when a website goes down, the host or the developer?

It depends on the cause, which is exactly the problem with splitting the two. If the outage is a full disk or a network fault, it is the host. If it is a fatal application error after a deployment or a database query lock, it is the developer. Where one vendor holds both layers, the question does not need to be answered before work starts, which is normally the single largest reduction in time to resolution.

Do I still need managed services if my site runs on AWS or Vercel?

Yes, because those platforms manage the layer beneath your application, not your application. AWS will keep an EC2 instance running but will not upgrade your CMS, review a dependency CVE or fix a broken integration. This is the case for a Management Only arrangement, where the organisation keeps its own cloud account and billing relationship and a managed services partner takes responsibility for everything running on top of it.

How many hours per month should a website management retainer include?

There is no universal number, because it depends on the size of the codebase, the number of integrations, editorial volume and how current the platform is. A useful test is whether proactive maintenance is funded outside the discretionary hours. If patching, monitoring and backups draw down the same pool as content changes, the maintenance will lose that competition every month.

What should I check before signing a managed website agreement?

Confirm that you own the domain, DNS, code repository and third party licences, that response targets are stated in hours by severity, that backup restores are tested rather than merely scheduled, and that major version upgrades have a named plan rather than a blanket exclusion. Also confirm the exit terms: what you receive, in what format, and within how many days of termination.

Managed Website Services from UnDigital

UnDigital is both the hosting provider and the development team, which removes the boundary that most managed arrangements are built around. Engagements run under three models: Hosting + Management for organisations that want one accountable party for the whole stack, Hosting Only for teams with in-house developers, and Management Only for organisations committed to their own AWS, Azure or Vercel environments. Every engagement starts with an infrastructure audit, and pricing is scoped from what that audit finds rather than published as a plan.

The work covers WordPress, Silverstripe, Drupal, Craft, Statamic, headless builds on Storyblok, Sanity and Contentful, and custom applications on Next.js, Nuxt, Laravel and Node, with 24/7 monitoring, six-hourly backups, WAF and DDoS protection and ongoing security management and monitoring on dedicated Australian infrastructure. If your current arrangement covers the first layer and none of the others, an audit will tell you precisely where the gaps are.