Website Managed Services

How to Evaluate a Managed Web Services Provider

A practical guide to evaluating a managed web services provider: the evidence to demand, the SLA clauses that decide whether the contract is worth anything, and the diligence questions to put in front of every vendor before you sign. Written for IT managers, digital leads and procurement teams responsible for a website that generates revenue or leads.

What you are actually buying when you buy managed web services

Most managed web services proposals read the same way: monitoring, backups, updates, support. The words are identical across vendors. What differs is what happens at 2am on a Sunday when the checkout is returning 502s, and whether anyone in the vendor's team is allowed to open the codebase and fix the cause.

Underneath the marketing, you are buying four separable things:

Infrastructure operation. Server provisioning, patching the OS and web stack, TLS certificate renewal, database tuning, backup execution and restore capability, firewall and DDoS posture.
Application maintenance. CMS core and module updates, dependency upgrades, PHP or Node runtime version moves, regression testing, deployment through a repeatable pipeline.
Incident response. Detection, triage, communication, remediation and a written post-incident record.
Change capacity. The developer hours to build the new form, integrate the CRM, fix the accessibility defect or ship the campaign template.

A provider that only sells the first of those four is a host. A provider that only sells the fourth is a project agency. Enterprise website management means all four under one accountable party, and the reason to be strict during evaluation is that the gaps between them are where outages live. If you want a clean baseline for scope comparison, our breakdown of what website managed services actually include and exclude is a useful checklist to hold each proposal against.

The vendor gap: why hosting and website providers are rarely the same company

The typical arrangement looks reasonable on a slide. A hosting company runs the server. A web agency built the site and does occasional work. An internal marketing team owns content. Everyone has a contract.

Then the site slows to a crawl during a campaign. The host reports CPU at 90 per cent and says the application is issuing unbounded database queries, which is not their scope. The agency says the server has insufficient resources and no object caching, which is not their scope. Both are partly right. Neither is obliged to resolve it, and you are the only party with an incentive to. That standoff usually costs days, and days of degraded performance on a lead generation site is real revenue.

This is the single most useful lens for evaluating any managed web services provider: ask who is contractually responsible when the cause is ambiguous. If the answer requires two vendors to agree, you have not removed the risk, you have documented it.

Step one: document your own environment before you go to market

Vendors can only quote against what you tell them, and vague briefs produce quotes that are re-priced three months in. Before the first call, assemble:

CMS and version for every site in scope, including microsites and campaign domains nobody has looked at for two years
Runtime versions: PHP, Node, Python, and the database engine and version
Where the code lives, whether there is a Git repository, and whether production matches it
Hosting arrangement: provider, account ownership, region, whether it is shared, VPS, or a cloud account you own
Integrations and outbound dependencies: CRM, payment gateway, ERP, email service, single sign-on, third party scripts
Traffic profile and peak events, and what a peak actually looks like in requests per minute
Compliance obligations: WCAG level, privacy, records retention, any penetration testing or security rating requirement
Current pain: the last five incidents, how long each took, and who resolved them

That last item is the most valuable and the most commonly skipped. A vendor who reads your incident history and immediately names the likely root causes is demonstrating capability. One who does not mention it is quoting a template.

Capability evidence to request, not just claims

Every provider will say they monitor, back up and patch. Ask them to prove it with artefacts from existing clients, redacted as needed.

Claim	Evidence to request	What a weak answer looks like
We take backups	Backup frequency, retention period, storage location, and the date and result of the last documented restore test	"Nightly backups" with no restore ever performed
We monitor 24/7	A sample alert, the escalation path, who receives it out of hours, and read access to the monitoring dashboard for your sites	Uptime checks only, no alerting to a human, no synthetic transaction checks
We patch and update	A redacted maintenance report showing specific packages and versions applied, with dates	"Updates applied monthly" with no itemised record
We have documented process	An actual runbook: restore procedure, rollback procedure, incident escalation, certificate renewal	Process described verbally, nothing written
We deploy safely	The CI/CD pipeline, staging environment policy, and how a bad release is rolled back	Changes made directly on production over SFTP
We track security	How CVEs affecting your stack are identified and triaged, and the last three acted on	"We use a security plugin"
We keep change history	Git history, ticket history, and a change log you can read without asking	Work described in emails only

Two artefacts matter more than the rest: a restore test with a date on it and a runbook you can read. Backups that have never been restored are a hypothesis. Process that exists only in one senior engineer's head disappears when that engineer takes leave.

Testing incident response during evaluation

Put scenarios in writing and require written answers. You are testing whether the response describes actual mechanics or reassuring generalities.

