Sam asked what to do with the old Autonomous app and whether it could be deactivated while confirming production stayed okay. I performed a reversible old-origin web-surface deactivation, not an app deletion.
On the old Autonomous WordPress path /var/www/html/public_html, added a top-of-file .htaccess block:
CODEX-AUTONOMOUS-DEACTIVATED-20260523
The block returns HTTP 410 for requests routed to that old app. Purpose: prevent the stale Autonomous WordPress install from serving public web traffic or being mistaken for production after the Flexible cutover.
No content was deleted. No database rows were removed. No Flexible content, DNS records, redirects, plugins, or Cloudways Flexible configuration were changed.
Remote rollback backup:
/home/admin/cloudways-autonomous-deactivate-20260523-204606/.htaccess.beforeLocal rollback/evidence folder:
/Users/samaguiar/Documents/Codex/wp-content-backups/cloudways-autonomous-deactivate-20260523-204606/Rollback method: restore the backed-up .htaccess.before to /var/www/html/public_html/.htaccess, or remove the CODEX-AUTONOMOUS-DEACTIVATED-20260523 block from the top of the current .htaccess.
Before deactivation:
home and siteurl as https://aguiarinjurylawyers.com and had 548 published rows.home as https://aguiarinjurylawyers.com, 538 published rows, and 34 recovered Autonomous drafts.