How Graftport's run model lets you re-run a migration on launch night without creating duplicates: the run modes, the dry-run safety net, the cheaper re-sync rate, and the rollback path if something is wrong after launch.
The hardest hour of a Shopify migration is the one where you flip DNS and the new store starts taking real orders. Most platforms tell you "do not touch the migration on go-live night." Graftport is built around the opposite assumption: re-running is a normal operation, even on launch night. This guide is the contract for how that works.
Every run in Graftport is one of four shapes:
| Mode | What it does |
|---|---|
| Extract only | Read from source, store raw. No destination touch. |
| Transform only | Re-shape last extract using current mappings. No fetches. |
| Load only | Push the last transformed shape to the destination. |
| Full | Extract → transform → load, in one run. |
Each mode can also be flagged dry-run, which means the run does all its work but stops short of writing to the destination Shopify store. Use dry-run liberally — it is exactly the same code path as a real run, minus the final write.
The four modes are how you orchestrate launch. A typical sequence:
Every record Graftport writes carries a stable identity formed
from the source platform plus the source ID. Magento's product
ID 7842 is magento:product:7842 regardless of which run touched
it. The destination Shopify product's metafield carries the same
identity tag.
On any subsequent run:
You can re-run a migration ten times in a row. The destination will not gain duplicates. The bill grows by sync charges for the records that genuinely changed since the last run, and by nothing else.
Dry-run runs the same extract and transform code as a live run. What it skips is exclusively the destination writes. Use it for:
A failed dry-run is cheap. A failed live load on launch night is expensive in trust, even if Graftport is fully idempotent.
A practical hour-by-hour timetable that has worked across many launches:
T -2 hours. Run Extract only against the live source. This locks in the source state at a known timestamp.
T -1 hour. Run Transform only + dry-run. Open the Data tab, confirm record counts match expectations and no records errored. Total time: usually under 10 minutes.
T 0. Run Load only (no dry-run). Pushes the just-extracted, just-transformed payload to the destination. Most records are skipped (already loaded from the rehearsal); a few hundred sync; new orders since the rehearsal first-load. Total time: a few minutes for a delta, longer for a full first push.
T +5 minutes. Open the run page, confirm failed = 0 and the
run status is succeeded.
T +10 minutes. Flip DNS to the destination Shopify store. Old URLs continue to 301-redirect via the redirect table Graftport loaded on the destination during the first run.
T +60 minutes. Submit the new sitemap to Search Console. Watch the Coverage report.
Two cases call for human judgment:
Graftport never overwrites a destination record without recording
what it did. Each loaded record's per-run trace lives in
run.record_event. If a re-sync clobbered a hand-edit your team
made on the destination Shopify store, you can:
Larger rollback patterns:
app.mapping_template_version. From the mapping editor, click
Versions, pick a prior version, hit Restore. The next
run uses the restored shape.The pricing tier you pay depends on whether a record is a first load or a sync. The dashboard's projection is based on the most recent dry-run; it is exact, not approximate. A typical launch- night sequence costs:
When go-live night arrives, the muscle memory you built in dry-runs makes it boring. Boring is what you want.
Connect a source store, dry-run a migration, see the exact Shopify result before a single record lands. The same platform your team will use on go-live night.