The pitch for Drupal-to-Shopify migration sounds clean: get off a self-hosted CMS that requires maintenance, security patches, and a developer on call, and onto a managed ecommerce platform that handles all of that for you. And the pitch is true — as far as it goes.

What the pitch leaves out is that Shopify is an opinionated platform with hard limits baked in. Some of those limits don't matter for most stores. Some of them matter enormously, and finding out which category you're in after the migration is the expensive way to learn.

This is a practical guide to the constraints. Not to talk you out of Shopify — it's genuinely excellent for what it's designed to do — but to make sure you know what you're agreeing to before you move 40,000 SKUs off a platform that gave you complete control.

The Hardest Constraint: URL Structure Is Locked

This is the one that surprises people most. Shopify enforces a fixed URL structure. You cannot change the path prefixes. Period.

Content type	Shopify URL (forced)	What your Drupal URLs might be
Products	/products/handle	/catalog/widgets/blue-widget
Collections	/collections/handle	/category/widgets
Pages	/pages/handle	/about, /contact
Blog posts	/blogs/news/article-handle	/blog/2024/article-title
Cart	/cart	Whatever you had

If your Drupal store has been running for five years and those product URLs have accumulated backlinks, search ranking, and user bookmarks, you need to 301-redirect every one of them to the new Shopify structure. Shopify gives you 10,000 redirect slots. That sounds like a lot until you have 40,000 products.

The workaround for large catalogs is a redirect app (Shopify's app ecosystem has several). But redirect apps add monthly cost, add load time for the redirect lookup, and don't fully replicate what your server-level nginx redirects used to do. It's manageable. It's not free.

No Server-Side Code

Drupal runs PHP on your server. You can do anything on that server — custom modules, complex business logic, background jobs, direct database queries, cron tasks, external API integrations that run server-side. All of that is yours to build.

Shopify's template engine is Liquid. It's powerful for building storefronts and it covers most display logic cleanly. But Liquid runs at render time on Shopify's infrastructure. You don't have access to the server. You can't run PHP. You can't run a cron job. You can't execute arbitrary server-side logic.

Complex business logic that lives in a Drupal module has to move somewhere. Usually that means:

• A Shopify app (if someone's built one for your use case)
• A custom Shopify app you pay to build (requires a Shopify Partner account and follows their app review process)
• Shopify Flow (a workflow automation tool that covers common if-then logic)
• An external serverless function that the storefront calls via API

None of these are bad. But if your Drupal site has ten custom modules, you need to map each one to a Shopify equivalent before migration. Some will map cleanly. Some won't.

Product Variant Limits

Shopify limits products to three option types (e.g., Size, Color, Material) and 100 variants per product (combinations of those options). For a t-shirt store, this is irrelevant. For a configurable industrial parts catalog with six option types and hundreds of combinations per part, this is a structural problem.

The workaround is metafields — Shopify's custom field system — combined with a custom storefront UI that handles the additional options. It works, but it's custom development that adds cost and complexity that didn't exist on Drupal.

Checkout: The Shopify Plus Wall

Standard Shopify gives you extremely limited checkout customization. You can add a logo, change colors, and that's about it. You cannot modify the checkout flow, add custom fields to the checkout, inject custom logic (like discount rules based on cart contents), or change the checkout URL structure.

Full checkout customization — specifically checkout.liquid and Checkout Extensibility — requires Shopify Plus. Plus starts at approximately $2,000/month. If your Drupal store has a customized checkout (custom discount logic, B2B pricing tiers, custom form fields for order notes), you need to either move to Plus or accept a simplified checkout flow.

A Direct List of What Shopify Won’t Let You Do

• Change the /products/, /collections/, or /pages/ URL prefixes
• Run server-side code (PHP, Python, Ruby) on the storefront
• Access the database directly (no raw SQL)
• Set up server-level cron jobs without an external service
• Customize checkout beyond basic branding (without Plus)
• Create more than 3 product option types per product
• Have more than 100 variants per product
• Build complex user permission hierarchies (Drupal's granular role system has no equivalent)
• Host arbitrary files in a custom directory structure (assets go through Shopify's CDN)
• Inject JavaScript into the checkout process (without Plus)
• Serve from multiple domains with a single Shopify store in the traditional multisite sense
• Create native blog categories (only tags; category simulation requires workarounds)

What You Actually Gain

The constraints are real, but so are the benefits. Shopify eliminates a category of problems entirely:

• Security: No PHP vulnerabilities to patch. No WordPress-style exploit waves. No plugin conflicts that create attack surface.
• PCI compliance: Shopify handles payment processing compliance for you. On Drupal, that's your problem (or your payment gateway's problem with careful integration).
• Hosting: No server to manage, no capacity to plan, no CDN to configure. Shopify scales automatically.
• Updates: Platform updates happen without your involvement. You don't apply them; you just have a newer platform.
• App ecosystem: Thousands of apps covering nearly every use case. Most are monthly subscription costs, but the alternatives (custom Drupal module development) often cost more per feature.

Who Should Migrate — and Who Shouldn’t

Migrate to Shopify if your product catalog is relatively standard (under 3 option types per product, under 100 variants per product), your checkout flow doesn't have custom logic that requires Plus, your URL structure can survive a 301 migration without catastrophic SEO damage, and you're primarily selling products rather than running a complex content site.

Think carefully before migrating if you have a heavily customized checkout, a catalog with complex variant requirements, significant custom module functionality that has no Shopify equivalent, or a content-heavy Drupal site where the CMS features (Views, complex content types, workflow states) are doing real work beyond powering an ecommerce catalog.

The Migration Process, Realistically

A clean Drupal-to-Shopify migration typically takes four to eight weeks for a mid-sized catalog. The work breakdown:

1. Audit phase — Map every URL, document every custom module, identify every constraint that will hit a Shopify limit. This is the most important week of the project.
2. Data migration — Export products, customers, and orders from Drupal. Transform to Shopify's import format. Handle variant mapping. This is where the 3-option-type limit either bites you or it doesn't.
3. Theme development — Build the Shopify theme in Liquid. If you have custom Drupal views driving complex filtered listings, plan how to replicate those with Shopify collections and metafields.
4. Redirect mapping — Every old URL to its new Shopify URL. All 10,000 (or more) of them.
5. Testing — Checkout flows, payment processing, email triggers, search, filters, mobile layout. Everything that touches the user path.
6. Cutover — DNS change, final redirect QA, Google Search Console property update, sitemap resubmission.

The audit phase is where most projects discover the constraints that matter for their specific store. Do it before you commit to a timeline or a budget. The constraints are fixed; the only variable is how much you know about them going in.