A new Minecraft release looks exciting until the server starts and a plugin refuses to load. Most painful upgrades are not about the download itself. They are about everything attached to it.
Treat an upgrade as a small migration. Know what you run today, test what you want to run next, and keep a route back.
Don't upgrade production first.
Check support for your server software, plugins, mods, Java runtime and world data. Back up everything. Rehearse the upgrade on a test instance, validate player data, then schedule the production change and monitor logs.
Minecraft Java Edition server administrationWrite down your existing stack
Record the current Minecraft version, server implementation, Java version, plugin or mod list, proxies and any client-side requirements. The release number alone does not tell you whether an add-on is compatible.
For a published modpack, follow its supplied server pack and instructions instead of assembling versions independently. Not every loader supports every Minecraft release immediately.
Confirm compatibility before downloading
Read release notes for Paper, Fabric, Forge or NeoForge as appropriate, then check your essential add-ons. Pay particular attention to world management, permissions, economy, authentication and network proxy plugins.
For any required Java runtime change, use the version documented for your server software. Avoid assuming the newest runtime is correct for an older server.
Rehearse on a copy, not your real world
Make a complete backup and clone the server to an isolated test environment. Upgrade the clone first. Watch the console for startup warnings, data migration steps and failing add-ons.
Join with a compatible client, check inventories and dimensions, teleport to established builds and verify permissions and common commands. Test with representative players before scheduling downtime.
Update with a rollback plan
Tell players the planned maintenance window and required client version. Stop the production instance, take one final backup and apply the tested change.
If something fails, restore the verified backup and matching previous software rather than opening an already-upgraded world in older software. A rollback means restoring data too, not simply replacing a jar file.
A couple more questions
Can I downgrade my world if I dislike the update?
Downgrading world data may corrupt or remove content. Restore a pre-upgrade backup using the matching prior software instead.
Should I update all mods at once?
For a modpack, use the pack author's tested versions. For a custom setup, validate dependencies and changes on a test server before production.
Sources & useful links
The technical details behind this guide, if you want to dig further.