← All guides7 min read

How long does a Shopify migration take? A realistic timeline

What actually drives Shopify migration timelines, phase by phase: extract, transform, load, staging verification, and the go-live sequence with Graftport.

The most common question before a replatform is not "can we do this" but "how long will this take." The honest answer is that it depends on four variables: the size of your catalogue, the depth of your order history, the complexity of your mappings, and how long your team takes on staging sign-off. This guide breaks the timeline into phases you can actually plan around, using Graftport as the reference tool.

The phases of a Graftport migration

Every migration in Graftport moves through the same sequence: extract, transform, load. Each phase is a discrete step you can dry-run independently, inspect, and re-run if needed. The total clock time is the sum of phases you control plus the phases the pipeline runs for you.

Phase 1 — Setup (typically a few hours to one day)

Before the pipeline runs, someone needs to:

  • Create the migration in Graftport, name it, and enter source credentials.
  • Connect the destination Shopify store.
  • Select and configure resource types (products, customers, orders, redirects, and so on).

This is human time, not machine time. For a migration with a clear data brief, most agency teams complete setup in under an afternoon. The one thing that takes longer than expected: sourcing the right Shopify Admin API access token with the correct scopes. The wizard tells you exactly what scopes are needed for each resource type.

For a detailed walkthrough of the setup screen, see Setting up your first Graftport migration.

Phase 2 — Extract (minutes to a few hours, depending on source size)

The extract phase pulls records from the source platform via its API. How long it takes is largely determined by:

Catalogue depth. A store with 500 products and 10,000 orders finishes extract faster than one with 50,000 products and 500,000 orders. Source APIs rate-limit how many records can be fetched per minute; Graftport respects those limits and queues requests accordingly.

Source platform. Magento 2 and WooCommerce's REST APIs are broadly similar in throughput. Shopify's Admin API is faster for large catalogues because it supports cursor-based bulk queries. If your source store is under heavy load (peak trading, a concurrent marketing campaign), the API will be slower than normal. Run extracts during off-peak hours when you can.

Order history depth. Three years of orders takes longer than six months. If you do not need complete order history on the destination, you can filter by date in the mapping configuration before extract.

A useful rule of thumb: plan for the extract to take roughly as long as a manual export of the same data would take, then divide by three. Graftport parallelises where the source API allows it.

Phase 3 — Transform (fast, often seconds to minutes)

Transform happens inside Graftport, entirely server-side. It applies your mapping rules to the extracted records, resolves lookups (e.g., mapping Magento category IDs to Shopify collection handles), and produces the load-ready payload.

Unless your mappings have complex custom logic or a very large number of records with many custom attributes, transform is rarely the bottleneck. Most teams do not wait on this phase.

Phase 4 — Load (roughly proportional to catalogue size)

The load phase writes to Shopify's Admin API. Shopify's rate limits govern the pace. Key variables:

Shopify plan. Standard Shopify stores and Shopify Plus stores have different API rate limits. Plus stores allow significantly higher throughput, so a Plus destination loads faster than a standard one for the same catalogue size.

Resource type mix. Products load faster than orders. Orders have more complex sub-records (line items, fulfillments, taxes, refunds) and Shopify validates more of them at write time.

Image attachments. If your product mappings include image migration, each image asset is fetched from the source CDN and uploaded to Shopify. This is often the single biggest contributor to load time for product-heavy catalogues. It is parallelised but network-bound.

After a full extract + transform + load, the destination staging store holds a complete copy of the source data as of the extract timestamp.

