Application handover.
Plan the change.

What else must work with the application?

Describe the current environment: operating system, application and database versions, file locations, scheduled jobs, queues and integrations. Include licensing requirements and a secure access handover method. WordPress, a Windows application and a custom system have different dependencies; one file-copy list will not cover all of them.

• Who maintains the code, operating system, database and supplier connections?
• Who controls DNS and approves the change? It may be the client or a separate provider.
• Which existing problems and unsupported versions are known?

Start with a controlled copy.

Check the application in the target environment using agreed data. Restrict access and disconnect actions affecting customers. Compare important functions with the existing service. A trial start should expose missing modules, permissions and configuration before cutover.

Illustrative example: files and the database have moved, but reports are missing because the overnight job still runs only on the old server. A manual sign-in test will not expose this. Acceptance checks must include background work.

How do you avoid two diverging data states?

Agree when writes will stop, the final synchronisation will run and users will move to the new environment. Record who authorises cutover and which tests support the decision. Do not promise uninterrupted service before dependencies and synchronisation have been checked.

Returning to previous files does not necessarily restore current data. If the new environment accepted orders or changed the database structure, agree how to preserve those changes and ensure compatibility before rollback. Define stop conditions and the period in which a return remains possible.

When is the handover complete?

After cutover, check actual availability and agreed processes. Confirm that alerts reach the right person, backups cover the new environment and recovery procedures are understood. Record the scope of minor fixes, separately quoted changes and developer support.

Retire the old environment after acceptance and a decision on what must be retained. The outcome is transferred responsibility, documentation and a list of open matters. A working website address alone does not prove that the whole system has been handed over.

Sources and next step

These sources describe mechanisms and good practices. They do not confirm your company’s configuration or compliance. The examples in this guide are illustrative.

• Plesk Obsidian: Backing Up and Restoring Websites
• NIST SP 800-34 Rev. 1: Contingency Planning Guide

To apply these questions to your business, explore the related service. A description of your situation is enough for an initial discussion; do not send passwords or confidential data through the form.