Book a demo
Book a demo
Login

Solution WordPress

Transfer WordPress access when a retainer ends

Remove or change access deliberately and hand over operating and recovery details. The client can administer and restore with their own credentials.

Technical review: · Source reviewed; no production deployment test claimed

Published · Updated · xCloud editorial

Read this guide as Markdown

Requirements and responsibilities

Illustrative situation

Illustrative scenario, not a customer case study: A WordPress maintenance retainer ends while the client continues operating the site. The client can administer and restore with their own credentials.

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

Inventory accounts, dns, storage and paid licenses

Where
WordPress public/admin views and relevant provider evidence
Permissions
Named WordPress/app administrator or business owner; use authorized test accounts.
Inputs
Inventory accounts, dns, storage and paid licenses; exact site identity, named approver and controlled sample data.
Action
Inventory agency/client xCloud, WordPress, DNS, storage and paid-plugin accounts; identify which must continue after the retainer.
Expected result
Transfer scope has no hidden agency-owned dependency.
Verify
Transfer scope has no hidden agency-owned dependency. Record the observed site, account or transaction and time in the release sheet.
If it fails
If a license cannot transfer, agree replacement before ending support.

Sources: WordPress roles and capabilities · xCloud team roles and permissions

Step 2 of 5

Create client-owned xcloud and WordPress access

Where
xCloud team membership dashboard
Permissions
Named xCloud team/site administrator; confirm target and scope.
Inputs
Create client-owned xcloud and wordpress access; exact site identity, named approver and controlled sample data.
Action
Have xCloud team owner create client-owned named access and test it before removing agency roles.
Expected result
Client can reach hosting resources.
Verify
Client can reach hosting resources. Record the observed site, account or transaction and time in the release sheet.
If it fails
If invitation remains pending, do not revoke the only administrator.

Sources: xCloud team roles and permissions · xCloud agent capability boundaries · WordPress roles and capabilities

Step 3 of 5

Walk through updates, backup and incident contacts

Where
WordPress public/admin views and relevant provider evidence
Permissions
Named WordPress/app administrator or business owner; use authorized test accounts.
Inputs
Walk through updates, backup and incident contacts; exact site identity, named approver and controlled sample data.
Action
Walk the client through backups, selected updates, incident contact and WordPress role administration using its own account.
Expected result
Client knows where operational controls live.
Verify
Client knows where operational controls live. Record the observed site, account or transaction and time in the release sheet.
If it fails
If a control is plan-restricted, document the support path.

Sources: WordPress roles and capabilities · xCloud team roles and permissions

Step 4 of 5

Verify client can complete a safe administrative task

Where
WordPress public/admin views and relevant provider evidence
Permissions
Named WordPress/app administrator or business owner; use authorized test accounts.
Inputs
Verify client can complete a safe administrative task; exact site identity, named approver and controlled sample data.
Action
Ask client to perform a harmless content correction and locate a backup point, then record its acceptance.
Expected result
Handover is observed rather than a credential email.
Verify
Handover is observed rather than a credential email. Record the observed site, account or transaction and time in the release sheet.
If it fails
If the client cannot complete the rehearsal, extend transition support.

Sources: WordPress roles and capabilities · xCloud team roles and permissions

Step 5 of 5

Revoke each provider account

Where
xCloud, WordPress, DNS, storage and paid-provider account consoles
Permissions
Each named provider or application owner changes only their own access control.
Inputs
Revoke agency access and record handover acceptance; exact site identity, named approver and controlled sample data.
Action
After client acceptance, the xCloud team owner removes agency xCloud membership, the WordPress administrator removes agency application accounts, and each DNS, storage and paid-plugin owner revokes its own provider access. Verify every surface separately.
Expected result
No agency access remains in the accepted systems while client-owned administration continues.
Verify
No agency access remains in the accepted systems while client-owned administration continues. Record the exact account or record tested, result, and time with the responsible owner.
If it fails
If a resource still depends on agency ownership, keep that item open with a transfer date.

Sources: xCloud team roles and permissions · xCloud agent capability boundaries · WordPress roles and capabilities

Maintenance

Recovery decisions

AI handoff

Connect xCloud MCP through the current documented profile and grant only the scopes needed for the selected team. Discover tool schemas first. Read resources to plan; require approval for any supported write. Use returned dashboard URLs for manual work. The packaged REST wrapper accepts GET requests only.

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

  • Review a WordPress business journey app · manual

    Application data and observed transactions cannot be inferred from xCloud resource reads. Use authorized test accounts and the application or provider evidence.

    Checkpoint: Record the test identity, timestamp, expected outcome, observed result and owner decision.

    WordPress roles and capabilities

  • Manage xCloud team membership and roles dashboard · manual

    Team invitations and role changes require an authorized xCloud team owner in the dashboard. A read-only MCP resource view cannot modify access.

    Checkpoint: Review the exact team, account and role before saving. Sign in as the invited user to verify intended visibility.

    xCloud team roles and permissions · xCloud agent capability boundaries

  • Business owner review and acceptance app · manual

    Human planning, acceptance and record reconciliation cannot be inferred from xCloud resource reads. The business owner chooses the application's source of truth.

    Checkpoint: Record approved criteria, observed application evidence, unresolved questions and named follow-up.

    WordPress roles and capabilities · xCloud agent capability boundaries

Copyable agent brief

Manual checkpoints

  • The named WordPress, app, dashboard or provider administrator performs the guide’s actual configuration step: Walk the client through backups, selected updates, incident contact and WordPress role administration using its own account.
  • The business owner compares the controlled sample with this observable result: Handover is observed rather than a credential email.
  • Staging push/pull, native backup schedules, restores and cache-setting edits require the authorized xCloud dashboard operator; the packaged REST wrapper is GET-only.
Feature coverage

Sources

Continue

Explore the next WordPress workflow