# A dedicated-server migration runbook that protects the data

> Rehearse the move, establish a consistent data boundary and define what rollback means after the new system accepts writes.

Canonical human page: https://swissoctet.com/insights/dedicated-server-migration-runbook/

SwissOctet Editorial. Topic: dedicated. Level: Applied. Reading time: 6 minutes.

## Direct answer
Prepare and test the new server first, copy data with an application-supported consistency method, define a cutover window and preserve the old environment. Rollback must account for writes accepted on the new server, not only a DNS change.

## Inventory the service before moving the machine
A migration includes more than the application files. List databases, uploads, scheduled jobs, queue workers, certificates, domains, secrets and outbound integrations. Record software versions and the operating assumptions that matter, such as file permissions and storage paths. A fresh dedicated server may expose a forgotten dependency that was quietly installed years earlier on the old environment.

Assign an owner for the cutover decision and define what success looks like. Include user-visible checks, data consistency and the ability to recover access. Confirm that the new configuration is delivered and usable before announcing a migration date. An order confirmation or a listed hardware specification is not the same as a working destination ready to receive production data.

## Build the destination as a separate environment
Install the required stack, establish administration and configure the intended firewall. Keep secrets private and set service permissions deliberately. Verify the application's expected hostname and certificate behaviour before public traffic moves. Apache's virtual-host documentation illustrates why hostname routing is a separate configuration decision from the server's address. A working default page does not prove that the correct application host is configured.

Use a representative restored dataset for rehearsal, with outgoing email, payments and scheduled jobs disabled or redirected to safe test systems. This prevents the test environment from acting on real users. Exercise login, uploads, background work and restoration. Record the procedure and its duration so the real window is based on an observed process rather than optimism.

## Choose a consistent data boundary
Use a backup or replication method supported by the database and application. PostgreSQL distinguishes SQL dumps, file-system backups and continuous archiving, each with its own assumptions. Its dump guidance notes that database dumps can be internally consistent while cluster-wide roles and other details need separate handling. Read the requirements for the exact system you run rather than copying open data files indiscriminately.

Plan how the database relates to uploads and queue state. If a record points to a file that was copied at a different time, the restored application can be incomplete even when both copies succeeded individually. Decide whether to pause writes briefly, use a tested replication arrangement or perform an application-specific export. Keep that consistency decision explicit in the runbook.

| Stage | Evidence required | Decision |
| --- | --- | --- |
| Rehearsal | Application and restored data pass checks | Destination can be considered for cutover |
| Final synchronisation | Defined consistent recovery point | Proceed only with understood remaining changes |
| Traffic switch | Correct routing and certificate behaviour | Monitor both destinations |
| Rollback | Location of all newly accepted writes | Reconcile data before returning traffic |

## Prepare traffic routing without promising instant changes
DNS time-to-live controls how long records may be cached, as explained in Cloudflare's DNS documentation. Review the TTL early if DNS is part of the migration, and allow existing cached records to age under their previous setting. Changing the value at the moment of cutover cannot retroactively shorten every cached answer. Different clients may reach different destinations during the transition.

Keep the old environment available while routing changes settle, with a deliberate policy for whether it can still accept writes. Avoid running duplicate queue consumers or scheduled jobs unless the application is designed for it. Monitor requests at both sides and confirm the intended hostname, TLS certificate and application version from independent clients.

## Define rollback after writes begin
Before the new system accepts changes, returning traffic may be relatively simple. Afterwards, a DNS reversal alone can lose work or create two conflicting histories. Define how newly created records and uploads would be preserved or reconciled. If the application cannot safely merge them, a controlled maintenance period may be preferable to an improvised return to the old copy.

Set the conditions that require pausing the migration, and keep the decision owner reachable. Preserve logs and useful evidence under the project's retention rules. Do not delete the old machine or its independent recovery copy merely because the home page loaded once. The retention period should cover the agreed verification and rollback needs.

## Close the migration with operational checks
After cutover, verify backups, alerts, certificate renewal, scheduled work and access recovery. Confirm that the monitored host is the new destination and that no test integrations remain in production. Review application errors and user-visible timings under ordinary traffic. Update the inventory and runbook so the next administrator does not have to infer what changed.

SwissOctet's dedicated families offer different physical configurations, but migration work and managed assistance must be confirmed for the chosen service. Use the catalogue to select suitable resources, then build a tested move around your application's data. A migration is complete when the service and its recovery process work on the destination, not simply when files have been transferred.

## Checklist
- Inventory data, jobs, secrets and integrations.
- Verify the delivered destination before scheduling.
- Rehearse with safe external integrations.
- Define database and upload consistency.
- Plan routing transition and duplicate-job prevention.
- Specify rollback for new writes.
- Verify backups and monitoring after cutover.

## Frequently asked questions
### Can I migrate by copying the application directory?
Only if that captures everything the service needs and preserves consistency. Databases, uploads, jobs, secrets and configuration usually require separate attention.

### Does lowering DNS TTL make cutover instant?
No. Previously cached answers can remain until their earlier lifetime ends, and clients may update at different times.

### Is rollback just pointing DNS at the old server?
Not after the new server accepts writes. You must account for those records and files before returning traffic.

## Primary sources
- [PostgreSQL: Backup and Restore](https://www.postgresql.org/docs/current/backup.html)
- [PostgreSQL: SQL Dump consistency and restoration](https://www.postgresql.org/docs/current/backup-dump.html)
- [Apache: Virtual Host documentation](https://httpd.apache.org/docs/2.4/vhosts/)
- [Cloudflare DNS: Time to Live](https://developers.cloudflare.com/dns/manage-dns-records/reference/ttl/)

## Related infrastructure
- [Metal Atlas](https://swissoctet.com/services/metal-atlas/index.txt): Dedicated compute with more memory and storage headroom for established workloads.
- [Metal Zenith](https://swissoctet.com/services/metal-zenith/index.txt): A step up in dedicated infrastructure for workloads that demand substantial resources.
- [Metal EPYC](https://swissoctet.com/services/metal-epyc/index.txt): AMD-powered dedicated hardware for parallel workloads and serious compute.

## Related guides
- [VPS or dedicated: choose the boundary that fits](https://swissoctet.com/insights/vps-or-dedicated-server/index.txt): Understand what a physical machine changes, what it does not change, and when it becomes a useful step for your workload.
- [Build a GPU VRAM budget before choosing hardware](https://swissoctet.com/insights/gpu-vram-budget-for-real-workloads/index.txt): Account for weights, activations, caches and temporary buffers, then test the peak workload rather than the model file alone.
- [Build a backup you can actually restore](https://swissoctet.com/insights/build-a-backup-you-can-restore/index.txt): Choose a recovery target, protect an independent copy and practise the restoration before an incident forces the issue.