How agencies and multi-brand parents structure Graftport for parallel migrations: one tenant per agency, one migration per (source, destination) pair, shared monthly allowance, separate mappings, audit-isolated runs.
Graftport is built for teams running migrations as a recurring operation, not a one-shot project. This guide is how agencies and multi-brand parents typically structure their account, what Graftport gives you that a per-project tool does not, and the billing implications of running parallel migrations.
In Graftport the unit of access is a tenant: one billable
account, one set of users, one shared monthly allowance. Inside
the tenant you have migrations: one per (source, destination)
pair. Inside each migration you have mappings (one per
resource type) and runs (every extract/transform/load attempt).
For an agency, the typical pattern is:
For a multi-brand parent, the same structure works:
Graftport is multi-tenant at the database level, but the same isolation principle applies between migrations inside a single tenant. No migration can read another migration's source data, mappings, or runs. The pipeline runner refuses to cross migration boundaries even if you ask it to via raw SQL — the row-level security policies do not allow it.
What this means in practice:
You can run extract, transform, and load on multiple migrations simultaneously. The runner queue inside Graftport supports concurrency at the migration level. Two migrations can be in the load phase at the same time without contending — they write to different destination Shopify stores, so the only shared resource is your tenant's pipeline runner pool.
For agencies in launch crunch, this matters: you can ship five clients on the same week, each on their own destination, without serialising the work.
Pricing on Graftport is one platform fee per tenant plus per-record usage. The monthly included records allowance is shared across every migration on your account that month. Records that go beyond the allowance are charged at the tier rates. Re-syncs are charged at the (cheaper) sync rate.
Practically:
The pricing page's calculator estimates the bill for a single migration in isolation; for a multi-migration month, sum the projected first-load and sync record counts across migrations and run the projection once at the tenant level.
Mapping templates are global to the platform — every tenant sees the same defaults. But your tenant can fork any template and edit freely; the upstream template is unchanged.
Agencies typically end up with a working set of forked templates that encode their house style: their preferred metafield namespace, their convention for how to handle bundle products, their policy on customer group → tag mapping. These live as template versions inside your tenant.
When a new client comes in, the wizard's Step 3 picks the
upstream template by default. To use your house version, edit the
mapping after creation and pick your forked version. Or, if you
want it as the default for all future migrations on your tenant,
contact us about provisioning a tenant-default template — we
ship that as a setting on app.tenant.
A common agency question: "If I lose access to a client at the end of an engagement, what happens to their migration data in Graftport?"
This is overkill for one or two migrations a year, just right for ten plus.
If you are running more than 20 brand replatforms a year, the included allowance and the standard tier rates are not the optimal shape for your usage. Email hello@graftport.com about an enterprise plan: bigger allowance, lower per-record rate above the included tier, dedicated runner pool for your tenant so other tenants' loads do not contend with yours.
Running fifty migrations a year through Graftport is the same operation as running one. That is the point.
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.