Context
Several sites on one Plesk server can depend on different PHP capabilities. A global version change may help one application while breaking another site's extension or scheduled task. Treat each subscription as a separate compatibility decision, even when the underlying server is shared.
Record the current execution paths
Inventory each site's PHP version, handler, enabled extensions and application requirements. Include command-line tasks, workers and scheduled jobs because they may use a different executable from web requests. Record who owns the application and who can approve its compatibility result. Check the supported combinations for the installed Plesk release and operating system instead of copying settings from a different host. Retain enough information to explain why a particular site has not yet moved.
Test the application against the target runtime
Create a representative test environment and exercise the workflows most likely to reveal compatibility issues. Include file uploads, authentication, checkout or reporting as applicable. Review extension and dependency support using their own release information. A homepage rendering successfully is not sufficient evidence for a complex application. Compare warnings and errors before and after the change without publishing sensitive diagnostics on a public page. Ask the application maintainer to resolve code issues rather than masking them through permanent error suppression.
Plan the switch and reversal decision
Back up the relevant application and configuration through the established recovery process. Agree when the runtime switch will happen and who will validate the result. Confirm which rollback options remain supported after any dependency or database changes. A runtime toggle alone may not reverse an application migration. Prepare a clear way to pause further site changes when the pilot reveals a shared hosting issue. Keep users informed if the maintenance window affects an important operation.
Verify web and background behavior
After the switch, repeat application checks through the actual public route and run the approved scheduled-task tests. Observe logs and resource consumption through a meaningful business period. Update the runtime inventory and remove obsolete exceptions only after their owners confirm the result. Plesk makes runtime management accessible, but the control panel cannot establish that every custom application is compatible. The completed change should include a tested site-specific result and an operational owner for any remaining compatibility work.
Discuss the environment, constraints and acceptance criteria with Clouvenix plesk administration specialists before scheduling production changes.
Technical reference
Official platform documentation. Confirm options, support status and operational behavior for the installed release. The workflow above is an engineering review approach, not a universal configuration recipe.