Encore

Transferring

Give an Encore its project: convert the one the game already runs in, or move the game into a new one — and what a move costs your players.

An Encore needs a project of its own, because that project is what players fund and what stops when they stop. A transfer gives it one, in one of two ways.

Mode	What happens	Addresses and names
Convert (`MODE_CONVERT`)	The project the game already runs in becomes the Encore project. Nothing moves.	Nothing changes.
Move (`MODE_MOVE`)	A new project is created, and each resource you choose is moved into it.	Game server addresses and resource names change.

Convert whenever you can. It is always the better outcome for players, and a plan recommends it whenever it is possible.

A transfer can start before verification finishes. Players cannot fund the project until the Encore is verified, but nothing stops you getting the game ready.

A transfer is started from the console or the CLI rather than Terraform: it can rename resources your other configuration manages.

From the moment a transfer finishes, the project spends only its own balance, and that balance starts at zero. Anything running in it goes to sleep shortly afterwards, and nothing starts again until the project has credit — from a player's purchase, or from you. If the servers must stay up across the switch, top the project up as soon as the transfer completes.

1. Plan

Encore → your Encore → Transfer → choose the project the game runs in

A plan changes nothing. It lists everything the source project holds, in every region, as candidates:

Field	Meaning
`type`	e.g. `playpute.plany.cloud/GameServer`
`belongs_to_game`	Found through the game itself — a server or group running it, a secret one of those servers uses.
`client_facing`	A shipped game client may address it — a game server or a group.
`movable`	Whether Encore can move this type. A resource that cannot be moved is still listed, with a `note` saying why.

and says which mode it recommends, in recommended_mode and explanation, with anything you should know first in warnings.

When a plan recommends converting

Only when nothing in the project is somebody else's: every game server, group and schematic in it belongs to this game, and nothing in it is of a kind Encore cannot move.

A plan recommends moving instead when:

the project holds game servers, groups or schematics for another game;
it holds a sandbox, which a transfer does not move; or
any part of the project could not be listed at that moment. Converting is a claim that the project holds nothing but the game, so a plan never makes it without having seen everything. Plan again a little later and it may change.

2. Convert

Encore → your Encore → Transfer → choose the project → Convert project

A conversion takes a fresh plan at the moment you start it — not the one you read earlier — and is refused with CANNOT_CONVERT unless that plan still recommends it. Something added to the project since you planned is exactly what that check is for.

If the plan carries warnings, acknowledge_warnings must be true (the CLI's --acknowledge-warnings) or the call is refused with WARNINGS_NOT_ACKNOWLEDGED.

A conversion completes at once. The operation it returns is already done, and the Encore's project is set.

3. Move

Encore → your Encore → Transfer → choose the project → tick what moves → Move N resources

Nothing moves unless you name it. belongs_to_game pre-selects what the plan found through the game; the list you send is the decision. Acknowledging the warnings is always required for a move.

What a move costs your players

Every move plan carries these warnings, and they are the reason converting is better:

Game servers get a new address›

A server's address belongs to its project. A moved server is reached at an address in the new project, so players must be told the new one — a server browser entry, a pinned IP in a Discord, a hard-coded host in a launcher all stop working.

Names in shipped clients stop resolving›

Every resource on Plany has its project in its name. A game client that addresses a moved resource by its old name stops reaching it. For a game nobody will patch again, that is permanent.

A sleeping server's first start is a full start›

A moved server keeps its disk — its world, saves and mods — but its first start in the new project takes as long as a fresh start rather than resuming in seconds.

Terraform will show the resources as deleted›

The old names are gone. For each moved resource, terraform state rm the old address and terraform import the new name, or the next plan will try to recreate what already moved.

What moves, and how

Resources move in order, and each step waits for the one before it, so a reference is always rewritten to something that has already arrived.

Order	Resource	How it moves
1	Secrets (`secretmanager.plany.cloud/Secret`)	Copied, with every version. The original keeps answering servers still in the source, and is deleted at the end once nothing references it.
2	Schematics (`playpute.plany.cloud/GameServerSchematic`)	Re-registered under the new project.
3	Autoscaling groups (`playpute.plany.cloud/GameServerGroup`)	Re-created with the same id and policy, starting from the group's schematic; the source group is drained and deleted. Members move with their group, never on their own.
4	Game servers (`playpute.plany.cloud/GameServer`)	Stopped, re-created in the new project with the same id, settings, pinned build, runtime and disk, started again if it was running, and the source deleted.

A running game server is stopped to be moved, so players on it are disconnected and can rejoin once it is back — at its new address.

What does not move

Resource	Why
Sandboxes	A transfer does not move them. A project holding one cannot be converted.
A group's member on its own	It moves with its group.

Anything left behind stays in the source project and goes on spending your ordinary account credit.

The new project is named projects/encore-<encore id> (shortened to fit), displayed as "<name> (Encore)", and the source project's IAM bindings are copied to it, so the people who ran the game run its Encore project.

Following a move

A move runs in the background, a step at a time. The operation's metadata is the Transfer, and the Encore carries the same object when read.

plany encore transfer status example-arena

The project switches to spending only its own balance last, after every item has moved. Until then the servers being moved bill your account as they always have, so an empty project balance never interrupts the move meant to fund it.

When an item needs your acknowledgement

A stopped server whose disk cannot be copied — the machine it was on was lost — can only move as a fresh install. That item waits in STATE_NEEDS_ACKNOWLEDGEMENT, and so does everything after it, until you accept it:

Encore → your Encore → Transfer → Move as a fresh install

The server is then re-created from its build, with its settings but without whatever was on its disk — the world, the saves, the installed mods.

When an item fails

An item that fails in a way retrying cannot change fails the transfer, with the reason in transfer.message. Nothing is rolled back: resources that already moved stay in the new project, which keeps drawing on your account credit, and everything not yet moved stays where it was. Items that fail only briefly — a moment of unavailability — are retried rather than failing anything.

After a transfer

The Encore's project is set, and players can fund it once the Encore is verified.
The project spends only its own credit, and its servers sleep at zero. See Funding.
It is one-way. An Encore project cannot be turned back into an ordinary one, because its balance may hold credit players paid for.
The Encore can no longer be deleted. It is what explains a project players paid into.

A second transfer is refused with ALREADY_TRANSFERRED once the Encore has a project, and with TRANSFER_RUNNING while one is in progress.

Who can do what

Starting a transfer needs encore.transfers.start on the Encore and project.projects.update on the source project, because it changes what that project spends. roles/account.owner and roles/account.admin hold the first; roles/account.billing deliberately does not — moving a game's infrastructure is not a decision about money.