Phase 5 — Staging review (your team's call)

How long staging takes is entirely in your team's hands. Graftport delivers a complete destination Shopify store with your data loaded; what you do next is a project management question, not a pipeline question.

A disciplined staging review covers:

  1. Product count and spot-check of 20–30 records for field accuracy.
  2. Customer email uniqueness (duplicates surface here if the source had them).
  3. Order record spot-check against the source.
  4. Redirect verification — pulling the top 200 ranked URLs from Search Console and sampling 50 at random. See Preserving SEO during a Shopify replatform for the exact drill.
  5. Theme and app configuration on the destination (Graftport handles data; theme and app config is the team's job).

Experienced teams with a clear review checklist turn around staging in 2–4 days. Teams doing it for the first time, or with a large catalogue, typically take one to two weeks. That range is almost never caused by data quality issues from Graftport; it is caused by internal sign-off processes and theme work running in parallel.

Phase 6 — Go-live and re-run (a few minutes to a few hours)

On go-live day, you re-run the migration to pick up any data that changed on the source since the dress-rehearsal run. Because Graftport tracks records by their source identity, re-running is safe: anything already loaded is skipped, and only net-new or changed records are processed.

The re-run on launch night typically takes a fraction of the time of the original full run, because most records are already present in the destination. See Re-running a migration safely on go-live night for how Graftport's idempotency works in practice.

DNS flip and Shopify domain transfer are the final steps — those are outside Graftport's scope and governed by your DNS provider and Shopify's domain settings. Most teams plan a maintenance window of 30–60 minutes for this step.

Realistic end-to-end timeline estimates

These are guidance ranges, not guarantees. Actual times vary with catalogue complexity, team availability, and source API conditions.

ScenarioTypical end-to-end
Small store (< 1k products, < 50k orders)1–2 weeks
Mid-size store (1k–10k products, < 200k orders)2–4 weeks
Large store (10k+ products, deep order history)4–8 weeks
Multi-brand / multi-source consolidation6–12 weeks

The ranges assume a single dedicated person driving the project on the agency or merchant side. If internal sign-off gates are long, add that time on top. If the team is experienced and the staging review checklist is tight, you will hit the low end.

What extends timelines most

Source data quality. A source with duplicate product SKUs, broken category trees, or customers with missing required fields causes extract or transform failures that need investigation. Budget time for a source-side data cleanup sprint if the catalogue has not been audited recently.

Mapping complexity. A migration with heavily customised Magento EAV attributes that map to Shopify metafields needs more mapping editor time than a clean Shopify-to-Shopify move.

Multiple brands in one account. Running parallel migrations for multiple clients or brands in a single Graftport tenant is efficient from a tooling standpoint, but adds coordination overhead. Each migration has its own staging review and go-live window. See Migrating multiple brands on one Graftport account for how to structure this.

App re-configuration on the destination. Graftport handles data. Shopify apps (subscriptions, loyalty, reviews, search) need to be reinstalled and reconfigured on the destination store by your team. If app re-configuration is on the critical path, it often drives the staging review timeline more than data verification does.

What does not extend the timeline

Re-running. Re-running a migration, even multiple times, adds only incremental machine time. There is no "reset and start over" penalty. This is the key architectural difference from legacy migration tools: Graftport is designed to be run repeatedly, so treating it as iterative does not cost you.

Dry-runs. A dry-run extract, or a dry-run full run, does not slow down the eventual live load. Dry-runs are free from a timeline perspective. Run as many as you need to feel confident.

Summary

The pipeline itself — extract, transform, load — takes hours, not days. What takes days or weeks is the human work: staging review, app re-configuration, internal sign-off, and the go-live sequence. Plan those human phases on the critical path and treat the pipeline phases as fast, re-runnable infrastructure underneath.

Ready to start? Sign up at app.graftport.com and run your first dry-run today.

Ready to migrate?

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.

Get started See the calculator
Related guides
Using the Graftport CLI with Claude Code: install to first publish
Set up the Graftport CLI and migration-engineer skill in Claude Code, then drive a real Shopify migration through the validate and publish l
Human approval gates for AI Shopify migrations: the Graftport contract
Why an AI coding agent should never push to Shopify on its own, and how Graftport's two-tier CLI contract enforces a human gate on every cos
Automating JSONata Shopify mapping with an AI coding agent
How the Graftport CLI lets an AI agent investigate source rows, fix JSONata mapping errors against structured validation codes, and publish