The attributes behind your decision
- Decision input
- Measured workload
- Primary variables
- Capacity, control, operations
- Validation
- Representative testing
- Next step
- Swiss infrastructure
Inventory dependencies and define success
Record domains, applications, databases, storage, scheduled jobs, certificates, mail flows, integrations and firewall rules. Define acceptable data loss and downtime before selecting the migration method.
Prepare and validate the destination
Provision the target resources, patch the operating system, restrict access and restore a representative copy. Test application behavior, permissions, background jobs, outbound mail and monitoring without changing production DNS.
Synchronize data and control the cutover
Lower DNS TTL in advance when appropriate. Freeze or replicate writes, perform the final synchronization, verify checksums or row counts and then direct traffic to the new service. Keep the former environment available during the agreed rollback window.
Verify, observe and document rollback
Test public and administrative paths from more than one network. Watch errors, latency, queues and resource saturation. Roll back when predefined thresholds fail; otherwise document the new backup and recovery procedure.
Use a staged cutover with an explicit rollback trigger
Create the destination environment first and test the application through a staging hostname. Copy the initial data, then rehearse the final synchronization. For a writable database, define when writes pause and how the last changes reach the destination. File copying alone may not create a consistent database backup.
Set a rollback trigger such as failed checkout, database errors or unavailable critical endpoints. Keep the old environment available during verification, but avoid accepting conflicting writes in two locations. After the cutover, check DNS, TLS, email delivery, background jobs, logs and backup jobs before retiring the old host.