How to schedule the upgrade window for the first beta version of Joomla 6.3 at the end of November, while still in the 5.4 site upgrade window
The first test version of Joomla 6.3 is scheduled for November 24, 2026, and sites still on 5.4 should schedule the upgrade window within the security support tail area, and complete a full upgrade drill before entering the tail. According to the official roadmap, routine defect fixes for 5.4 stopped on October 13, 2026, and security support will end on October 12, 2027; the official version of 6.3 is scheduled for April 13, 2027.
What hard dates did the official roadmap provide?
The value of the roadmap lies in the fact that it provides promised dates rather than guesses, which can be reversed accordingly:
| Node | Date | The significance of the 5.4 site |
|---|---|---|
| Routine defect repair stops for 5.4 | 2026-10-13 | There will no longer be patches for non-security issues |
| 6.3 First Alpha | 2026-11-24 | For developers to verify compatibility, not suitable for production |
| 6.3 Beta 1 | 2027-02-16 | The interface is becoming stable, can be used for upgrade drills |
| 6.3 Official Version | 2027-04-13 | Available upgrade target for production |
| End of security support for 5.4 | 2027-10-12 | Hard cutoff, no patches after this |
What does the security fix phase mean
Enter the phase of fixing only security issues, patching channel narrows: functional defects and compatibility issues are no longer backported, point releases are scheduled as needed, only critical security vulnerabilities will trigger new versions. The actual impact on site operations is that both types of risks rise simultaneously.
One type is business-side risk. The template or extension in the current version may cause display errors or interface exceptions, and official repairs cannot be awaited, only manual intervention or changing the extension can be done. Another type is time-side risk. Security patches will continue to be released, but the release window has a clear endpoint, and the closer it gets to the endpoint, the more likely it is to appear 'vulnerabilities are publicly disclosed, and fixes only exist in update versions' gaps. Therefore, the security phase alone is not a reason to delay, but a signal to schedule windows.
Four checkpoints for scheduling the upgrade window
The first is the test environment. Use a copy of the production data for practice, without trying it directly on the official site. The second is backup. Backup and recovery need to cover the database and static files, freeze a snapshot before the upgrade, recover as a whole in case of problems, which is the premise of rollback. The third is compatibility with extensions and templates. Check individually whether the extensions in use support the target version, whether the templates need to be rewritten, and the compatibility list determines whether the upgrade is a smooth migration or a reconstruction job. The fourth is the rollback plan. Clarify the recovery steps and verification methods, actually perform a rollback during the exercise, and confirm that the plan is available rather than just written on paper.
It is recommended to allocate time: at least six months should be left before the end of security support to complete the full process from rehearsal to formal upgrade, and unexpected compatibility issues should be handled in stages with room for maneuvering.
The follow-up work outside the upgrade action.
After the version upgrade is completed, the tail end of the credential side is easy to be overlooked. AnQiCMS has fixed two high-risk issues caused by SQL injection in list sorting parameters and the possibility of forging login credentials when switching site, in v3.6.6. The official upgrade recommendation is to also rotate the site signature key and change the administrator password; this action applies to all content systems—the assumption outside the patch is that the old key may have been exposed since the vulnerability can be used to forge credentials. The Joomla site should also reset the background password and key configuration after the upgrade.
Common questions
Question: Can we follow up directly when the first test version is released?Answer: Not recommended. Alpha is aimed at developers for compatibility verification, and interfaces and data structures may continue to change. The benefits of following up on the production site are far lower than the risks.
Question: Can we still receive security patches for 5.4, and is it okay to upgrade closer to the deadline?Answer: Yes, but the margin is very thin. Upgrading often involves template and extension rework, and the rework is compressed in the last two months. Once incompatible, there is no way back.
Question: How do I decide whether to upgrade to 6.2 or wait for 6.3?Answer: Considering the support for extensions and site changes. If the current stable version meets business needs, upgrade according to the stable version, and treat the migration of major versions as a separate project schedule, rather than just doing it by chance.