Plan before replacing files
Review the target release, exact version entitlement and supplied upgrade or migration instructions. An initial purchase and update rights are separate: permission to use an existing version does not grant every future version.
Take a complete backup and test the procedure on a restricted copy. Record the current version and host requirements. The fresh installer is not an upgrade tool.
Keep signed code intact
Commercial release archives include an immutable publisher-signed inventory and bundled production dependencies. Do not edit guarded PHP files, run Composer, regenerate autoload files or run Node builds inside the signed installation. Restore the exact matching release bytes if integrity verification fails.
Older UI or source guides can describe partial core updates or executable plugin ZIP installation. Those code-changing actions are disabled in signed customer distributions. They are not a supported route around a complete reviewed release upgrade. Existing data and permitted non-code settings remain installation-owned.
Verify after the change
Preserve config/app.php, the application key, private storage and external licence identity according to the release procedure. Check owner and limited-user access, template snapshots, projects/cases, attachments, cron and email. Verify private-directory denial rules and the genuine licence status before returning the workspace to normal use.
If no upgrade procedure has been supplied for the versions involved, obtain one before altering an installation containing real work.