Skip to content

Managed WordPress hosting

Know who owns every hosting decision.

A managed operating model for WordPress. Before access changes hands, we define the server boundary, backups and restore evidence, update approvals, monitoring path, incident decisions, and final handoff in writing.

  • Responsibility matrix
  • Restore evidence
  • Change record
  • Rollback decision
  • Access handoff
Operating modelScope first
An operations specialist reviewing infrastructure dashboards beside server racks
Concept image. The written controls below define the engagement, not a dashboard illustration.

Responsibility matrix

Managed does not mean invisible.

The proposal names the platform, Tenten and client owners for each boundary. If ownership changes, the matrix changes before access or production work does.

01

Cloud account and billing

Tenten

Recommend an option and document the access needed for the agreed scope.

Your team

Own the commercial account and approve spend unless the proposal says otherwise.

Evidence retained

Account owner, billing contact, access boundary

02

Server baseline

Tenten

Record the runtime, configuration, dependencies and known constraints before change work starts.

Your team

Confirm the production site, business critical periods and people who can approve risk.

Evidence retained

Baseline inventory, scope, approver

03

WordPress and PHP changes

Tenten

Assess compatibility, record versions and execute an approved change window. Use staging when it exists and is included.

Your team

Provide valid plugin licenses, acceptance criteria and a decision owner for functional risk.

Evidence retained

Change record, checks, rollback condition

04

Backups and restore

Tenten

Run the agreed schedule and retain the job and restore evidence included in scope.

Your team

Confirm data criticality, retention needs and the acceptable recovery trade-off.

Evidence retained

Backup result, restore test, timestamp

05

Monitoring and escalation

Tenten

Configure the agreed checks, validate alerts and open the documented escalation path.

Your team

Keep business contacts current and decide when impact calls for customer communication or a trade-off.

Evidence retained

Signal, threshold, channel, decision owner

06

Domain, DNS and third parties

Tenten

Make only approved changes inside the agreed control boundary.

Your team

Retain ownership and recovery access for the registrar, DNS, email and connected services.

Evidence retained

System owner, recovery path, approved change

07

Data, content and compliance

Tenten

Protect granted access and follow the data handling boundary written into the engagement.

Your team

Own lawful processing, content accuracy, retention decisions and regulatory approval.

Evidence retained

Data boundary, access list, client approval

08

Incident and rollback

Tenten

Record the timeline, contain the issue and recommend a forward fix or rollback from the available evidence.

Your team

Approve business trade-offs when recovery time, data loss or customer impact differs between options.

Evidence retained

Incident timeline, decision, recovery checks

Minimum evidence pack

A control is useful when someone can review the record.

These are minimum record shapes, not a claim that every item is already complete. The estimate states which artifacts Tenten will create, retain and hand over.

01

Required record

Backup and restore evidence

Can this site be recovered from a known point?

  • Agreed schedule and retention
  • Files and database job result
  • Restore target, result and timestamp
  • Gap or exception that still needs an owner

A successful backup job is not the same as a successful restore test.

02

Required record

Update and change record

Is this change understood, approved and reversible enough to run?

  • Request, owner and affected versions
  • Risk and maintenance window
  • Pre-change and post-change checks
  • Rollback condition and known-good point

Updates are assessed changes. Custom code and plugins can make unattended updates unsafe.

03

Required record

Monitoring and escalation map

Who receives the signal, validates impact and makes the next decision?

  • Endpoint or resource being checked
  • Signal and alert condition
  • Primary and backup escalation channels
  • Business decision owner

Monitoring can detect a symptom. It does not guarantee availability or resolve the cause.

04

Required record

Incident and rollback record

Do we contain, fix forward, restore or roll back?

  • Timeline and observed impact
  • Recent changes and working hypothesis
  • Decision owner and containment action
  • Recovery checks and follow-up owner

Rollback is conditional. Data changes and third-party failures may need a different recovery path.

05

Required record

Access and handoff pack

Can the next owner operate the site without hidden access or context?

  • Account and system inventory
  • Named owners and access level
  • Runbook, open risks and next window
  • Credential transfer, rotation or revocation

The client keeps recoverable ownership. Secrets stay in an approved credential store, not in the runbook.

Operating decisions

Five gates before the next action.

A runbook should make the stop, approve, escalate and handoff points visible. It should not turn every alert into the same answer.

  1. 01

    Before migration

    If there is no named owner, required access or usable recovery point, resolve that gap before scheduling cutover.

    Record: Owner list, access check, baseline and recovery point

  2. 02

    Before a planned change

    Record the risk, approver, window, checks and rollback condition. Use an available staging path when it is compatible and included.

    Record: Approved change record

  3. 03

    When an alert fires

    Validate user impact and recent changes, then escalate through the agreed channel. Do not treat the alert itself as a diagnosis.

    Record: Alert evidence and triage note

  4. 04

    During an incident

    Contain first. Choose a forward fix, restore or rollback against the known-good state, data risk and business impact.

    Record: Incident timeline and recovery decision

  5. 05

    At handoff

    Transfer the inventory, open risks, access boundary and next maintenance window. Rotate or revoke access as agreed.

    Record: Signed-off handoff pack

Infrastructure options

AWS, GCE or Azure. No universal winner.

These are platform options, not performance promises. The proposal confirms the account owner, region, required services, support path, costs and exit requirements before a provider is selected.

Amazon Web Services logo

Option 01

AWS

Amazon Web Services. Availability and fit are confirmed against the actual account and scope.

Google Compute Engine logo

Option 02

GCE

Google Compute Engine. Availability and fit are confirmed against the actual account and scope.

Microsoft Azure logo

Option 03

Azure

Microsoft Azure. Availability and fit are confirmed against the actual account and scope.

Provider decision inputs

  • 01Existing account ownership and procurement
  • 02Required region and service availability
  • 03Current architecture and migration constraints
  • 04Budget, provider support and account responsibilities
  • 05Exit, recovery and handoff requirements

Fit and trade-offs

Useful when ownership matters. Wrong when certainty is being sold as a feature.

Good fit

  • A WordPress site with named technical and business decision owners.
  • A team that wants recurring maintenance backed by written change and recovery records.
  • An organization that can provide recoverable provider, WordPress, registrar and DNS access.
  • A team prepared to use maintenance windows, acceptance checks and explicit approval for risk.
  • A buyer who values a clear handoff and continued client ownership of the accounts.

Not a fit

  • A requirement for uninterrupted availability, zero incidents or universal performance gains.
  • An expectation that every core, PHP, theme and plugin update runs without compatibility review.
  • A setup with no client-side account owner, recovery access or business decision contact.
  • A regulated or certified operating requirement that has not been separately reviewed and written into scope.
  • A one-time speed repair with no ongoing hosting need. That should be scoped as performance work instead.

Scope boundary

What this page does not promise

  • Cloud provider outages, credits and regional service terms remain subject to the selected provider.
  • Monitoring coverage and response channels are defined in the proposal. Monitoring does not mean continuous human observation or guaranteed uptime.
  • Backups reduce recovery risk, but recovery depends on retention, restore testing, data timing and the failure mode.
  • Security controls reduce exposure. They do not make WordPress, custom code or third-party services incident-free.
  • Plugin licenses, custom application work, DNS or email ownership, compliance review and specific recovery objectives are included only when written into scope.

Scope the operating contract

Bring the current host, access map and recovery questions.

We will identify the missing decisions, confirm what Tenten can own, and put the responsibilities, evidence and exclusions into the estimate.

Get a free estimate