Skip to content

Migrations

The Migrations page is where you launch and track tenant-level operations that touch the underlying instances — cloning, deleting, exporting, importing, and replacing entire instances.

What you can do

Five job types:

Job typeWhat it does
Tenant CloneDuplicates a tenant onto a target instance, with optional user-email remapping.
Tenant DeleteRemoves a tenant from its instance and from the Console. Destructive.
Tenant ExportPackages a tenant's data into a downloadable artifact.
Tenant ImportRestores a tenant from a previously exported artifact, on a target instance.
Instance ReplaceMoves every tenant from one instance to another in bulk. Each tenant becomes a sub-job; the parent tracks overall progress.

Every job can be run as a dry run first. Dry runs walk through the whole flow without writing destructive changes — they are the recommended way to validate a job before letting it act for real.

List page

Toolbar

  • Search — free-text across job number, ID, tenant name, error message, actor email.
  • Type — Tenant Clone / Delete / Export / Import / Instance Replace.
  • Instance — filter by source or target instance.
  • Status — All / Active / Succeeded / Failed.
  • Time Range — 7 days / 30 days / All. Toggles at the bottom right of the toolbar.
  • Clear Filters — resets all filters.
  • Refresh — manual refresh (the page also auto-polls running jobs every 10 seconds).
  • New Job button (top right).

A live counter shows how many jobs are currently running.

Columns

ColumnNotes
JobJob type label (Tenant Clone, etc.), the job number (#123), a dry-run flag, and the attempt count if retried.
SubjectCompact description — "Old Tenant (ABC) on prod-1" or "prod-1 → staging-1" for an instance replace.
StatusQueued / Running / Succeeded / Failed.
SummaryPer-tenant progress for instance replaces ("3 / 27 tenants"); the created tenant code for clones; a generic summary otherwise.
StartedRelative timestamp.
DurationElapsed time in human-readable form ("2h 15m").
ByAvatar of the user who requested the job.

Click a row to open the right-hand drawer with the job's logs, outcomes, and actions.

Job lineage

Retries of the same job are grouped as one row — you see the latest attempt's state and the attempt count, not separate rows per retry.

Creating a new job

Click New Job. The wizard has two steps.

Step 1 — Choose the job type

A grid of five cards. Click one.

Step 2 — Configure

Fields depend on the type:

  • Tenant Clone / Tenant Import — source/target tenant, target instance, user-email remap section (explicit mappings if you want to anonymise PII), dry-run toggle.
  • Tenant Delete — source tenant, dry-run toggle.
  • Tenant Export — source tenant, dry-run toggle.
  • Instance Replace — source instance, target instance, dry-run toggle.

Live (non-dry-run) destructive operations show red borders and require explicit confirmation. Dry-run is the default.

Click Run. The job appears in the list with status queued then running.

Job drawer

Migration job drawerMigration job drawer

Click any row to slide out the drawer. Sections:

  • Header — job type, status, dry-run flag, attempt count, started time, duration.
  • Subject — what is being acted on (tenant, instance, or both).
  • Phase logs — collapsible groups (preflight, clone, import, etc.). Phases with errors or warnings auto-open.
  • Live progress — for in-flight jobs, the current phase and percentage.
  • Outcomes — what changed, broken down by category.
  • Actions — context-dependent:
    • Rerun / Retry / Resume — the label depends on job type and current status. For instance replaces this resumes only the failed tenants.
    • Rollback — visible if the job is part of a failed instance-replace sequence; cleans up orphaned tenants.
    • Download artifact / Upload artifact — for exports and imports respectively.

Instance-replace progress

Instance-replace jobs include a per-tenant progress table in the drawer with source code, target code, and per-tenant status. You can see exactly which tenants succeeded and which failed mid-replace.

Best practice

  1. Always dry-run first. A failing dry run tells you what would have gone wrong without doing damage.
  2. Validate the artifact for exports before relying on it for an import. Download and inspect.
  3. For instance replaces, schedule a window — even with parallelism the wall-clock time scales with tenant count.
  4. Watch the drawer's phase log during the first few minutes of a live run. Most failures surface early (preflight, capacity, permissions).