Migrate from Sandbox to Production

Sandbox and production are fully separate environments: separate content, separate internal IDs, separate webhooks and keys. Nothing moves automatically — you build the hub in sandbox, then migrate the configuration to production yourself using the tools below.

The one rule that makes migration painless: entities reference each other by internal IDs, and internal IDs are always different between environments. What survives the move are the keys you control — item SKU, store key, page and article slug, price template and reward keys. The migration tooling re-links everything by these keys.

Stage 1 — Prepare your hub in sandbox

Switch to the sandbox environment using the environment selector in the top-right corner of the dashboard (it stays locked until the initial AI content generation finishes).

Both environments are created with the same AI-generated demo content: a default store, demo items, sample news, leaderboards with test participants. In sandbox, archive or delete this seed first, then build your real catalog and hub on a clean slate — don't reshape demo entities into real ones.

warning

Archiving does not free an entity's SKU or key. Production holds the same demo seed, and the transfer matches objects by key including archived ones — so a real item that shares a SKU with a demo item will collide with it in production. Assign your own SKUs and keys; never reuse ones from the demo seed.

Everything you configure in sandbox uses test data only: no real players, no live payments (see Test payments).

Stage 2 — Migrate to production

Before transferring: archive the production starter content

Production still holds its untouched demo seed, and the transfer never removes anything — it only creates and updates by key. Archive the seed before transferring, all of it, so demo content and migrated content don't end up mixed in one catalog. Catalog entities (items, bundles, lootboxes, subscriptions) and campaigns support archiving; demo news, leaderboards and daily rewards can only be deleted — delete them. Keyed system entities you can't remove (the default store, system pages) are safe: the transfer overwrites them with your sandbox versions.

Three ways to move content

Method	Covers	Notes
Transfer tool — the Transfer button on entity lists in the dashboard	Items (SKUs), bundles, lootboxes, subscriptions, stores and store contents, offers, store promotions, daily rewards, loyalty program, progression programs, campaigns, website (theme, pages, leaderboards, achievements), website promos, news	Re-maps internal IDs by SKU/key automatically. Virtual currencies and other dependencies travel along with the items that use them
File export / import (Google Sheets or XLSX; translations: Sheets or JSON)	Glossary, translations, price templates, coupons, creators	Export from sandbox → import into production. Import applies immediately — only creator import supports a validation dry-run. Stores and store contents can be exported to a file, but not imported back: use the Transfer tool for them
Configure fresh in the dashboard	Webhooks, API keys, Aghanim Connect connectors, custom domain	Environment-specific by design — see below

How the Transfer tool works

Run it from sandbox. Open the entity list in your sandbox environment, select the rows, click Transfer, and choose the production game as the destination.
It transfers your selection, not the whole list — a page shows up to 100 entries, so a large catalog takes several passes.
Dependencies come along automatically. Nested bundle items, lootbox drop tables, fallback items, virtual currencies referenced by prices — all pulled in and re-linked by SKU. If a referenced item can't be resolved in the destination, the transfer reports an error for that object instead of creating it broken.
Review the preview. Every transfer shows a diff before applying. Use the exclude object types selector to protect entities you've already fine-tuned in production from being overwritten on repeat runs.
It's repeatable. The transfer is an upsert by key — running it again is the normal way to top up changes, not a risk.
Partial failures are safe. Objects that failed are listed in the result; fix the cause and run the transfer again.

warning

The store transfer has an optional checkbox to delete destination store items that aren't in the source. It's off by default — leave it off unless you deliberately want production stores mirrored to sandbox exactly.

Recommended order

Order matters between entity types (a store references items); within the catalog the tooling resolves dependencies itself:

Price templates — file import (store contents reference them).
Catalog — items, bundles, lootboxes, subscriptions via the Transfer tool. Pity (guaranteed drop) steps are the exception to automatic re-linking: after transferring a lootbox with pity configured, re-select the guaranteed items in production.
Stores, store contents, offers, promotions — Transfer tool.
Daily rewards, loyalty, progression, campaigns — Transfer tool. Campaign transfer doesn't carry linked pages — move the website first, then verify campaign page references.
Glossary, translations, coupons, creators — file import.
Website: theme, pages, news — Transfer tool.
Webhooks, API keys, connectors — configure fresh (next section).
Custom domain → final checks → publish.

Media doesn't need re-uploading: asset URLs are environment-independent, transferred content keeps working images.

Never copy these — configure them fresh

These are environment-specific by design. Copying sandbox values into production will break things:

Webhook endpoints and secrets — production has its own signing secrets (whsec_… vs whsec_sandbox_…). Register your production webhook URLs in Integration → Webhooks; never point production at your test endpoints.
API keys — issued per environment; generate production keys in Integration → API keys.
Aghanim Connect connectors — reinstall in Aghanim Connect with production credentials (real Measurement ID, production MMP tokens), not test apps.
Custom domain and publish state — set up on production directly (see Custom domain).

Verify before publishing

Open every hub page in preview: blocks that reference stores, items or articles render correctly.
No demo content is left visible: sample news, demo items, and especially leaderboards with test participants — they look like live data and will be visible to real players.
Lootboxes with pity: confirm the guaranteed drop items point at production items.
Production webhooks respond. Publishing runs a live check on player.verify — the hub won't publish if it fails. Make sure item.add and item.remove are registered too, or purchases won't be delivered.
Make a test purchase and confirm the item is delivered and your analytics connectors receive the event.
A deep link from a production game build lands in the hub and auto-authorizes the player.

Then publish the hub — and hold announcements until the cache propagates.

Need help? Contact us at [email protected] — we can review your migration plan or walk through the Transfer tool with you.

Need help?
Contact our integration team at [email protected]