iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
An AI agent helped plan, rehearse, and verify a production SaaS move to a new VPS, but it did not autonomously take over the whole migration. In a first-person case report published by Convertica on October 6, 2026, the agent inventoried the existing server, drafted a runbook, found problems during rehearsal, and supported a six-minute cutover. The operator retained payment, production approvals, and the DNS change. The account is a detailed example, not proof that another agent or migration will produce the same results.
Why the SaaS was moved
Convertica describes its service as a small PDF toolkit with real users and payments. It ran Django, Celery, Redis, Postgres, Nginx, and LibreOffice in Docker on one VPS. The author says resource-heavy tasks—including OCR on a 200-page scan and processing a large spreadsheet through LibreOffice—could push a Celery worker into its memory limit. The goal was to get more memory without simply paying the existing provider more or spending a weekend managing the move.
The author’s October 2026 comparison was:
| Reported specification | Former host: DigitalOcean droplet | Destination: OVH VPS-2 |
|---|---|---|
| vCPU | 2 | 4 |
| RAM | 4 GB | 8 GB |
| Disk | 80 GB | 75 GB NVMe |
| Reported monthly price | $34.44 | About $12 (44.53 PLN) |
These are the author’s reported figures, not current quotations or a market-wide comparison. The author says they personally checked the destination’s order page before paying. Anyone comparing VPS plans should confirm current availability, location, CPU, memory, disk, backup inclusion and cost, billing period, network behavior, and total monthly charge.
Quick wins for a faster PC:
Scan for outdated or missing drivers - takes under a minuteDriver Scan →Clear out junk files and repair common Windows errorsFree Scan →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →What the agent did before touching production
It inventoried the existing host
The author says the agent began with a read-only inventory rather than changing the running system. It reported a 24 MB Postgres database, 460 KB of uploaded media, and 17 MB of backups, while the old disk showed 52 GB used. The author attributes much of the remaining space to about 37 GB of old Docker images and 43 GB of build cache.
#1 Best Overall
The inventory also surfaced an operational issue unrelated to the new server: the origin SSL certificate had expired in March, and Certbot renewals had been failing because Nginx held port 80. A renewal script existed but was not in cron. According to the author, Cloudflare Full mode did not verify the origin certificate, so the site continued working without the certificate problem being noticed.
It prepared a migration runbook
The agent reportedly proposed preparing the destination without downtime, rehearsing with a copy of the database, testing HTTPS against the new host before changing DNS, and performing a short cutover with rollback instructions. The author says the rehearsal used curl --resolve to direct the real domain to the new IP without changing public DNS.
Celery beat—the scheduler for periodic tasks—was kept off on the destination during rehearsal. That avoided a situation in which scheduled work might run on both the old and new servers at once.
Free tools Windows power users keep installed
One-click scans. No signup required.
What the rehearsal caught
The test migration exposed three concrete problems before the live switch:
- Celery beat could not write its schedule file. The fresh Docker volume was root-owned, while the process ran as an unprivileged user. The author says the agent traced the ownership mismatch, corrected it, and documented the fix.
- The Nginx configuration check ran at the wrong time. A deployment script invoked
nginx -tinside the destination’s Nginx container before that container was running. The author says the agent changed the check to use a throwaway container from the same image. - Outbound email would have been blocked. Brevo accepted API calls only from whitelisted IP addresses, and the new server used IPv6. The author says the agent spotted the allowlist dependency and provided the addresses to authorize.
The destination was configured with a Cloudflare Origin Certificate and Cloudflare Full (strict) mode, according to the author.
How the production cutover worked
For the live move, the author says the app was stopped on the old server, a final database dump was restored on the new one, services were started there, and the Cloudflare DNS record was changed. Reported downtime ran from 14:44 to 14:50 UTC on a Monday afternoon: six minutes in this case, not a duration to expect from a different application or setup.
Afterward, the author updated CI deployment secrets to point at the new host, and a later release went through the normal pipeline. The operator—not the agent—changed DNS and handled payment and approvals for actions affecting production. The author also says some proposed work was deliberately deferred.
What changed after the site came back
The migration was not the end of the work. The author reports making these follow-up changes:
- Adjusted resource limits for the 8 GB host and restored a dedicated Celery worker for premium jobs.
- Required Cloudflare Authenticated Origin Pulls at the origin.
- Added a Docker build-cache size cap after noticing cache growth of about 8 GB per release.
- Added daily
pg_dumpbackups with 14 days of retention alongside the provider’s daily snapshot. - Enabled VPS auto-renew and removed the old droplet after checking for remaining billable volumes, snapshots, or reserved IPs.
The author says they tested both direct-IP access and the Cloudflare route with curl. Those reported checks describe what was implemented in this case; they are not an independent security audit or proof that backups can be restored successfully.
What this case says about using an agent for a server migration
Useful work depends on access to the real system
The author’s account suggests the agent’s plan was based on the Compose files, container limits, data sizes, and server state—not only on a short description of the application. That context helped it identify storage facts, the overlooked certificate-renewal issue, and migration dependencies such as the email IP allowlist.
Rehearsal matters more than a confident plan
The schedule-file ownership issue, premature Nginx check, and outbound-email restriction became visible during the rehearsal rather than after the public switch. The useful lesson is not that an agent will always catch these classes of failure; it is that a copied-data rehearsal and pre-cutover checks create a chance to find them while rollback is straightforward.
Keep consequential decisions with the operator
The author says the agent handled provider research, inventory, runbook preparation, rehearsal debugging, verification, and cleanup. The operator logged into dashboards, paid for the destination, approved production-affecting commands, changed DNS, and chose what to postpone. The author’s stated principles were: “Insist on read-only first,” “Make it prove every step,” and “Keep the irreversible buttons for yourself.”
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.A practical checklist for planning a similar move
The case points to checks worth doing before choosing a destination or scheduling a cutover:
- Compare current plans on CPU, RAM, disk capacity and type, region, total recurring cost, billing terms, and backup pricing.
- Check network behavior and dependencies outside the VPS, including IP allowlists for mail or other APIs.
- Inventory database, uploaded files, backups, disk usage, certificates, scheduled renewals, container limits, and build caches.
- Rehearse with a copy of production data; keep duplicate schedulers and other side-effecting jobs disabled on the destination.
- Verify the destination’s HTTPS path before changing DNS, and define a rollback path and a final-data-sync procedure.
- Require observable evidence for claimed completion—such as command output, health checks, and running-container lists—and keep approval for irreversible or production-facing actions with a human.
- After cutover, verify application behavior, deployment credentials, origin access, backups, renewal, resource limits, and any remaining billable resources on the old host.
The source for this case is Convertica’s October 6, 2026 DEV Community account. Its details are the author’s report; they do not establish a general migration success rate or independently audited outcome.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
Recommended Free Tools
