This procedure requires authorized administrative access to both servers and a supported source platform. Check the current migration prerequisites, operating-system direction, destination capacity, PHP and database versions, mail-server compatibility and network access. Keep independent backups and define the maximum acceptable data loss, downtime and recovery path.

1. Inventory domains, files, databases, mailboxes, scheduled tasks, certificates and external dependencies. Record authoritative DNS and current TTLs. Lower relevant TTLs ahead of the cutover when appropriate, allowing the earlier TTL to expire first.
2. Install or open Plesk Migrator on the destination and start a migration using the supported source type and connection method. Limit temporary administrative access to what the migration requires and protect credentials.
3. Select only the intended subscriptions and review destination owner, plan, address and database mappings. Run pre-migration checks and resolve blocking issues before transferring data.
4. Perform the initial transfer while retaining the source. Read per-subscription warnings and run post-migration checks. A completed transfer does not prove the application behaves correctly on a different runtime.
5. Preview the destination without moving public traffic. Test the application using its real hostname through a controlled local mapping or supported preview, including login, uploads, scheduled processing and mail. Ensure tests do not send duplicate production messages or payments.
6. Plan a final synchronization window. Pause writes and background workers where needed, then resynchronize the required content using the supported migration controls. Confirm what each selected re-sync will overwrite.
7. Switch authoritative DNS or the relevant traffic route deliberately. A migration tool DNS action only covers the topology it supports; external DNS and registrar delegation may require separate changes. Enable destination jobs once and prevent the source from continuing duplicate business processing.
8. Monitor both servers during the transition and retain the source for the agreed recovery period. Remove temporary migration credentials and access only after verification and evidence retention are complete.

No. Keep it protected until traffic, data and recovery checks are complete. Retention does not mean allowing the old application to continue accepting independent writes. Document which server is authoritative during each phase and who can approve final retirement.

Check the public destination from independent networks, compare important database records and mailboxes, and test critical business actions. Confirm certificates, mail routing, backups, monitoring and scheduled jobs operate on the destination. Record unresolved warnings with an owner and a concrete next action.

If cutover fails, decide whether returning traffic to the source is still safe after destination writes began. A simple DNS reversal can split new transactions between servers. Preserve both states and reconcile data before reopening service. For unsupported components, use an explicit application or mailbox migration procedure rather than assuming Migrator copies every extension and server customization.

• Completing a final mail sync during a Plesk migration
• Knowing when Plesk DNS changes control public records
• Restoring one Plesk database without replacing the whole subscription
• Creating and downloading a full subscription backup in Plesk

• Plesk: Migrating Via The Plesk Interface
• Plesk: Advanced Migration Mode