I agree this should have been a MAJOR 5.0 release for one and this should have either been held back until there was a real need for it, or 4.0 should have been held back for Debian 12 Support. We do 3 year server contracts, and it’s just unacceptable to be having to add another server a year later just to do it all over again.
The Script has been already released. It is listed in a previous answer.
1 Like
Check the solution post!
The script has issues as others have reported it not working properly and the server failing to work after the upgrade with no solution but to re-install. Unless the script is made fool-proof then it’s not a good way to trust upgrading production systems without a spare server ready to go.
1 Like
We updated the script a couple of days ago. When did you try?
Anything that needs the warning “can be used in production systems at your own risk” is not a solution. It needs to be 100% full proof and supported!
We understand your concern about the need for solutions to be reliable and foolproof, especially in production environments.
It’s important to highlight that no migration method(manual or automated) is completely risk-free. Even official sources, like Debian’s documentation, emphasize the importance of taking precautions, such as creating full backups before performing system upgrades. This is because unexpected issues, such as hardware failures during migration, can lead to complications.
When we mention “can be used in production systems at your own risk,” it is to stress the necessity of taking preventive steps, such as thorough testing in a staging environment and creating backups, to safeguard your data and configurations. While we strive to ensure our tools are robust and reliable, we cannot account for every unique scenario or unforeseen issue that might arise in a specific environment.
I hope VitalPBX will consider using the LTS version of the OS so that next time we can have a few years before needing a major upgrade.
1 Like