Preparing a server migration: a practical checklist

Build an inventory of dependencies

List applications, versions, databases, services, paths, users and permissions. Include DNS, certificates, external IP allowlists and integrations. Assign a technical and a business contact to each application. They answer different questions: whether a service runs and whether its output is correct for everyday work.

Check the explicit scope of any migration tool. Plesk, for example, documents which content Migrator transfers and which server settings it leaves behind. A completed copy is therefore not proof that the whole operating environment has moved. Compare the tool's coverage with your own inventory.

Keep related data consistent

An application may store records in a database and associated files in the filesystem. Copying these at different times can leave missing attachments or references at the destination. Identify related data and choose a product-supported method for obtaining a consistent set. Pausing writes may form part of that method.

Database exports also have prerequisites. PostgreSQL's documentation highlights required roles and permissions when restoring an SQL dump. Check versions, extensions, encoding and errors at the destination. An export file is not a substitute for a successful import followed by an application test.

Example: test a complete order workflow

For a shop, test the entire order process. Test product search, the basket, sign-in, checkout in the intended test mode, order confirmation and transfer to inventory management. Prevent real payments and messages to customers. Record the expected result and the person accepting each step.

During rehearsal, measure copying, database import and verification time. Use those measurements to set a realistic maintenance window. If the rehearsal already exceeds the acceptable interruption, revise the process before the actual move. Allow for downtime unless the rehearsal confirms that the application can move without interruption.

Maintenance-window checklist

• Record approval, contact availability, start time and the latest rollback decision time.
• Pause scheduled jobs, queues and writes according to the agreed procedure.
• Transfer the final data set and verify successful processing from logs.
• Switch access paths and test from the networks people actually use.
• Obtain business acceptance and restart background jobs and integrations in a controlled order.
• Document errors, decisions and actual timestamps in the migration record.

Rollback means more than reverting DNS

Once the new system accepts changes, the data sets diverge. Simply switching back can lose those changes. Define who decides on rollback, when it requires additional data transfer and which system may accept writes during that process. A shop also needs to account for payments already initiated or messages already sent.

Hand over ongoing operations

Verify backups, monitoring, certificate renewal and recurring tasks on the destination. Test recovery from a backup produced by the new system. Retire the old system after acceptance and the agreed rollback period. Then document ongoing responsibilities and remove access that is no longer needed.