The homepage returns HTTP 500 at 6:40pm on a Friday. Who is notified, by what mechanism, and what is the first action taken?
A critical CVE is published for our CMS core with a public exploit. What happens in the first 24 hours, and who authorises an emergency patch?
The database is corrupted at 11am and the last clean backup is six hours old. Walk through the restore, the expected duration, and what content is lost.
A third party integration starts timing out and page loads exceed 20 seconds. How is the failing dependency isolated?
Malicious file uploads are found in the web root. What is the containment sequence, and how do you determine the entry vector?
A deployment breaks the enquiry form and nobody notices for four hours. How would monitoring have caught it, and how is it rolled back?

Good answers name tools, thresholds, roles and timeframes. Weak answers say the team would investigate promptly. It is also worth reading through what a competent first hour of urgent website support looks like so you can benchmark the responses you get.

Reading the SLA properly

Response versus resolution

Most CMS support SLAs commit to a response time only. A one hour response can mean an automated ticket acknowledgement. Ask what the target is for a fix, or at minimum for a workaround and a written cause, and whether that target is contractual or aspirational. If a provider will not commit to resolution targets, ask what their historical median time to restore service has been for severity one incidents.

Severity definitions

Severity levels decide which clock applies, so who classifies an incident matters enormously. Insist that severity is defined by business impact rather than technical category, that you can escalate a classification, and that specific examples are written into the schedule. A broken payment path and a broken sitemap should never share a tier.

Coverage windows

"24/7 monitoring" and "24/7 response" are different products. Confirm the hours during which a human will act, the time zone those hours are expressed in, whether public holidays are included, and which state's holidays apply. For retail, confirm coverage across your peak trading period explicitly.

Exclusions and service credits

Read the exclusions before the commitments. Common carve-outs include third party outages, DNS you control, upstream cloud provider incidents, content changes made by your team, and any planned maintenance window. Service credits are usually capped at a portion of the monthly fee, which means they are a governance signal rather than compensation. What matters is whether a breach triggers a formal review and remediation plan. Our guide to website support SLAs for enterprise and government sets out how these schedules are normally constructed, and there is a companion piece on what to do when an SLA is breached.

Commercial structures compared

Structure	Best suited to	Main risk	Watch for
Monthly managed retainer	Sites where uptime and security are the priority and change volume is steady	Paying for capacity you do not consume in quiet months	Whether the retainer includes development hours or only maintenance
Prepaid hour blocks	Organisations with irregular project work on top of a maintenance base	Hours expiring unused, or being consumed by admin	Expiry terms, rollover, and minimum billing increments
Per-site fixed fee	Multi-site estates with similar builds	Complex sites subsidised by simple ones, then re-priced	How a site is reclassified when traffic or complexity grows
Time and materials	Low-stakes sites with no SLA requirement	No incentive to prevent recurring faults	Whether after-hours work carries a loaded rate
Infrastructure at cost plus management fee	Organisations that own their own AWS or Azure account	Split responsibility if the cloud account is not fully delegated	Who holds root, and who can change billing-relevant resources

Time and materials deserves particular scepticism for a critical site. It pays the vendor for recurrence and gives them no financial reason to eliminate the cause of repeat faults.

Access, ownership and exit

The clauses you will care about most are the ones you hope never to use. Establish before signing:

Code. You own the repository, in your organisation's Git account, with the vendor as a collaborator. Not the reverse.
DNS. Your registrar account, your ownership, vendor granted delegated access. DNS held by a departing vendor is a hostage situation.
Cloud accounts. Either you own the account and delegate, or the vendor owns it and you have a written migration path with a defined timeframe.
Backups. The right to request a full database and file export at any time, in a documented format, without a fee.
Documentation. Runbooks, environment variables, integration credentials and architecture notes handed over at offboarding, not reconstructed after.
Notice and assistance. Termination notice period, and an obligation to provide reasonable transition assistance at agreed rates.

If you are already locked into an arrangement without these, they can be recovered, but it is a project rather than an email. That is the substance of a vendor replacement and transition engagement.

Red flags that predict a difficult relationship

No staging environment, or changes described as "tested on production carefully"
Cannot produce a dated restore test
Refuses read access to monitoring or the ticket queue
Single named engineer with no documented backup or on-call rotation
Support only via a personal mobile or an individual's email address
Cannot describe how they would handle a CMS major version upgrade for your platform
Quotes without asking a single question about your integrations or traffic peaks
Owns your domain, DNS or repository as a matter of policy
Treats security as a plugin rather than a layered configuration
Talks about infrastructure but has no developers, or has developers but no infrastructure engineers

