Updating a modded server without losing the world

Updating a modded server is not like updating a vanilla one. A vanilla update is a jar swap and a world-format migration that the game handles. A modded update is thirty independent projects that each have to agree, and a world file that contains data only some of them understand.

The failure is not that it does not start. The failure is that it starts, runs, and has silently removed everything one missing mod was responsible for.

The world remembers mods that are gone

When a mod adds blocks or items, the world stores references to them. Remove the mod and those references have nothing to resolve to.

What happens next depends on the loader and the version, and none of the outcomes are good: the blocks vanish, or they become air, or the chunk fails to load and the server drops it. A player's base built around a mod's machinery becomes a hole.

This is the single most important fact about modded servers and it is why "just remove the broken mod" is rarely the quick fix it appears to be.

Update the whole set or none of it

Mods target a specific loader version and a specific game version. Updating one mod to a build compiled against a newer loader produces a server that refuses to start, if you are lucky, or one that starts and crashes on a specific interaction, if you are not.

So the unit of update is the modpack, not the mod. Move everything together, to a set of versions somebody has actually run together, which in practice means following a pack's own release rather than assembling your own combination and hoping.

The crash you get from a mismatched set is also unusually hard to read: the stack trace names the mod that failed rather than the one that broke it, which sends people to the wrong author. Finding the real cause is the first-error-not-the-last discipline applied to a boot log with forty entries.

If you do assemble your own, you are the person testing that combination, and you should behave accordingly.

The order that actually works

1. Stop the server cleanly. Not a kill. The world has to finish writing, because you are about to make a copy of it.
2. Copy everything, off the machine. World, configs, mods folder, at the current versions. This is the rollback, and it is the only one — see backups that leave the building.
3. Update on a copy first. Start the new version against a duplicate of the world. Not the real one.
4. Look at it. Load the spawn, load somebody's base, check that the machinery is still there and still functions. A server that starts is not a server that survived.
5. Then do it for real, using the same steps on the live copy.

Step three is the one people skip because it feels redundant. It is the entire safety net.

Config files get rewritten

Many mods regenerate their config on first run with a new version, merging defaults over what is there. Sometimes that preserves your settings. Sometimes it resets a value you tuned six months ago and never wrote down.

Copy the config directory before updating and diff it afterwards. The changes are usually small and occasionally include something that matters — a spawn rate, a permission, a world-generation flag that is about to affect every new chunk.

Tell people first, and keep them out

A modded update is a maintenance window, not a restart. It takes as long as it takes, and having players connect midway through is how a half-migrated world gets written.

Announce it, set a start time, and take the server off the listing or into whitelist for the duration. Then say when it is done. The community-management half of this matters as much as the technical half, and it is the same discipline as any other planned outage.

When a mod is abandoned

At some point one mod in the set will have no update for the new game version, and the choice is to stay behind or to drop it.

Staying behind is a real option and frequently the right one. A modded server on a stable version with a community that is happy is not obliged to chase releases, and the cost of chasing is exactly this process, repeatedly.

Dropping it means accepting that everything it added leaves the world. If that mod is decorative, fine. If it is the storage system everybody's base is built around, the honest answer is that the server has a decision to make rather than an update to run, and it is worth making that decision openly rather than discovering it mid-migration, for the same reason a plugin list is a liability you should count before it grows.