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.
Your practical 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.
The details that matter.
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.
Go to the source.
These references support the technical concepts in this guide. Follow the current documentation before changing a production system.
- PostgreSQL: Backup and Restore www.postgresql.org
- PostgreSQL: SQL Dump consistency and restoration www.postgresql.org
- Apache: Virtual Host documentation httpd.apache.org
- Cloudflare DNS: Time to Live developers.cloudflare.com
Editorial guidance by SwissOctet. Examples are illustrative. Service specifications, available options and contractual conditions must be verified separately.