Switch Rust Hosts: Check Export Access Before Signing Up

To switch a Rust hosting provider without losing your world, verify the source export and destination import as one decision before paying for a new plan or canceling the old one. Rust keeps world, player, configuration, framework, and Rust+ data in separate places, and the next host may not accept every file or entitlement. This checklist helps you get written answers from both providers, budget enough overlap for acceptance, and keep a rollback path. It covers PC Rust and pre-signing checks; the actual file transfer and cutover are a separate operation.

If the plan changes and you decide to stop instead of switching, use the separate Rust hosting cancellation checklist to confirm billing, final access, and deletion timing.

Decide what must survive the Rust host switch#

Write down the exact player experience and server state you are trying to preserve. “Keep the server” can mean the world and bases, learned blueprints, plugin economy, admin roles, Rust+ notifications, or all of them. Each can depend on different files or provider features.

Facepunch’s Rust server-file reference maps common identity contents: the .sav file stores map data and entities such as buildings and deployables; blueprint and other player data use separate files; the map file is separate; and companion.id identifies the server to Rust+. Database files can have SQLite write-ahead log companions. Do not treat one .sav as a complete server export. Use Facepunch’s server file reference as your starting inventory, then ask the source host to confirm its current export set.

State to preserve	What to ask about	Evidence to keep
World and map	Which identity and world files are included? Is this a procedural or custom map?	File inventory, map name/seed/size, and a dated source export record
Players and blueprints	Which current database files and related WAL files are included?	Provider’s written scope and a destination check for representative player state
Configuration and access	Are settings, admin lists, bans, and server identity included or recreated separately?	Redacted config copies and a list of values the destination expects
Framework and plugins	Which framework/version and plugin data can the destination support?	Plugin list, versions, data folders, and license-holder terms where relevant
Rust+	How is `companion.id` protected and handled during the move?	Provider answer and a Rust+ re-pair/connectivity acceptance check
Other custom data	Are custom maps, signs, images, or service-specific files part of the service?	A named owner and explicit export/import answer for each item

The table is an inventory prompt, not a claim that every file should be copied blindly. If you use the wrong identity, miss a database companion, or target an incompatible save version, the server may create a fresh world while your old progress remains in an unused folder. Keep the inventory tied to the exact active server.identity, not an old test server. For safe Rust data classification and recovery details, use the server data management checklist.

Record the source server before you sign#

Ask the current provider for its export method while you still have account access. Find out whether you can download files yourself, whether support must prepare an archive, which service path is used, and whether the download remains available after cancellation. Ask for the exact deadline and any fee. A panel icon called “backup” does not tell you whether it contains the active identity or lets you take it away.

Record a compact source profile before comparing the destination:

Current Rust server build or protocol, and when it last updated.
The active server.identity, map type, world size, seed, and custom map URL if used.
Framework name and version, plugin names and versions, plus the directories that hold their data.
Which blueprints, player states, server settings, admin roles, bans, and custom assets the group expects to keep.
Source export format, download route, file size estimate if available, and last date the source can be accessed.

Do not email passwords, RCON secrets, Steam account credentials, or a raw companion.id file to collect these answers. Ask each provider how to share a protected export for a permitted evaluation, and limit access to people who need it. If support cannot name the identity or files it will provide, treat that answer as unresolved rather than assuming a full account export includes the Rust server data.

Get the destination’s import requirements in writing#

Give the prospective provider your redacted source profile and ask what it will accept before ordering. The exact identity folder, save files, framework layer, and panel import process can vary by provider. Request the destination’s current supported server build and whether it can load your current map save and separate player data on that build.

Ask the destination to confirm each of these points:

Question	A useful answer names
Where does the export go?	The exact account feature, support process, or documented file transfer it accepts
What must match?	Active identity, map settings, seed or custom-map source, and save/protocol expectations
What about framework data?	Supported Oxide/uMod or Carbon version, plugin files/data scope, and who reinstalls dependencies
Can you test first?	A staging or isolated import path, what it changes, and who verifies it
What if it fails?	Restore point, overwrite behavior, provider responsibility, and access to the original export
What is outside the service?	Files or paid content the provider will not transfer or support

Save the replies with dates and the plan name. “We support Rust” is not an import specification. If the new host can accept only a fresh identity, a framework is missing, or the target build cannot load the source state, pause before paying. Ask for a supported conversion path or choose a different destination; do not resolve uncertainty by renaming files or forcing an old save onto a new build.

Protect Rust+ identity and plugin rights#

Rust+ makes a host move more than a folder copy. Facepunch says companion.id is the server’s unique Rust+ identifier, should stay with the server and its backups, and must not be used on multiple servers. It also warns not to give the file to someone else or delete it casually. That means a test copy must not accidentally run beside production with the same companion identity, and a provider should explain how it handles this sensitive file. Keep it out of public tickets and screenshots.

Ask how the endpoint, TCP reachability, and Rust+ pairing will be checked after the move. A changed IP or panel-managed port may need attention; do not assume old mobile pairings or notifications will continue. Facepunch’s Rust+ server documentation lists the current connection checks and settings. Confirm a test path that respects its identity rules.

