AiXVPScost & terms for AI / automation

Contabo Decision guide Updated 2026-11-12

Moving to Contabo Without Losing the Old Server

A migration is an order-of-operations problem, not a copy problem. The old server stays alive until the new one answers, the DNS cutover is reversible, and the old data is still available after the new box is live. If I cancel first, copy second, I have turned a migration into a recovery. For a Contabo move, I would build the new VPS, copy and test the application on the new IP, lower the DNS TTL, cut over, keep the old server through the notice period, and only then cancel. Contabo provides the server, panel, snapshots, and support. The self-managed VPS path leaves the application migration to you; if you need a managed migration, ask Contabo or a third party before ordering.

Contabo review Sources
Contabo decision guide — one purchase question, one decision.
Scope. Decision draft. Contabo product and process facts were checked on the official Contabo pages on 2026-11-12. This is a planning analysis, not a performed migration, a restore test, or a provider ranking. Commands and application layouts vary; adapt the order to the real stack.

The inventory before the copy

I would write down what the old server actually is:

  • Operating system, kernel, packages, and versions.
  • Application runtime: PHP, Node, Python, Docker, n8n, WordPress, database.
  • Files: uploads, plugins/themes, model weights, binary data, logs.
  • Database: engine, version, size, users, and a consistent dump procedure.
  • Scheduled work: cron, systemd timers, queues, workers.
  • Secrets: environment files, n8n encryption key, API keys, TLS certificates.
  • Network: DNS records, TTL, mail records, webhooks, firewall rules, open ports.
  • Recovery: the current backup, the last restore test, and who can access it.

The Contabo setup guide covers the new-server side. The n8n export guide and WordPress backups guide cover the application-specific exports.

Build the new server first

I would order the new Contabo VPS with the same or a slightly larger shape, choose the same OS family, and record the panel details. I would not reuse the old server's IP or hostname during the build.

On the new box:

  1. Create the users, SSH keys, and firewall rules.
  2. Install the same runtime versions.
  3. Restore the application files and database.
  4. Import the secrets and the n8n encryption key, if applicable.
  5. Start the app on a temporary hostname or the new IP.
  6. Test the app, the database, the file paths, the scheduled jobs, and the mail path.

A snapshot before the first production change gives a rollback point. Auto Backup is a separate daily layer; it does not replace the pre-change snapshot or the off-server export.

Test before the DNS cutover

I would test the new box without moving production traffic:

  • Point a local hosts file or a temporary DNS name at the new IP.
  • Verify the site or workflow over HTTPS, including redirects and cookies.
  • Send a test webhook and confirm the callback URL.
  • Run a scheduled job and check the logs.
  • Send a test mail and confirm the transport; a successful send is not inbox delivery.
  • Restore one file from the backup to prove the backup is readable.

If the app depends on an external callback allowlist, add the new IP or hostname before the cutover. If it depends on a license tied to the IP or hostname, check the vendor's transfer process.

Synchronize the final writes

For a live WordPress or n8n instance, the first copy is not the last. Before the cutover I would put the application into a short read-only or maintenance window, stop the old cron and queue workers, run a final database dump and file sync, and record which database is authoritative. If the old site keeps taking orders or the old worker keeps executing, the new copy starts behind, and the rollback copy may be the more recent one. Decide the authoritative side before changing DNS, and do not run the same scheduled job on both servers.

Cut over DNS and callbacks

Lower the DNS TTL at least a day before the move, then change the A/AAAA records to the new IP. Keep the old server running. Watch:

  • HTTP/HTTPS and redirects.
  • Webhooks and OAuth callbacks.
  • Mail (SPF/DKIM/DMARC, PTR if the VPS sends directly).
  • Cron and queue workers.
  • Error rates and latency.
  • The old server's logs for traffic that has not moved.

DNS is cached in places you do not control. A low TTL helps, but it is not an instant switch. I would keep both servers alive through at least one full TTL window and a business cycle.

Keep the rollback until the exit is clean

The old server is the rollback. I would not cancel it until:

  • The new server has run through a full business cycle.
  • The DNS and callbacks have settled.
  • The new backups have been tested.
  • The old data has an independent copy.
  • The cancellation notice and billing period are understood.

Contabo's billing and cancellation guide covers the panel and the notice period. A cancellation is not a data export; export first, then cancel. If the old host is not Contabo, its cancellation rules are separate.

What I would not do

  • I would not cancel the old server before the new one answers.
  • I would not copy a live database file without a consistent dump.
  • I would not move DNS before testing the new IP.
  • I would not assume a snapshot is an off-site backup.
  • I would not migrate an n8n instance without its encryption key and credentials.
  • I would not treat a successful page load as a full migration test.

The cutover checklist

On the cutover day, I would keep a short go/no-go list: the new box answers on its own IP; the app, database, and files are from the same point in time; the webhook and OAuth callbacks use the new hostname; mail sends through the intended relay; the backup restore has been tested; the old server is still running; and the DNS TTL has expired for the traffic I care about. If any line is missing, I would delay the DNS change rather than fix it in production.

What this does not decide

This article does not perform a migration, does not provide distribution-specific commands, and does not test a Contabo restore. It gives the order and the checkpoints. The actual commands depend on the old and new stacks.

Contabo dedicated servers. If a workload has outgrown a VPS, Contabo also sells dedicated servers. The current offer is Contabo: Powerful Dedicated Server Dual Xeon.

Affiliate link: AiXVPS may earn a commission if you buy through it, at no extra cost to you. Affiliate disclosure.

Sources