Book a demo
Book a demo
Login

Solution WordPress

Prepare a WordPress migration cutover

Inventory site state, plan migration destination, DNS changes, and acceptance testing. The target accepts new leads after DNS change and old leads reconcile.

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

Published · Updated · xCloud editorial

Read this guide as Markdown

Requirements and responsibilities

  • Have named ownership of the domain, selected xCloud team and site, and WordPress administrator access. For this scenario, agree who supplies the data and signs off: A business is changing WordPress hosts without losing form leads near launch.

    xCloud agent capability boundaries · WordPress roles and capabilities

  • Use a compatible Nginx or OpenLiteSpeed stack for native WordPress. Verify current server resources, plan eligibility and each selected plugin or service license and requirements before installing; a Docker server does not host a new native WordPress site.

    xCloud agent capability boundaries · WordPress plugin administration

  • Prepare a safe test identity and a completed, accessible backup before consequential changes. The important failure to plan around is: A DNS switch can straddle two live databases.

    Site backups in xCloud · WordPress hardening handbook

  • Before any database copy or restore starts, the authorized operator restricts the target and quarantines outbound mail, payment, fulfillment and other provider effects. Restored settings may overwrite plugin suppression; reapply sandbox credentials and verify isolation before testing.

    Create a staging environment in xCloud · Site backups in xCloud

Illustrative situation

Illustrative scenario, not a customer case study: A business is changing WordPress hosts without losing form leads near launch. The target accepts new leads after DNS change and old leads reconcile.

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 source data, mail, dns and integrations

Where
WordPress public/admin views and relevant provider evidence
Permissions
Named WordPress/app administrator or business owner; use authorized test accounts.
Inputs
Inventory source data, mail, dns and integrations; exact site identity, named approver and controlled sample data.
Action
Inventory source WordPress data, integrations, mail, DNS authority and newest lead record.
Expected result
The migration has a source snapshot and decision owner.
Verify
The migration has a source snapshot and decision owner. Record the observed site, account or transaction and time in the release sheet.
If it fails
If ongoing edits cannot pause, start a replay log.

Sources: WordPress roles and capabilities · xCloud WordPress migration guide · Enable HTTPS and configure SSL certificates in xCloud

Step 2 of 5

Migrate to a compatible WordPress target

Where
xCloud Add site and site overview
Permissions
Named xCloud team/site administrator; confirm target and scope.
Inputs
Migrate to a compatible wordpress target; exact site identity, named approver and controlled sample data.
Action
Build a compatible target in xCloud and migrate a copy using the documented procedure, leaving live DNS unchanged.
Expected result
The target can be tested without public traffic.
Verify
The target can be tested without public traffic. Record the observed site, account or transaction and time in the release sheet.
If it fails
If PHP/plugin requirements differ, resolve them on a copy.

Sources: xCloud agent capability boundaries · xCloud MCP documentation and connection profiles · xCloud WordPress migration guide · Enable HTTPS and configure SSL certificates in xCloud

Step 3 of 5

Compare latest records and choose freeze boundary

Where
WordPress public/admin views and relevant provider evidence
Permissions
Named WordPress/app administrator or business owner; use authorized test accounts.
Inputs
Compare latest records and choose freeze boundary; exact site identity, named approver and controlled sample data.
Action
Compare recent posts, forms and media; agree a freeze time or a way to replay late submissions from old site.
Expected result
Cutover has a defined data boundary.
Verify
Cutover has a defined data boundary. Record the observed site, account or transaction and time in the release sheet.
If it fails
If both sites can receive leads with no reconciliation, delay DNS change.

Sources: WordPress roles and capabilities · xCloud WordPress migration guide · Enable HTTPS and configure SSL certificates in xCloud

Step 4 of 5

Lower dns ttl if appropriate and switch approved records

Where
Authorized DNS provider and public browser
Permissions
Named xCloud team/site administrator; confirm target and scope.
Inputs
Lower dns ttl if appropriate and switch approved records; exact site identity, named approver and controlled sample data.
Action
At approved time the domain owner updates exact DNS records; inspect authoritative answers and HTTPS on the target.
Expected result
New visitors reach the intended target.
Verify
New visitors reach the intended target. Record the observed site, account or transaction and time in the release sheet.
If it fails
If traffic splits, retain old site data and reconcile both sides.

Sources: xCloud WordPress migration guide · Enable HTTPS and configure SSL certificates in xCloud

Step 5 of 5

Watch both sites and reconcile late submissions

Where
WordPress public/admin views and relevant provider evidence
Permissions
Named WordPress/app administrator or business owner; use authorized test accounts.
Inputs
Watch both sites and reconcile late submissions; exact site identity, named approver and controlled sample data.
Action
Monitor first real submissions and old-host logs, then close old intake only when late records are accounted for.
Expected result
No lead is silently abandoned at cutover.
Verify
No lead is silently abandoned at cutover. Record the observed site, account or transaction and time in the release sheet.
If it fails
If a new lead remains on old host, move it through the agreed process before shutdown.

Sources: WordPress roles and capabilities · xCloud WordPress migration guide · Enable HTTPS and configure SSL certificates in xCloud

Maintenance

Recovery decisions

  • Before restoring, compare the chosen recovery point with newer business records. A DNS switch can straddle two live databases. Use the xCloud dashboard for native restore only after the owner approves target and scope; reconcile or preserve newer data first.

    Site backups in xCloud · xCloud agent capability boundaries

  • Validate the restored copy with representative content, authentication, HTTPS and this guide’s business acceptance test before moving traffic or closing the incident.

    Site backups in xCloud · WordPress hardening handbook

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

  • Create a WordPress site mcp · write

    Requires a compatible Nginx or OpenLiteSpeed server; Docker and single-site agentic servers cannot host a new WordPress site.

    Checkpoint: Approve the exact server, domain, capacity, cost and creation inputs before provisioning. Verify completion and HTTPS.

    Operation identifiers and scopes to discover

    servers.sites.wordpress.create

    Scopes: write:sites

    xCloud agent capability boundaries · xCloud MCP documentation and connection profiles

  • Change domain DNS and verify routing app · manual

    DNS changes belong to the domain provider or authorized DNS integration; reading an xCloud site does not establish public propagation or certificate validity.

    Checkpoint: Approve exact hostname and record values; check authoritative DNS and live HTTPS from an independent session.

    xCloud WordPress migration guide · Enable HTTPS and configure SSL certificates in xCloud

Copyable agent brief

Manual checkpoints

  • The named WordPress, app, dashboard or provider administrator performs the guide’s actual configuration step: Compare recent posts, forms and media; agree a freeze time or a way to replay late submissions from old site.
  • The business owner compares the controlled sample with this observable result: New visitors reach the intended target.
  • 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