Runs
A run is one execution of one or more phases over a migration. Runs are the unit of work you start; everything else is configuration.
The three phases
| Phase | What it does |
|---|---|
| Extract | Pulls the latest data from the source platform’s API. |
| Transform | Runs the pinned JSONata mapping over that data, producing Shopify-shaped records ready to load. |
| Load | Pushes the staged records to Shopify. |
You can run any non-empty subset of phases. The most common combinations are:
- Extract only — first contact with a source. Confirms credentials and pulls in the data. Nothing reaches Shopify.
- Transform + load — re-do the work without re-pulling from the source. Common after a mapping fix.
- Full (extract + transform + load) — the production case once configuration is settled.
See Runs → Phases for the picker UX and what each combination implies.
Run status
| Status | Meaning |
|---|---|
| Pending | Queued, waiting to start. |
| Running | In progress. |
| Succeeded | Every resource finished cleanly. No errors. |
| Completed with errors | The run finished, but some rows or resources hit errors. The data that did land is usable. |
| Failed | Every resource hit a fatal error, or the run was aborted before any data could land. |
| Canceled | An operator canceled the run before it finished. |
Final statuses (Succeeded, Completed with errors, Failed, Canceled) never change. You can’t “resume” a finished run — you start a new run, which automatically picks up where the data left off.
Run items
Each run produces one run item per enabled resource. The run item shows you:
- Which phase it’s currently in.
- The result once it’s done (Succeeded / Failed).
- Per-resource counts: extracted, transformed, loaded, skipped, errored.
- Any errors with the failing record IDs.
A failed item doesn’t fail its siblings. If some resources finish cleanly and others hit errors, the run as a whole shows Completed with errors — the data that did land is usable. Failed is reserved for the case where every resource failed.
301 redirects
After a successful, non-dry run that included the load phase, Graftport emits 301 redirects so customer bookmarks and search-engine results don’t 404 on the new shop.
Redirects come from two sources:
- Carryover. For Shopify-to-Shopify migrations, every existing redirect on the source store is copied over.
- Derived. Whenever a product or collection landed at a different URL on the destination than it had on the source, a redirect is generated automatically.
The run detail page shows a 301 Redirects panel with how many were pushed, how many failed, and (for Shopify sources) a sample of how many of the source paths were actually live on the source store. The panel is marked Skipped when the run was a dry run, didn’t include load, or didn’t reach a clean Succeeded state.
Why runs are cheap to repeat
Graftport keeps your extracted source data and your staged records between runs. That means:
- Re-running transform doesn’t re-pull from the source.
- Re-running load only pushes records that haven’t landed yet (or have changed).
- Re-running extract updates existing source rows in place rather than duplicating.
This is why you can iterate on a mapping in five-minute cycles instead of an hour each.