Plugins and custom maps have their own owners and terms. Do not assume a hosting transfer grants a plugin license, gives the next provider permission to access paid files, or makes every framework interchangeable. Record whether you can export plugin configuration and data, who reinstalls the framework, and whether each creator permits the intended use on the destination. If a license or service term is unclear, ask its owner before including the item in the move.

Budget enough overlap to verify both hosts#

A migration can involve more than two monthly charges. Add the new plan’s first payment, any migration or setup labor, the days both accounts must remain open, and any required location, storage, or plugin fees. Then check the source provider’s export deadline and cancellation terms. The lowest new monthly price can become an expensive choice if your only export path expires before you can validate it.

Use a simple time budget with named owners:

Checkpoint	Owner	Deadline or proof
Export request and source access confirmed	Source account holder	Written response, route, and last access date
Destination requirements answered	New provider	File/build/framework compatibility and test procedure
Recoverable source copy secured	Server administrator	Inventory and recovery point stored outside the old account
Test window and support coverage booked	Group organizer	Both providers can be reached during the window
Acceptance decision recorded	Two group members	World, player state, admin access, plugins, and player connection checked
Cancellation allowed	Account holder	Only after acceptance and rollback criteria are satisfied

Ask whether the destination offers a trial or staging account; do not assume that it does. Keep the original host available long enough to compare the imported state, but agree with both providers on when each Rust process must be stopped. Players should know which server is authoritative during the handoff. A migration window that permits people to keep playing on both copies can split progress and create a confusing rollback.

If the move changes the recurring bill, separate migration costs from ongoing charges using the Rust server hosting cost worksheet. It helps you compare the money; it does not prove that the destination can load your world.

Set acceptance and rollback rules before authorizing the move#

Before approving the order, agree on what counts as “the server made it across.” A successful upload or a green panel status is only one signal. Facepunch notes that save and player data live in separate files, so verify the outcomes your players care about rather than checking only that one world file exists.

Keep a recovery point independent of both accounts
Confirm who creates the final source copy, where it is stored, and who can restore it. Keep it separate from the provider accounts being changed so an account closure does not remove the only recovery path.
Use an agreed isolated test path
Have the destination explain how it will test imported files without letting a duplicate production identity serve players. Record the expected build, map, identity, framework, and any excluded Rust+ file for staging. If no safe test is available, require a written rollback plan before ordering.
Check the state the group expects to keep
Agree on checks for the correct world and player-built structures, blueprints or player data, administrator access, plugin configuration/data, and custom content. The person responsible should compare the result with the source inventory and save evidence without exposing credentials.
Verify actual player access before cancellation
When it is safe to make the destination authoritative, have a group member connect with the intended PC Rust client and confirm the route, expected world, and Rust+ behavior if used. Do not cancel the source while a required check is still unresolved.

A step that cannot be tested needs an owner and a deadline; it should not silently become “passed.” If the destination opens a new empty identity, loses an expected blueprint, cannot load the chosen framework, or fails Rust+ checks, stop the cutover and return to the agreed source/backup plan. Once the checklist passes, follow the Rust server migration runbook for the staged handoff and single-writer cutover.

Make the host-switch decision from evidence#

Use this go/no-go record before signing or setting a cancellation date:

Decision gate	Go only when…	Stop when…
Source export	You know the exact data, access route, owner, and last available date	The provider cannot confirm what leaves the account or when
Destination acceptance	The provider confirms build, identity, files, framework, and test path	Compatibility is only an assumption based on the word “Rust”
Rights and identity	Rust+, plugins, custom maps, and credentials each have a safe, permitted plan	A unique identifier would be copied to concurrent servers or a license is unclear
Recovery	A verified copy and rollback owner exist outside the old account	The only copy remains inside an account scheduled for cancellation
Timing and cost	Overlap, support, fees, and cancellation notice fit the plan	You would lose access before the destination can be checked

Keep the record with the source profile, both providers’ dated answers, and a contact who can stop the move. If one gate is still open, delay the purchase or cancellation and ask the provider for a concrete answer. For broader plan selection, use the Rust hosting comparison checklist; it compares workload, recovery, administration, regions, and recurring terms across providers.

If a managed Rust PC host fits after these checks, we recommend Game Hosting’s Rust plans with an integrated panel and free backups. Confirm export and import requirements, then verify the transferred world before ending the old service. Rust Console Edition is separate and cannot join a PC server.

Quick answers

Can I move a Rust server without starting over?

Often, if the source can provide the required data and the destination can load the matching identity, files, and supported build. Confirm both sides in writing and test the imported world before you cancel the source.

How do I migrate a Rust server to another host?

First verify export access, compatible destination requirements, and a safe acceptance plan. The actual copy and cutover depend on the providers and belong after those checks.

Should I cancel the old Rust host before testing the new one?

No. Keep a verified recovery copy and source access until the destination passes the checks you agreed on with the provider.

Will Rust+ still recognize my server after a host change?

Facepunch identifies companion.id as a unique server identity and warns against using one file on multiple servers. Ask how each provider will protect and handle it, then verify Rust+ after the cutover.