A question set you can paste into an RFP

Which environments will exist, and how does code move between them?
What is monitored, at what interval, and what triggers a page to a human?
What is the backup frequency, retention and storage region, and when was the last restore test?
What is your recovery time objective and recovery point objective for a total server loss?
How are CVEs affecting our stack identified, and what is the patch window by severity?
Who is on call outside business hours, and how many people can resolve a severity one incident?
Define your severity levels with examples relevant to our site, and state who classifies an incident.
What are your response and resolution targets per severity, and what are the exclusions?
How many hours of development work are included, and what happens when we exceed them?
Who performs the work, in which locations, and are any parts subcontracted?
What reporting do we receive monthly, and does it itemise updates applied?
What is the offboarding process and the timeframe for handing over all assets?
Name two clients on the same CMS at similar scale that we can speak to.

What a well-run first ninety days looks like

Onboarding quality is the best available predictor of ongoing quality. A competent transition follows a recognisable shape.

Days 1 to 14. Infrastructure and application audit. Full inventory of versions, dependencies, cron jobs, integrations and certificates. Access consolidated and secured with MFA. Monitoring and alerting stood up before anything is changed.

Days 15 to 45. Backups configured and a restore proven in a scratch environment. Staging environment created. Code brought into version control if it was not already. Critical security findings remediated. WAF and DNS posture reviewed.

Days 46 to 90. Deployment pipeline in place. Patch and update cadence running with itemised reporting. Runbooks written for restore, rollback and escalation. A prioritised remediation roadmap for the technical debt that cannot be fixed in the first month, with effort estimates.

If a provider's onboarding plan is "we will take over the credentials and let you know if we see anything", that is your answer.

Frequently Asked Questions

What is a managed web services provider?

A managed web services provider takes ongoing responsibility for the operation of a website, covering the hosting infrastructure, the CMS and application layer, security, monitoring, and incident response under a defined service level agreement. It differs from web hosting, which covers the server only, and from project-based web development, which ends at launch. The distinguishing feature is that one party is accountable for availability regardless of whether the cause sits in the server or the code.

What should a CMS support SLA actually commit to?

At minimum it should define severity levels with worked examples, response targets per severity, the hours during which a human will act and in which time zone, escalation contacts, and the exclusions that suspend the clock. Better agreements also commit to resolution or workaround targets, restore point and restore time objectives, and a formal post-incident review for severity one events. Service credits are useful as a governance trigger, but they rarely compensate for the commercial impact of an outage.

How do I know whether a provider's backups actually work?

Ask for the date and outcome of the most recent restore test, performed into a separate environment rather than over production. A provider running proper backup discipline will have this documented, along with retention periods, storage location and the recovery point objective. If no restore has ever been performed, the backups are untested and should be treated as unverified.

Should hosting and website management come from the same vendor?

For any site that drives revenue or lead generation, yes, because most serious incidents involve both layers. When a host and a developer are separate companies, ambiguous causes such as slow queries, memory exhaustion or caching conflicts produce a standoff where neither party is contractually obliged to resolve the issue. A single provider with both infrastructure engineers and developers removes that gap.

What should I own rather than let a provider hold?

You should own your domain registration and DNS, the Git repository containing your code, and ideally the cloud account if you are on AWS or Azure, granting the provider delegated access to each. You should also have a contractual right to request a full database and file export at any time. Ownership of these assets is what makes changing providers a project rather than a negotiation.

How long does it take to move to a new managed services provider?

A single well-documented site with clean version control can transition in two to four weeks including a migration and DNS cutover. Estates with undocumented servers, no repository, mixed CMS versions or live integrations typically take six to twelve weeks, with the audit phase consuming the first fortnight. The variable is rarely the migration itself, it is discovering what is actually running in production.

Where UnDigital fits

UnDigital operates as both the infrastructure provider and the development team, which is the arrangement this entire evaluation process tends to point towards. Our managed hosting for enterprise websites covers dedicated Australian infrastructure, 24/7 monitoring, six-hourly backups, WAF and DDoS protection and uptime SLAs, and the same team maintains the WordPress, Silverstripe, Drupal, headless and custom applications running on it. For organisations bringing their own cloud account, we also deliver management only. Every engagement begins with an infrastructure and application audit, so the first thing you receive is a documented view of what you actually have, and our enterprise website managed services page sets out how the ongoing arrangement is structured from there.

Bring your current SLA, your incident history and the list of things nobody has been willing to own, and we will tell you what we would change in the first ninety days.