close
close
ABOUT US AFFIALITES CONTACT US LOGIN CLIENT AREA
menu
We also take care of providing excellent support 24/7 at no additional cost.

BLOGS

Dedicated Server Migration Checklist for a Safer Cutover

09.30.2026

Move an application between servers with an inventory, tested data copy, controlled cutover and a rollback plan that protects new customer activity.

A server migration is a sequence of controlled changes. The riskiest period is often the overlap when the old and new environments can both accept writes. Plan ownership of customer activity before copying files or changing DNS.

Inventory the complete service

Record application versions, database engines, scheduled jobs, background workers, uploads, DNS records, certificates and external integrations. Include less visible dependencies such as outbound IP allowlists, webhook endpoints and mail delivery settings. An application can load its homepage while an essential background function remains broken.

Prepare and test the destination

Create the new environment using compatible software and restrictive access. Test it through a temporary hostname or controlled local resolution. Verify login, file access, database reads and the specific business workflows your customers use. Keep payment capture, live customer email and duplicate scheduled jobs disabled during rehearsals.

Plan the final data synchronization

For a small system, a documented maintenance window may be easier to validate than a complex replication scheme. Larger applications may need replication or a carefully designed write transition. Either way, define when writes stop on the old system, how the final changes reach the destination, and when the new system becomes authoritative.

DNS changes do not instantly move every client. Existing caches and long-running connections can continue using the old address. If changing DNS time-to-live values, do so early enough for the previous values to expire. Keep the transition compatible with clients that reach either endpoint.

Make rollback a data plan

Returning DNS to the old server is not a complete rollback after customers have written new data to the destination. Decide how those writes would be retained or reconciled. Identify explicit rollback triggers, the responsible operator and the point after which rollback requires a different procedure.

Close the migration deliberately

  • Check errors, response times, queued jobs and successful customer actions.
  • Confirm backups are running on the new environment.
  • Update monitoring, documentation and access controls.
  • Retain the old environment for the agreed recovery period before decommissioning it.

When selecting a replacement dedicated server, include the migration window and temporary overlap in your capacity and budget planning.