Moving your Minecraft server to a new version without losing the world

A new Minecraft release lands, or the mod you want exists for one version only, and the question is always the same: can the server move without taking the world into the bin with it. On uniz.host it can, and the copy is made for you before anything is touched. What follows is what the machinery does, in what order, and which direction ends in a server that will not start.

Nothing is applied the moment you press the button

The control lives in the Version and software section of the Version and performance group on that server's Settings tab. Pick the new software or version, then press Change version: that opens a confirmation rather than doing anything. The important sentence is printed both under the selects and at the foot of that confirmation — a safety backup runs first, and the change applies only after it succeeds.

Sending the request does exactly two things: it launches a full backup of the server's data folder, and it stamps the change as pending. Nothing about the version or the software has moved yet. You get a confirmation that the backup started, the section grows a banner saying the change will apply automatically once the backup completes, and the change button stays disabled while that banner is up, so a second request cannot stack on the first.

Minutes later a background loop notices the backup job finished and settles the request:

That is the whole safety story: the only path to a changed version runs through a backup that provably exists. It also survives you closing the tab — the request is settled server-side, not by the page you were looking at.

The safety backup does not spend your manual allowance

The backup taken here is filed as an automatic backup, and the limit that stops you piling up backups counts manual ones only — so a version change never costs you a slot. It does join the automatic pool, which is trimmed to the newest few whenever an automatic backup completes, three by default. A pre-change snapshot you want to keep for weeks should be taken manually as well.

One difference by edition. A running Java server can be backed up live: it is told to flush the world and pause autosaving for the length of the copy, and autosaving comes back on when the job settles, so nobody is kicked. Bedrock has no live backup path, so a running Bedrock server's version request is refused until you stop it.

Change the version, step by step

Open the Version and performance group on the Settings tab

On a Minecraft server's Settings tab, choose the Version and performance group. Its first section is Version and software: the Current line shows the software and the version pinned today, with an Update available marker when your software has published something newer than your pin. You need the settings permission — the owner has it, a team member needs it granted.

Pick the target version, the software, or both

The version list is fetched per software, from that project's own build catalogue, so you can only pick a version your software actually publishes a build for. Above the concrete versions sits LATEST (auto-update).

The Software select appears for Java servers on the thirteen switchable builds. Bedrock has no software axis at all — only a version field. Switching software re-checks your pinned version against the new software's catalogue and moves you to its newest build if that software never made your version.

Decide whether to restart after the change is applied

A checkbox under the two selects offers to restart once the change lands, and it is pre-ticked when the server is running. Leave it ticked and the change is live as soon as the backup settles. Untick it and the change is stored while the running pod keeps the old version until its next restart. On a stopped server it changes nothing: the new version is what boots next time you start it.

Press Change version and read every warning the confirmation shows you

Change version stays disabled until you have picked something different. Pressing it opens a confirmation with one line saying what changes to what, such as Paper 1.21.4 → Paper 1.21.5. Under it are the red boxes: every one names a real failure mode, and more than one can appear at once. The next three sections walk through them.

Confirm and watch for the backup banner

The confirmation's own Change version button stays disabled until every acknowledgement in view is ticked. After you confirm, the banner in the Version and software section is your progress indicator; when it clears, the Current line shows the new software and version.

Downgrading is the direction that breaks worlds

Going up is routine. Going down is the one that ends with a server that will not boot, and the dialog says it plainly: Minecraft cannot load worlds saved by a newer version, so the server will not start until you change back or restore the backup. There is no repair, no converter, no fixing it from the console — the world file is simply newer than the game reading it.

The dialog raises this warning whenever it can prove the target sits below your current pin in the same catalogue, and a softer version of it whenever the direction cannot be proven either way — your server is on LATEST, your pinned version has been dropped from the catalogue being compared against, or you switched to software whose newest build predates your current version. That softer wording is the platform refusing to guess about your world, not the platform being vague. If you are downgrading on purpose — because a mod you need never got updated — do it knowing the return trip is the backup, and take a manual one first.

Switching software family clears the mods you installed

Server software falls into families: plugins (Paper, Purpur, Leaf, Folia, Spigot, Bukkit), Fabric (Fabric, Quilt), and Forge (Forge, NeoForge, and the hybrids). Plain vanilla belongs to no family, so moving into it counts as leaving whichever one you were in.

Moving inside a family keeps your installed list. Crossing between families cannot, because a plugin cannot load on a mod loader and a mod cannot load on a plugin server — the files are for different software entirely. So the change clears the installed list as part of applying, and while you have file-installed mods the request will not be accepted until you tick the acknowledgement that says they will be removed. The family warning appears whenever you cross; the acknowledgement only when there is something to lose. Write down what you had installed before you cross — the list is cleared, not archived somewhere you can read it back.

Latest versus pinning a version

LATEST (auto-update) is stored as a sentinel, not as a number, and the newest published build for your software is resolved when the server starts. Two things follow. A LATEST server never shows the update marker, because it cannot be behind. And an ordinary restart — including one you did for an unrelated reason — can move it onto a release that landed yesterday. That is fine on a vanilla server and a genuine hazard on a modded one, because mods are built against specific versions and a new major release routinely leaves them behind for weeks.

A pinned server compares itself against its own software's catalogue and shows the update marker when that software has published something newer — but only while the catalogue still lists your pin, so a pin old enough to have been pruned stays quiet rather than nagging. As of 2026-08-14 the newest Minecraft Java release is 26.2, and Mojang's own manifest is what the picker's vanilla list is derived from.

The Java runtime pin survives the change

If you have ever set the Java runtime field (the Java section of the same group) by hand, it stays exactly where you put it across a version change. This is the trap that produces a server crash-looping on Java too old for the version it just moved to — the newest releases require Java 25, so a server pinned to java8 for a 1.12-era pack will not boot on them.

The dialog checks this against the version and software you are moving to, and shows a separate warning naming your pinned runtime, with its own acknowledgement to tick. It is a warning rather than a block: nothing stops the change, and the Java runtime field is never disabled by server state, precisely so you can climb out afterwards. Setting that field back to Auto is the fix in almost every case — the full picture is in the Java runtime guide.

Requests the platform will not accept

Some combinations are refused outright rather than warned about:

If the new version will not boot

Work down this list rather than restarting and hoping:

1. Read the console. A world too new for the game and a Java too old for it fail in visibly different ways, and the first lines after the boot attempt usually name which.
2. Check the Java runtime field in the Java section of the Version and performance group. If it is anything but Auto, set it back to Auto and start again — that field is editable even while the server is crash-looping.
3. Change the version back. Going up to where you were is the fastest recovery from a downgrade, and it takes its own safety backup on the way.
4. Restore from the Backups tab. The safety backup the change took is sitting there, and restoring it returns the world to its pre-change state — at the cost of everything built since.

Read next

• The Java runtime guide — which Java each version needs, and how Auto picks it
• Server properties — the server's other settings on the Settings tab
• Gamerules — the settings that live in the world file, not in our database
• Running a Minecraft server yourself — the same job without a panel