Migration
A migration is the top-level workspace — one per merchant move. It holds:
- A source platform + credentials (Dandomain, Magento, Shopify, or WooCommerce).
- A destination (always Shopify) + an Admin API token.
- A set of enabled resources (products, customers, …) and the mapping pinned to each.
- The full run history for this merchant.
Two things that sound alike
A migration carries a status and a stage. They are different questions and neither one derives from the other.
- Status — is this record in play? Draft, Active, or Archived.
- Stage — how far through the delivery are you? Setup, Test load, Client sign-off, Go live, or Live.
A migration can be Active and still in Setup. It can be at the Live stage and later be Archived. Don’t read one off the other.
Status
| Status | Meaning |
|---|---|
| Draft | Just created. Free to edit credentials, resources, mappings. Safe scratch space. |
| Active | In production. Runs are billable. Credential and resource changes are still allowed. |
| Archived | Migration is done or abandoned. Read-only. New runs are blocked but existing data and history remain inspectable. |
Promote Draft → Active from Settings → Status and stage on the migration, once you’ve validated an extract and a dry-run transform.
Stages
Stage is where the migration sits in your delivery process. It’s the column a migration occupies on the board, and it’s shown as a badge at the top of the migration.
| Stage | What it means |
|---|---|
| Setup | You are connecting the source and mapping its fields. |
| Test load | Data is loading into a test store so you can check it. |
| Client sign-off | The client is reviewing the test store. Nothing loads to production until they approve. |
| Go live | Approved. The production load is scheduled or running. |
| Live | The production store is live. Changes keep syncing. |
Moving a migration between stages
There are two places to change it.
On the Migrations screen, the Board view gives each stage a column and each migration a card. Drag a card to another column to move it, or focus a card and use the arrow keys.
Inside a single migration, Settings → Status and stage has a picker showing the current stage, next to the status control. Choosing another one moves it straight away — the same change the board makes, without hunting for the card.
Moving a card never starts, stops, or changes a run. Stage is a label you keep up to date for your own team — it records where you think the work is, and nothing else acts on it.
Nothing enforces an order either. A migration can go back from Client sign-off to Setup when the client asks for a change, or skip a column when a go-live is pulled forward.
The card footer shows how long the migration has been in its current stage, so a card that has sat in Client sign-off for three weeks is visible without opening it.
Filters
Above both views, chips narrow the list:
| Chip | Shows |
|---|---|
| All | Everything. |
| Setup & test | Migrations in Setup or Test load. |
| Awaiting sign-off | Migrations in Client sign-off. |
| Live | Migrations at Go live or Live. |
| Blocked | Migrations whose last run failed — the only chip that isn’t a stage. |
Editing vs versioning
You can change the merchant’s display name, swap credentials when they rotate, or enable a new resource without rebuilding history. But every run is a frozen record of what happened: once a run shows that it transformed row X with mapping version V, that pairing never changes.
This is intentional. It means you can answer “what did we send to Shopify on March 14?” by reading the run’s history, not by replaying logic in your head.
Slug
Each migration has a slug derived from its name on creation — a short,
lower-case handle like northwind-home-goods. You’ll see it on the
Settings tab, and you have to type it to confirm a destructive
action such as purging loaded records, which is the main reason it
exists.
You can edit it, and doing so doesn’t break any links: shareable migration URLs are built from the migration’s ID, not its slug.