EzePanel · Plesk migration
Guided planning
Translate a Plesk subscription into an explicit hosting plan.
Review subscription ownership, sites, database engines and mail before moving to an EzePanel Linux environment. Resolve compatibility questions before the first cutover.
Plan the transferCheck the platform as well as the subscription
Inventory subscription sites, system users, PHP handlers, document roots, database engines, mail services and scheduled tasks. Identify extensions or application services outside ordinary PHP/MySQL hosting.
A Windows, IIS, ASP.NET or Microsoft SQL workload is not automatically compatible with an EzePanel Linux/PHP/MySQL target. Resolve the application migration separately before promising an equivalent hosting environment.
Resolve compatibility before provisioning
Separate workloads that fit the intended Linux/PHP/MySQL target from applications requiring another platform or service. Create EzePanel accounts and owned domains only after the destination ownership, document roots, PHP requirements and capacity are agreed.
The current product provides the destination hosting tools. A dedicated Plesk archive importer or one-click account transfer is not currently provided; broader migration tooling is Planned.
Move application data in a supported format
Preserve the source subscription recovery copy. Move eligible website files and usable SQL exports separately; create the destination database/user and update the application configuration. A different database engine requires an application-specific conversion plan.
Preserve the source copy and inspect the import result. The EzePanel SQL import accepts .sql/.sql.gz within its upload limits; it is not a full control-panel archive importer or a guarantee of atomic rollback.
Rebuild subscription services explicitly
Translate the required domains, mail identities, DNS records, SSL coverage and scheduled tasks into the destination account structure. Review each Plesk extension or integration separately; a subscription archive does not configure an equivalent EzePanel service.
Do not assume portable password hashes, mail filters, forwarding rules, certificates or account paths. Reissue or install eligible SSL through the supported target process and verify coverage. Keep external registrar and DNS authority clear.
Use the shared cutover checklist.
Verify the target application and services, agree final synchronization, then change traffic with a recovery decision already prepared. Retain the source until preservation and recovery requirements are satisfied.
Verification, cutover and rollback guidanceCommon questions
Before you move hosting.
Can I upload a Plesk full backup and migrate automatically?
No automatic full-account importer is presented here. This is guided planning using verified EzePanel destination tools and operator-managed transfers.
Will all passwords and mail settings transfer unchanged?
Do not assume that. Recreate or migrate each credential and mail setting through an agreed supported method, and verify the result.
Can I guarantee a migration without downtime?
No. The required consistency window, DNS behavior, application and services determine the plan. Agree the operational impact before cutover.
What if I need to return to the old server?
Keep the source and recovery copies available. Review writes made after cutover before redirecting traffic; a DNS change does not reconcile data automatically.
Discuss the scope before the move.
Outline the source platform, workloads and destination requirements. Confirm the transfer approach before committing to a cutover.