Windrose World Island ID Mismatch and FTP Binary Transfer Fix

Windrose World Island ID Mismatch and FTP Binary Transfer Fix

Moving a Windrose world from one host to another is one of the most common operational tasks after the April 14, 2026 Early Access launch. Players start a world on a local client, fall in love with their crew's progress, and then decide they want a persistent dedicated server so nobody has to be online to host. Or they rent a server from one provider, discover it is underpowered, and want to move to a better one. Or they run on a panel and want to move between regions. All of those scenarios share the same surprising failure mode: the world looks like it has been copied correctly, the server starts, the invite code gets issued, but the world either refuses to load or loads as a brand-new empty island where there should be hours of progression.

There are two distinct technical reasons for this, and nobody who has not seen both will guess them on their own. The first is a World Island ID mismatch caused by the save folder, ServerDescription.json, and WorldDescription.json pointing to different IDs. The second is FTP ASCII-mode corruption caused by certain FTP clients auto-detecting Windrose's save files as text and silently changing line endings on the way up. This guide walks through both issues, explains how to diagnose them without risking more damage, and documents the migration procedure that works reliably on Early Access Windrose.

Why this class of failure is so common

Windrose worlds are represented on disk as a tree of files under a world-specific folder, with two JSON descriptors that glue the pieces together. When the server boots, it looks at its top-level ServerDescription.json for a World Island ID, then looks into the corresponding folder under Worlds, then reads WorldDescription.json inside that folder. All three pieces are supposed to match. If any one of them drifts, the server either fails to load the world or loads the wrong one. The symptoms look exactly like save corruption, but no bytes are actually broken — just the pointers between them.

A second problem layer lives in the transfer itself. Several popular FTP clients, including default-configured FileZilla, still auto-detect file types based on extension. Windrose saves contain JSON and non-JSON binary blobs in the same tree. When FileZilla decides a JSON file is text and switches to ASCII mode, it can rewrite CRLF sequences and break checksums the server expects. The server sees the world folder, reads the JSON, and either rejects the save or silently replaces it with a new empty one.

Windrose save file layout you need to know

Windrose stores world data in slightly different trees depending on whether you are on a client save or a dedicated-server save.

The three points you must verify on a dedicated-server migration:

1. The islandId field inside ServerDescription.json.
2. The folder name inside Worlds\ (this must match the islandId exactly).
3. The islandId field inside Worlds\<islandId>\WorldDescription.json.

If these three do not match, the server cannot find the world you think it is loading.

How the mismatch happens in practice

It is surprisingly easy to produce a mismatch without meaning to. Here are the most common ways:

• You rename the world folder by hand to something more readable like our-crew-island, breaking its agreement with the JSON files.
• You migrate two worlds simultaneously and one ServerDescription.json overwrites another, but the folders were copied independently.
• A panel creates a stub world at first boot, generating a new islandId, and you then paste the old world folder on top without updating the JSON.
• You restore from a backup that was taken at a different point in time from the JSON you have now.
• You copy only part of the tree. A common version is copying Worlds\ but forgetting to bring ServerDescription.json too.

All of these produce a working-looking server that either ignores your real world or loads a fresh empty one.

Diagnosing the mismatch

You can confirm whether a mismatch is your problem in under a minute. With the server stopped, open each file in a plain text editor and compare:

1. Open ServerDescription.json. Find the islandId value.
2. List the Worlds\ folder. Note every subfolder name.
3. Open Worlds\<islandId>\WorldDescription.json. Find its islandId value.

All three must be identical strings. If the islandId in ServerDescription.json refers to a folder that does not exist, the server has no world to load. If the folder exists but its inner JSON has a different islandId, the server either refuses to bind or treats it as a stranger world.

Fixing the mismatch

The fix is conceptually simple and requires only discipline:

1. Stop the server.
2. Decide which of the three islandId values is the one you want to keep. Usually this is the one inside Worlds\<folder>\WorldDescription.json, because that is the value tied to the real world data.
3. Rename the Worlds\ subfolder if necessary so the folder name matches the WorldDescription.json value.
4. Update the islandId in ServerDescription.json to match.
5. Double-check all three match exactly (character for character — IDs often contain dashes and are case-sensitive).
6. Start the server and confirm the world loads with the expected progress.

When you do this right, the server comes back with your crew's world in the state it was in at the time of the backup. Nothing dramatic needs to happen after that.

