A server migration checklist for business websites and applications

Inventory everything the application needs to run

List the runtime, database, uploaded files, scheduled jobs and external services the application relies on. Include environment configuration and any separate worker processes. A directory copied successfully to a new server may still be missing the conditions the application needs to run.

Identify the owner of DNS, the hosting account and any email services connected to the domain. Confirm authorized access before selecting a migration window. An otherwise ready move can stall because the person making the change cannot update a record or obtain a required credential.

Separate persistent data from replaceable code

Know which information changes while the application is running. Database records, uploaded files and queued work may need a different migration method from a versioned code release. Plan how those changes are captured during the cutover.

For a Docker-based application, include its persistent volumes in the inventory. Docker's documentation explains that volumes hold data outside a container's lifecycle. Copying or replacing the image alone does not move that data.

Docker documentation on persistent volumes.

Validate the destination before directing customers to it

Check the new environment through a controlled preview or other suitable test route. Verify key pages, account access, file uploads and the business actions that matter. Make sure test activity does not send duplicate customer notifications or process live transactions.

Compare the old and new configuration item by item. A missing scheduled task may not be obvious from the homepage, and an incorrect callback URL may affect only one integration. Work through the inventory instead of relying on a quick look at the site.

Define the cutover and rollback decisions

Name the person who performs each step, the expected validation and the conditions that would stop the move. Decide how to handle writes to the old system while the data syncs. Some applications need a short maintenance period to avoid conflicting records.

Rollback requires more than retaining the old server. If customers have created records on the new environment, moving back may require reconciliation. Agree the point at which rollback becomes a data decision and identify who is authorized to make it.

Check DNS, certificates and background work after release

After the switch, verify the public domain, HTTPS, important forms and integration callbacks. Check background tasks and queues as well as interactive pages. Record the final configuration so later support does not depend on someone remembering the migration window.

Keep the old environment available for the agreed verification period, and control who can access it and write to it. Do not remove the only recovery copy because the homepage loads from the new server. Set the retirement date in the plan.

Document the new operating arrangement

Record who pays the provider, who receives alerts, what is backed up and where operational instructions live. Confirm that obsolete access can be removed without locking out the business. Include the next maintenance or recovery review where relevant.

Wasevo scopes migrations around the application's dependencies and business impact. We do not assume zero downtime. Our proposed method explains any interruption and the checks that show the move is complete.