Plan an ARK Ascended cluster without risking character transfers

An ARK: Survival Ascended cluster is more than two servers displaying the same name. Transfer discovery, supported map builds, shared transfer data and consistent restrictions must all agree. Plan it with support before moving a valued character; a visible destination is not proof that downloading will succeed.

Confirm what the hosting setup supports

List the participating server IDs, maps, builds, mods and intended transfer rules. Ask CloudExa ~~help~~whether ~~guide.~~those installations can use a supported shared transfer-data location. Separate game-server file areas are isolated by design. This guide does not imply that the panel supplies shared storage or that customers can mount another server’s files themselves.

The configuration reference documents a common -clusterid and -ClusterDirOverride for cluster data. These are launch options, not ordinary INI entries. The exact path must be valid and accessible inside each running server’s environment. A Windows executable under a Linux compatibility layer may see paths differently from the host. Have support confirm the arrangement instead of copying a host path into every startup field.

Keep transfer data separate from map saves

A shared cluster directory holds transfer state. It is not permission to share or merge entire map-save directories. Each map must retain its own world and related player and tribe files. File-copy jobs that overwrite one map with another can damage ownership or create inconsistent character state.

Use a distinct cluster identifier and review upload and download restrictions together. Agree whether characters, items and creatures are allowed in each direction. Check that participating releases and required mods support the intended route. A common identifier cannot convert Survival Evolved saves into Ascended saves or make missing content available.

Run a disposable transfer test

Announce maintenance and take coordinated, stopped checkpoints of all participating map saves and existing transfer data.
Record the restrictions and relevant launch options before changing anything. Keep the checkpoint outside the shared working directory.
Use a disposable test character with expendable items. Verify the destination appears, the transfer completes, and the character can join and play.
Test the return direction independently. Check expected inventory, ownership and creature behaviour rather than assuming a successful connection proves all transfer types.
Only open transfers to ordinary players after documenting the supported route and recovery procedure.

Respond to a failed transfer

Stop repeated uploads and downloads while investigating. Record source, destination, time, character identifier and the last successful step. Preserve both servers’ current saves and transfer state before another attempt. Restoring just one server while other cluster members continue accepting transfers can duplicate or lose state. Ask support to coordinate recovery across the affected maps rather than restoring a single character file at random.

Set a clear maintenance rule for the cluster: nobody transfers while a member is being restored or updated. Resume only after a second disposable test confirms the final arrangement. That rule matters as much as the initial configuration.