Why FTP mode matters

Now the second layer: the wire-level transfer itself. Certain FTP clients, notably default-configured FileZilla, use an auto-detect mode that decides each file's transfer type based on its extension. For text-like files it switches to ASCII mode, which rewrites line endings from LF to CRLF on upload. For a typical text file this is harmless. For a game save that is part JSON and part binary, this is destructive.

The official Windrose FAQ is unambiguous about this. It specifically warns that "certain FTP clients may transfer files incorrectly or incompletely" and recommends using WinSCP or Cyberduck in Binary transfer mode. The practical upshot is that you should never trust auto-detection for a save migration. If you are using FileZilla, change the default transfer type to Binary before you touch anything.

How to force Binary mode

Each client has a different setting. Here are the important ones:

• FileZilla: Edit → Settings → Transfers → File Types. Change "Default transfer type" from "Auto" to "Binary." Apply before any new transfer.
• WinSCP: Tools → Preferences → Transfer. Confirm the active transfer preset uses Binary. The built-in default preset is usually fine if unchanged.
• Cyberduck: Preferences → Transfers. Set "Transfer files in binary mode" and disable any ASCII auto-detect.
• Command-line FTP: run binary before any get or put.
• SFTP/SCP via OpenSSH: SFTP always transfers in binary and is not affected by this class of problem. Prefer SFTP when available.

If you have the option, SFTP is strictly safer than FTP for Windrose save migrations. It is not vulnerable to the ASCII-mode issue and is usually better protected in transit.

A safe migration procedure

Combining both layers, a safe Windrose world migration looks like this:

1. Stop the source server cleanly. Do not kill the process uncleanly.
2. Take a local snapshot of the entire R5\Saved tree. Keep this snapshot untouched as your rollback point.
3. Transfer the tree to your workstation in Binary mode via SFTP or WinSCP. Verify the byte counts match on both ends.
4. On the destination server, stop any running process. If the panel auto-started a fresh world, stop it before you upload anything.
5. Upload the tree in Binary mode. Confirm byte counts match again.
6. Open both JSON files and verify the three islandId values match.
7. Start the destination server.
8. Join with one test account first. Confirm your character, your world state, and your progression are intact.
9. Only then invite the rest of the crew in.

Each of these steps exists because someone, somewhere, skipped it and ended up with a silently broken world. The extra few minutes spent on byte counts and ID verification pays for itself many times over.

Special cases

A few variations deserve mentioning:

• Moving from local client save to dedicated server: the source tree lives under AppData\Local\R5\Saved\SaveProfiles, not the dedicated server's R5\Saved. You may need to unpack the relevant world folder and craft a matching ServerDescription.json. Read Save Transfer and Recovery before starting.
• Moving between third-party hosts: if a provider insists on "importing" a world through their own tooling, verify afterwards that the IDs are consistent. Some importers create a new world and you lose progression in the translation.
• Restoring a mid-session backup: Windrose may not always accept a mid-flight backup cleanly, especially if an in-progress event changed the save while you copied it. Prefer snapshots taken with the server stopped.

Logging and self-checks that help

A simple shell one-liner can verify the three islandId values match without opening the files manually. On a Windows server with PowerShell:

Select-String -Path .\R5\Saved\ServerDescription.json -Pattern 'islandId'
Get-ChildItem .\R5\Saved\Worlds | ForEach-Object { $_.Name }
Select-String -Path .\R5\Saved\Worlds\*\WorldDescription.json -Pattern 'islandId'

All three outputs should reference the same ID string. Keep this snippet handy; it pays off during any migration.

When to cut your losses

If you have performed a migration and the world loads but is missing large amounts of data, stop immediately. Do not keep playing or making edits. Instead:

1. Shut the server down.
2. Restore from your pre-migration snapshot.
3. Start again from step one of the safe procedure above.
4. If the problem recurs, compare file sizes and timestamps between source and destination to isolate where the loss is happening.

Continuing to play in a partially broken world overwrites the very pointers you would need to recover cleanly. The cost of half an hour of rollback is much smaller than the cost of days of lost crew progression.

Decision table

Sources

• Official Windrose FAQ
• Official Windrose Dedicated Server Guide
• LOW.MS: Windrose Server Troubleshooting
• AllThings.how: How to Fix "Server Not Found" in Windrose
• PCGamingWiki: Windrose