How agencies and multi-brand teams structure Graftport for multi-client Shopify migration work: account hierarchy, shared billing, mapping reuse, parallel go-lives, and handoff.
Agencies and multi-brand teams have a different relationship with migration tooling than a merchant running a one-time move. You are running migrations repeatedly, for different clients, on different source platforms, with different timelines — often in parallel. This guide covers how Graftport's account model fits that workflow: how to structure your account, reuse mapping work across clients, run parallel migrations safely, and hand off a completed migration to a client's own Shopify admin.
Graftport organises work into three layers:
Tenant (your agency)
└── Migration (one per source → destination pair)
├── Mapping (one per resource type, versionable)
└── Run history
One tenant, many migrations. Your agency has one Graftport account (the tenant). Every client migration lives inside that tenant as a separate migration object. The billing and record allowance roll up to the tenant level; individual migrations don't have their own billing thresholds.
Migrations are isolated. Source credentials for Client A are never readable by Client B. A mapping change on one migration cannot affect another. Row-level security at the database layer enforces this — there is no configuration option that relaxes it.
All users see all migrations. Every user on your tenant can see every migration. If you need to keep Client A's data invisible to a contractor who works only on Client B, the current model does not support that. Per-migration access control is on the roadmap; today, the trust boundary is the tenant, not the individual migration.
Migrations appear in a list. Names that actually help: NorthwindHome (Magento 2.4 → Shopify Plus) or PetStore UK (WooCommerce → Shopify).
Names that don't help: Client, Migration 1, Test.
Include the source platform in the name. It removes ambiguity when you
have three WooCommerce migrations open at once. Include a status
qualifier if useful: PetStore UK — staging for the staging run and
PetStore UK — production once the production migration is live.
The biggest productivity gain for agency teams is mapping reuse. Most Magento stores share a common product attribute structure; most WooCommerce stores use variations the same way. A mapping you built carefully for Client A is a starting point for Client B.
Fork, don't start from scratch. When you open the mapping editor on a new migration, you can fork an existing template from any migration on your tenant. The forked mapping starts as a versioned copy — edit it freely without touching the source.
Versioning protects you. Every save creates a new mapping version. If a fork of Client A's mapping breaks on Client B's product data, you can revert to the last working version in two clicks. The migration's run history always records which mapping version each run used — essential for post-go-live auditing.
Custom attribute mapping. If multiple clients use similar Magento custom attribute structures, the metafield mapping approach is the same across clients. Build it once on the first client, document the expression pattern, and fork it for subsequent clients. The guide on mapping Magento custom attributes to Shopify metafields covers the pattern in detail.
Multiple migrations can run simultaneously on the same tenant. There is no global lock — each migration runs its own extract, transform, and load against its own source and destination without interfering with any other.
What to watch when running parallel migrations:
Shared allowance. The tenant's included monthly records are shared across all migrations that fire during the billing month. If two large migrations load in the same month, they consume from the same pool. Plan your go-live schedule with this in mind; staggering large loads across billing months can reduce overage. Use the pricing calculator at graftport.com/pricing to model each migration's projected first-load count.
Shared team. All users on the tenant can start runs on any migration. Agree on a convention for who owns the "run" button for a given migration — the last thing you want is two engineers both kicking off a load on go-live night.
The sequence for each client migration should be reproducible, regardless of source platform:
Set up the migration — source credentials, destination token, enabled resources, mapping forks as needed. Two to four hours for a standard migration; more for complex attribute mappings.
Staging run — full (extract + transform + load) against a development or partner Shopify store. Walk the destination with the client to sign off.
Delta before go-live — on go-live day, extract again against the live source to pick up changes since the staging run. Transform and dry-run to confirm the delta counts.
Go-live load — load with dry-run off. Graftport skips everything already on staging (at zero cost) and loads only the new and changed records. See Re-running a migration on go-live night for the timing sequence.
DNS flip — once the load reports succeeded, flip DNS to the destination.
24-hour delta — the next day, run one more extract + load to catch orders placed during the DNS propagation window.
The pre-go-live checklist has the full verification drill your team should run on staging before any go-live.
The above workflow is optimised for agencies doing repeated replatforms. If you're looking at a single Magento store that needs a one-off done-for-you move rather than a self-serve migration, our sister product Move to Shopify is designed for that scenario — a flat fee, no tooling to learn.
When the migration is complete and the destination store is live, you'll want to hand the destination store over to the client while archiving or removing access from your Graftport tenant.
On the Shopify side: transfer the destination store to the client's Shopify Partners account or to their own Shopify admin. This is a Shopify admin operation, not a Graftport one.
On the Graftport side: the migration record stays on your tenant. The source and destination credentials remain encrypted in the migration object — useful if you need to run a final delta extract weeks after go-live. When you're fully done, you can clear the credentials from the Edit migration page to remove Graftport's access to both stores.
Ready to run your first multi-client migration?
Set up a free account, connect a source, and run a dry-run to see exactly what lands in Shopify before committing.
Start at app.graftport.com · See the pricing model
Related reading:
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.