A Website and Application Migration Checklist

Prepare dependencies, destination tests, data consistency and rollback before changing production traffic.

Before you begin

Identify the source and destination owners, access approval contacts and the person who can validate the business application. Collect software versions, licences, data sizes and a dependency map. Agree a secure method for exchanging access after scope review.

Work through the checklist

1. Build the dependency inventory. List files, databases, workers, scheduled jobs, DNS, certificates, email senders and external integrations. Include licences that are tied to a machine, address or vendor activation.
2. Check destination compatibility. Confirm operating-system, runtime and database versions with the developer or software vendor. Review resources, storage working space and required outbound connectivity.
3. Protect the source. Agree a usable backup or export and the recovery procedure before changes. Verify that somebody can access it and knows how to restore the relevant application data.
4. Choose the transfer method. Determine how files and databases move, which records can change during transfer and how final writes are handled. A database export and a file copy may need a coordinated point in time.
5. Test business workflows. Validate sign-in, forms, uploads, mail delivery, payments or reports as applicable. Record results and unresolved issues with the application owner.
6. Approve cutover and rollback. Agree the traffic-change window, acceptance decision and rollback conditions. Keep the source available for the agreed transition period, then remove it through an authorised process.

Make acceptance observable

Choose tests that match actual business use. A server responding to a request proves less than an order, upload or report completing correctly. Define who performs each check and who may approve the final move. Include external integrations and scheduled tasks that may not run during a quick visual check. Record the outcome so later troubleshooting can distinguish a migration issue from a new application change.

Handle data changes deliberately

When users continue writing data during a move, source and destination can diverge. Decide whether the application needs a maintenance period, a final synchronisation or another application-supported approach. This decision depends on the software and transfer tools. Discuss interruption openly. A generic migration service does not promise a free move, instant completion or zero downtime.

Example and limits

A business site with uploads and a database may need an initial transfer, destination tests and a final consistent data transfer before DNS changes. The actual method depends on the application. This checklist is a planning record, not an executable migration command or a guarantee of timing.

Document the next action

Record the decisions, the person authorised to approve changes and the evidence used to validate the result. Keep passwords, private keys and confidential business data out of planning notes shared through an initial enquiry. Revisit the record when the application, access requirements or commercial agreement changes.