Operations WordPress

Hand over WordPress recovery information

Provide backup location/status, access owner, restoration caveats, and escalation route. Check the named site's prerequisites, task result, backup scope and recovery handoff with xCloud.

Read this guide as Markdown

Requirements and responsibilities

Illustrative situation

A client is ending an agency maintenance agreement. The receiving team needs enough WordPress recovery information to find backups and make a safe restore decision during an outage.

Choose the approach

Dashboard and application procedure

Follow these steps yourself, or use the scoped AI handoff below for supported hosting operations.

Step 1 of 5

Identify service ownership

Where
Agency contract and xCloud site
Permissions
Authorized xCloud read access to the named team and site; the relevant app or provider owner supplies records outside xCloud.
Inputs
Team, server, domain, WordPress owner
Action
Record exact resource IDs and who can authorize a restore, DNS change and customer communication.
Expected result
A named decision chain.
Verify
Ask recipient to confirm access to the intended team.
If it fails
If the client lacks team access, transfer it before agency removal.

Sources: xCloud MCP documentation and connection profiles · xCloud agent capability boundaries

Step 2 of 5

Locate recovery points

Where
xCloud Site Backup
Permissions
Authorized xCloud site owner with dashboard rights for the exact setting, backup, staging or restore action and a reviewed target.
Inputs
Completed snapshots, scope, destination, retention
Action
Show recipient where to find backup history and settings. Record latest Completed timestamp and file/database scope.
Expected result
A known recovery point and age.
Verify
Have recipient locate the row unaided.
If it fails
If backup is stale or failed, flag it and repair before handover closes.

Sources: Site backups in xCloud · xCloud agent capability boundaries

Step 3 of 5

Map data gaps

Where
WordPress app and external systems
Permissions
Authorized WordPress/WooCommerce application administrator or delegated role with rights for this task; hosting access alone is insufficient.
Inputs
Orders, bookings, members, mail and payment ledgers
Action
Describe what a snapshot restores and which post-snapshot records need reconciliation. List external systems and their owners.
Expected result
A realistic recovery boundary.
Verify
Walk through one sample transaction after the backup time.
If it fails
If newer data cannot be recovered, escalate this risk explicitly.

Sources: Manage WordPress plugins

Step 4 of 5

Rehearse decision path

Where
Handover meeting and safe target
Permissions
Authorized xCloud read access to the named team and site; the relevant app or provider owner supplies records outside xCloud.
Inputs
Restore target, approval, test checklist
Action
Simulate an outage decision: choose backup and target, identify data to preserve, and list login/content/business checks. Do not restore production as a teaching exercise.
Expected result
Recipient can explain the recovery sequence.
Verify
Ask them to identify when not to restore.
If it fails
If target or scope is confused, repeat the exercise before signing off.

Sources: xCloud MCP documentation and connection profiles · xCloud agent capability boundaries · Site backups in xCloud

Step 5 of 5

Transfer access securely

Where
Approved password manager and xCloud Team Management
Permissions
xCloud team owner authorized to review or change membership; preserve another working owner.
Inputs
Owners, account rotation, support contacts
Action
Transfer secrets through the client's approved manager, rotate shared credentials and update team membership after new owner verifies access.
Expected result
A complete, controlled handover.
Verify
Client signs in and finds backup and support contacts.
If it fails
If a sole admin is removed prematurely, restore access through approved ownership process.

Sources: xCloud team roles and permissions

Maintenance

Recovery decisions

AI handoff

Connect an authorized xCloud MCP profile and discover its exact tools and team scope. The packaged REST wrapper is GET-only; use dashboard or app controls for undocumented writes.

Supported scope

  • Confirm requirements and inspect resources mcp · read

    Discover the connected profile and operation schema first; only teams granted to the connection are visible.

    Checkpoint: Confirm exact team, server and site identity. Use dashboard_url returned by the resource; do not invent a dashboard link.

    Operation identifiers and scopes to discover

    teams.index, servers.show, sites.show

    Scopes: read:servers, read:sites

    xCloud MCP documentation and connection profiles · xCloud agent capability boundaries

Copyable agent brief

Manual checkpoints

  • Approve exact site, target, cost and any write or maintenance window after inspecting the proposed plan.
  • An authorized WordPress administrator must configure and test app users, content, integrations and business rules in the app.
  • Native WordPress staging, backup schedule/settings, push/pull and all restores are dashboard-only; Docker restore is dashboard-only and replaces state.
  • Reconcile data created after the chosen recovery point before any destructive restore.
Feature coverage

Sources

Continue

Explore all use cases