WooCommerce to Shopify: When Your Store Outgrows WordPress

WooCommerce is the most popular e-commerce platform on the web by raw store count. It's also the platform that most often gets migrated away from once a store hits real scale. The pattern is familiar: a brand starts on WordPress + WooCommerce because that's what their dev built them on, the store grows, and somewhere between $500K and $5M in annual revenue, things start to fray. Plugins conflict. Checkout slows. Hosting upgrades cost more than Shopify Plus would. The dev team becomes a single point of failure.

If you're at that point, you're not alone. We've shipped this migration path many times, including for a regulated commerce client (Wildflower Hemp Co) currently on Shopify Plus. Here's how we think about it.

The honest case for moving

Shopify is the right destination for a WooCommerce store when:

• Your traffic is high enough that hosting performance matters. Shopify's infrastructure handles traffic spikes (flash sales, press hits, holiday seasons) without breaking a sweat. WooCommerce on shared or VPS hosting starts to crack under sustained load. By the time you're paying for managed WooCommerce hosting at $300+/month with caching and a CDN, Shopify Plus pricing is in the same range and the platform is purpose-built for the job.
• Your plugin stack has become fragile. Twelve plugins for inventory, shipping, tax, accounting, abandoned cart, reviews, loyalty, subscriptions, etc., where every WordPress core update is a coin flip. Shopify replaces most of these with a single-vendor app ecosystem and a hardened core platform.
• You sell across multiple channels. Shopify's POS, social commerce integrations, and B2B tools are mature. WooCommerce can do this with plugins, but the integration surface is messier.
• You need international tax and currency support. Shopify Markets handles multi-currency, multi-language, and multi-region tax in a way that's significantly easier than WooCommerce equivalents (which usually require a stack of plugins and custom work).
• You're considering headless or composable commerce. Shopify's Storefront API and Hydrogen framework give you a clean path to headless. WooCommerce can be made headless, but it's much more work.
• Your team's bottleneck is the developer. Shopify's admin UI is something most marketing managers can use. WooCommerce admin requires a WordPress mental model and often a developer for anything beyond basic product updates.

When you should stay on WooCommerce

We don't recommend Shopify when:

• Your store is mostly content with a small commerce side. A media site or content brand that sells some merchandise as a side revenue stream is better served keeping content on WordPress and either staying on WooCommerce or using a Shopify Buy Button for the products.
• You have heavy custom cart logic. Complex pricing rules, custom discount engines, B2B quote-to-order flows, anything that requires modifying checkout behavior. Shopify's standard plans lock checkout. Shopify Plus opens it (via checkout extensions) but at $2,300+/month.
• You depend on specific WooCommerce extensions with no Shopify equivalent. Some niche WooCommerce extensions (specific subscription handlers, custom B2B portals, deep ERP integrations) don't have direct Shopify analogs. Audit before you commit.
• You're under $200K in annual revenue. Below this threshold, Shopify's monthly subscription cost ($39 to $299/month) plus app costs ($50 to $300/month) often exceeds what you'd spend on managed WooCommerce hosting. The economics favor staying.
• You have a content-driven SEO strategy that depends on WordPress. A blog with serious SEO traffic, content marketing as a primary acquisition channel, deep editorial workflow. Shopify's blogging is functional but not at WordPress's level. You can run WordPress for content and Shopify for commerce, but that's a different architecture, not a migration.

What gets preserved

Done right, a WooCommerce to Shopify migration preserves:

• Customer accounts, including order history, addresses, and saved details (with the right migration tools)
• Product catalog: SKUs, variants, images, descriptions, custom attributes
• Order history, with the caveat that historical orders sometimes lose some metadata depending on the migration tool used
• Search rankings via 301 redirects from old WooCommerce URLs to new Shopify URLs
• SEO metadata (titles, descriptions, schema)
• Email subscribers, transferred to Shopify's email or to a third-party tool like Klaviyo

What changes (be ready)

• Theme. WooCommerce themes don't migrate to Shopify. The storefront design either gets rebuilt in Shopify (using one of their themes as a base) or rebuilt entirely as a custom Shopify theme.
• Checkout flow. Shopify's checkout is locked on standard plans. You can customize the order summary, the post-purchase experience, and the thank you page, but the core checkout pages are Shopify's. Shopify Plus (~$2,300/month) opens this up via checkout extensions and B2B-specific flows.
• Apps replace plugins. Most WooCommerce plugins have a Shopify app equivalent. Shopify apps usually charge monthly subscriptions where WordPress plugins were one-time purchases. Budget for ongoing app costs.
• Payment processor. WooCommerce works with whatever payment gateway you wired up. Shopify defaults to Shopify Payments (Stripe under the hood). You can use other gateways but they incur an extra 0.5% to 2% Shopify transaction fee on top of what the gateway itself charges.
• Tax setup. Shopify Tax (free up to a threshold, then paid) replaces whatever you were doing for sales tax. Built-in nexus tracking, automatic rate calculation. Cleaner than the WooCommerce + plugin equivalent for most U.S. stores.

What the migration actually looks like

Phase 1: Audit and product mapping

Inventory every product, variant, customer record, order, content page, and integration. Map each to its Shopify equivalent. Identify gaps where WooCommerce extensions don't have direct Shopify app equivalents.

Phase 2: Shopify build on a development store

Shopify Partner accounts come with free development stores. We build the new theme there, configure products, set up apps, wire integrations, all without affecting the live WooCommerce site. This is the equivalent of "staging" in the WordPress world.

Phase 3: Data migration

Shopify offers a few approved migration tools (Cart2Cart, LitExtension, Matrixify) for moving products, customers, and orders. We pick the right tool based on data volume, complexity, and source data quality. For complex catalogs we sometimes write custom migration scripts. Variants, image associations, custom product attributes, and SEO metadata all need careful mapping.

Phase 4: Redirect map

Every old WooCommerce URL gets a 301 to its new Shopify equivalent. Product URLs change format (/product/sku-123 becomes /products/product-name). Category URLs change. Blog post URLs change. The redirect map prevents SEO loss. Shopify has a built-in URL Redirects feature (Online Store > Navigation > URL Redirects) for managing this.

Phase 5: Apps and integrations

The plugin equivalents get installed and configured. Email marketing connects to Klaviyo or Shopify Email. Reviews connect to Judge.me or Yotpo. Loyalty connects to Smile or LoyaltyLion. Shipping connects to ShipStation or Shippo. Each one needs configuration time, not just installation.

Phase 6: Tax and payments

Shopify Tax gets enabled and nexus rules configured. Shopify Payments gets set up (or the alternative gateway is connected, with the transaction fee acknowledged). Test transactions across multiple regions before launch.

Phase 7: QA and sign-off

Test orders end-to-end across multiple regions, payment methods, and product types. Test refunds. Test subscription renewals if applicable. Test shipping rate calculation. Test tax calculation. The store walks every flow before sign-off.

Phase 8: Launch and monitoring

DNS cutover, sitemap resubmit, 30 to 60 days of monitoring. Order volume comparison. Search Console comparison. Customer support volume monitoring (post-migration questions are normal for the first two weeks).

Timeline reality

• Small store (under 100 SKUs, single warehouse, U.S.-only): 4 to 8 weeks
• Mid-size store (500 to 5,000 SKUs, multiple variants, basic international): 8 to 14 weeks
• Large or complex store (10,000+ SKUs, B2B, multi-region, subscription, custom workflows): 14 to 24+ weeks

The variable that hits hardest isn't catalog size, it's complexity of pricing rules, B2B logic, and custom integrations.

Cost reality

• Small store migration plus theme rebuild: $15,000 to $35,000
• Mid-size migration with custom theme: $35,000 to $75,000
• Complex migration with B2B, custom theming, and integrations: $75,000 to $200,000+

Plus Shopify subscription costs:

• Shopify Basic: $39/month
• Shopify Standard: $105/month
• Shopify Advanced: $399/month
• Shopify Plus: ~$2,300/month (custom pricing for high-volume merchants)

Plus app costs, which typically run $50 to $500/month for a typical store stack.

Common mistakes

Running both stores in parallel for too long. A short overlap during QA is fine. Running both live for weeks creates inventory drift, SEO confusion, and customer experience inconsistency. Pick a launch date and commit.

Not mapping URL redirects. Same warning as every other migration: 301s from every old URL to its new equivalent. Without this, your SEO drops the day you launch. The redirect map is non-negotiable.

Assuming the data migration tool will handle everything. It won't. Edge cases (custom product attributes, complex variants, gift card balances, store credit) almost always need manual cleanup. Budget for it.

Forgetting tax setup. Shopify Tax handles U.S. sales tax cleanly, but it doesn't auto-detect every nexus state for you. You configure where you have nexus, and the platform calculates from there. Get this right with your accountant before launch.

Underestimating app subscription costs. A typical Shopify store stack (email, reviews, loyalty, SEO, shipping, tax, analytics) easily runs $200 to $400/month in apps. Add this to your TCO comparison vs WooCommerce.

Not training the team. Shopify's admin is friendlier than WooCommerce's, but it's still different. A 30-minute walkthrough on launch week pays back massively in reduced support burden.

WordPress maintenance fatigue is real. We hear it weekly. A plugin update breaks the homepage. A theme update wipes out custom CSS. The hosting bill creeps up every year. Page builders get heavier and slower until the site crawls on mobile. The dev team's smallest change requires a staging environment, a deploy pipeline, and a Tuesday afternoon.

Webflow promises a way out. No plugins. No PHP. No version updates breaking things. Beautiful design control. A CMS that non-technical teams can actually use.

The pitch is real. It's also incomplete. Here's what we tell clients who ask us about migrating from WordPress to Webflow.

The honest case for moving

Webflow is the right destination for a WordPress site when:

• The site is a marketing site or content site, not an application. Brochure sites, design portfolios, agency sites, SaaS marketing sites, content marketing blogs. Where Webflow shines.
• Design control matters more than CMS depth. If your team has a strong opinion about how every page should look and feels constrained by WordPress themes, Webflow's visual builder gives you genuine pixel-level control without writing code.
• You don't need a plugin ecosystem. A WordPress site that depends on twelve plugins for forms, SEO, caching, image optimization, security, social sharing, redirects, etc. simplifies dramatically on Webflow because most of that is built in.
• Maintenance is killing you. No PHP version to update, no plugins to patch, no themes to compatibility-test. Webflow's hosting and platform updates happen invisibly. This is a real ongoing cost difference.
• Your team wants to update content without breaking things. Webflow's CMS, when set up well, lets non-technical teams edit pages, publish blog posts, and manage collections without ever touching code or worrying about updates.

When Webflow isn't the answer

We don't recommend Webflow when:

• You have serious e-commerce. Webflow Ecommerce exists but is significantly behind WooCommerce, Shopify, or BigCommerce in feature depth. If you're processing more than $100K/year in orders or have complex catalog needs, Webflow is the wrong tool.
• You have membership, paywall, or login-required content. Webflow's user accounts feature exists but is limited compared to WordPress + MemberPress, Memberstack, or a custom membership solution. Doable for simple cases, not for complex ones.
• Your CMS architecture has many interconnected content types. Webflow Collections work well for blogs, case studies, team members, services. They get awkward when you have ten content types referencing each other in complex relationships.
• You depend on specific WordPress plugins. Forms with conditional logic and Salesforce integration. Multi-language content via WPML. Booking systems via WP-Booking-Plus or similar. Some of these have Webflow equivalents (often via third-party tools like Memberstack or Outseta), but many don't, or the equivalents cost more monthly than the original WordPress site cost annually.
• You have a large editorial team with workflow needs. Webflow's editor permissions are simpler than WordPress's role system. For a single content manager, it's fine. For a team of fifteen with draft/review/approve/publish flows, it's limiting.

What gets preserved in the migration

Done right, a WordPress to Webflow migration preserves:

• Every URL via 301 redirects from old structure to new
• All page content and blog posts with formatting, embedded media, and SEO metadata
• Search rankings when redirects are mapped properly and metadata is preserved
• Brand identity, design intent, content tone: all of it can move over and improve in the process
• Sitemap.xml and robots.txt rebuilt for the new structure and resubmitted to Search Console

What you'll rebuild from scratch

Be ready for these:

• The theme. Webflow doesn't import WordPress themes. The visual design either gets rebuilt in Webflow's designer (using your existing brand and design system) or refreshed entirely as part of the migration.
• All forms. WordPress forms (Gravity, WPForms, Contact Form 7) don't migrate. Webflow has native forms that are simpler but less powerful. Complex form logic may need a third-party tool like Jotform, Typeform, or Formspark embedded into Webflow.
• All custom WordPress functionality. Custom plugins, custom shortcodes, custom widgets, anything theme-specific: gone. You either find a Webflow-native way to do it or a third-party tool that integrates.
• Integrations. Email marketing connections (Mailchimp, ConvertKit), CRM connections (HubSpot, Salesforce), analytics: all need to be re-wired to Webflow.

This isn't a copy-paste migration. It's a rebuild that preserves the content while rethinking the implementation.

What the migration looks like

Phase 1: Audit and content inventory

Every page, post, custom post type, taxonomy, and form gets inventoried. We identify what migrates as-is, what needs reshaping for Webflow's CMS structure, and what gets retired entirely.

Phase 2: Webflow build on staging

A fresh Webflow project gets created. The new design (or the ported existing design) gets built in Webflow's designer. Collections (Webflow's term for custom post types) get configured to match the source content model.

Phase 3: Content migration

Content moves over via:

• Webflow's CSV import for bulk blog posts and collection items
• Custom export from WordPress using WP All Export or direct database extraction, then transformation to Webflow's CSV format
• Manual rebuild for pages that have unique layouts and don't fit the collection model

Embedded media uploads to Webflow's asset manager. Internal links get rewritten to point at the new URL structure.

Phase 4: Redirect map

Every old WordPress URL gets a 301 redirect to its new Webflow equivalent. Webflow has a built-in redirect manager (Site Settings > Publishing > 301 Redirects) that handles this. We build the redirect map as a spreadsheet, then implement it before launch.

Phase 5: SEO rebuild

Meta titles, descriptions, OG tags, schema markup, sitemap.xml: rebuilt in Webflow and resubmitted to Search Console post-launch. Webflow handles a lot of SEO basics automatically, but specific schema and structured data need attention.

Phase 6: QA and sign-off

Cross-browser, cross-device, performance, accessibility. Webflow generally produces fast, accessible code, but theme-specific testing matters. Client walks every page on staging and signs off.

Phase 7: Launch and monitoring

DNS cutover, sitemap resubmit, 14 to 30 days of monitoring for ranking drift, form submission failures, broken redirects.

Timeline reality

• Small marketing site (under 50 pages, simple blog): 3 to 6 weeks
• Mid-size site (50 to 200 pages, multiple collections, custom landing pages): 6 to 10 weeks
• Complex site with redesign and content rework: 10 to 16 weeks

Webflow migrations tend to be faster than WordPress-to-WordPress redesigns, because the platform itself is faster to build in and there's less plugin configuration to do. But they're not "lift and shift" projects.

Cost reality

• Small marketing site migration: $8,000 to $15,000
• Mid-size migration with light redesign: $15,000 to $35,000
• Complex migration with full redesign: $35,000 to $80,000

Plus Webflow's hosting plans, which range from $14/month for a basic site to several hundred per month for high-traffic CMS sites. For most marketing sites, expect $30 to $50/month all-in for hosting once it's launched.

Common mistakes

Assuming Webflow can do everything WordPress can. It can't. We've seen migrations stall in week 6 because someone realized they couldn't replicate a specific WordPress plugin's behavior. Audit functionality before committing.

Underestimating CMS rebuild time. Webflow's collection structure isn't WordPress's custom post type structure. Reshaping content models takes longer than people expect, especially for sites with deep relationships between content types.

Forgetting form migration. Forms are usually the last thing teams think about. They're often the first thing that breaks on launch. Test every form, every notification, every integration before going live.

Building without a redirect plan. Same as every other migration: 301s from every old URL to its new equivalent, before launch, no exceptions.

Not budgeting for ongoing Webflow updates. WordPress hosting is cheap; the cost is in plugin licenses and maintenance. Webflow flips this. Hosting is more expensive but maintenance drops to near zero. The total cost of ownership usually favors Webflow for small-to-mid marketing sites, but it's worth running the numbers.

Picking Webflow because it's "easier" without testing it. Webflow is easier than WordPress for designers. It's not necessarily easier for content editors who've spent years in the WordPress block editor. Have your team try Webflow's editor before committing.

A real conversation we have a few times a month: a client on Drupal calls us because they're tired. Tired of paying for specialized Drupal devs every time they want a small change. Tired of the editorial interface their team finds unintuitive. Tired of the maintenance overhead. They want to know if WordPress is the answer.

Sometimes it is. Sometimes it isn't. Here's how we actually think about it when a real client asks.

The honest case for moving from Drupal to WordPress

Drupal is a powerful, structured CMS. WordPress is an easier, more flexible CMS. Both statements are true. The question for any individual site isn't which is better in the abstract. It's which one matches the way your team actually works.

WordPress wins for a Drupal site when:

• Your team is small and non-technical. WordPress's content editing experience (Gutenberg, ACF, classic editor) is something most marketing managers can use without training. Drupal's admin UI requires a learning curve that compounds with every new staff member.
• Your content model is reasonably simple. Pages, blog posts, maybe a staff directory, maybe case studies. If that's the shape of your site, WordPress with ACF (Advanced Custom Fields) handles it cleanly without the structured-content overhead Drupal brings.
• Your developer pool is the bottleneck. WordPress devs are easier to find, cheaper per hour, and faster to onboard than Drupal devs. For organizations that depend on agency partners or freelancers, this is a real ongoing cost difference.
• Plugin ecosystem matters more than custom modules. WordPress has a larger plugin ecosystem with strong solutions for SEO (Yoast, RankMath), forms (Gravity, WPForms), e-commerce (WooCommerce), membership (MemberPress), etc. Most of what custom Drupal modules do, WordPress plugins do off the shelf.
• Long-term maintenance is what's killing you. Drupal core upgrades are bigger events than WordPress core upgrades. Drupal contrib modules go through dependency churn. WordPress is just steadier on the maintenance side.

When you should stay on Drupal

We don't recommend WordPress when:

• You have multi-site needs. Drupal's multi-site architecture is more mature than WordPress Multisite, especially for organizations with shared content models across many sub-brands or regional sites.
• You have heavy structured content. Government sites with strict content typing, university sites with thousands of program pages and faculty bios, enterprise content systems with complex taxonomies. Drupal's content architecture is genuinely better for this.
• You have enterprise compliance demands. Federal accessibility audits, government security reviews, FedRAMP-style processes. Drupal has deeper roots in this world. The community and Acquia ecosystem are built around it.
• Your custom modules represent significant business logic. If you have years of investment in custom Drupal modules that encode real product or process knowledge, migrating away from Drupal means rewriting that logic. Sometimes that's worth doing. Often it isn't.
• You're on a multi-step editorial workflow. Drupal's content moderation and workflow tools (especially with Workflows + Content Moderation + Workspaces) are more sophisticated than WordPress's out-of-box equivalents.

If two or more of these apply to you, the answer is probably to stay on Drupal and do a D10 or D11 migration instead.

What the migration actually looks like

When we migrate a Drupal site to WordPress, here's the rough sequence:

Phase 1: Audit and content map

We inventory the source site. Every content type, every taxonomy, every node, every user role, every custom module, every integration. Then we map each piece to its WordPress equivalent.

• Drupal content types become WordPress custom post types (via ACF, Pods, or CPT UI)
• Drupal taxonomies become WordPress custom taxonomies (similar architecture, just different names)
• Drupal fields become ACF fields on the equivalent post types
• Drupal users and roles map to WordPress users with role plugins (Members, User Role Editor) where finer-grained control is needed
• Drupal views become WordPress queries, usually wrapped in custom block templates or page builder modules

Phase 2: WordPress build on staging

We provision a fresh WordPress install on a staging environment (staging.yoursite.com or similar). Theme work happens here, against a clean install. The new design is built (or the existing design is ported, depending on scope).

Phase 3: Content migration

This is where the rubber meets the road. The content moves over via:

• Custom migration scripts that read Drupal's database directly and import into WordPress's
• WP All Import for simpler migrations with reasonable content volumes
• Direct database mapping for very large sites where script efficiency matters

Embedded media gets migrated to WordPress's media library. Internal links get rewritten to point to the new URL structure. Featured images, alt text, metadata: all preserved.

Phase 4: Redirect map

Every old Drupal URL gets a 301 redirect to its new WordPress equivalent. We build this map as a spreadsheet, then implement it via either Apache/Nginx server config or a WordPress redirect plugin (Redirection, Yoast, or Rank Math). This is the single most important step for SEO preservation.

Phase 5: SEO rebuild

Meta titles, descriptions, schema markup, sitemap.xml, robots.txt: all rebuilt on WordPress and resubmitted to Search Console on launch day. This is where you decide whether you're keeping your rankings or losing them.

Phase 6: QA and sign-off

Cross-browser, cross-device, accessibility pass, performance benchmarking. The client walks every page on staging and signs off before anything promotes to production.

Phase 7: Launch and monitoring

Coordinated DNS cutover, sitemap resubmit, monitoring window of 14 to 30 days post-launch. Search Console comparisons. Form submission tests. Error log monitoring.

Timeline reality

For most Drupal-to-WordPress migrations we ship:

• Small marketing site (under 100 pages, simple content model): 4 to 6 weeks
• Mid-size content site (200 to 1000 pages, multiple content types, custom views): 6 to 12 weeks
• Large or complex site (multi-site, member areas, deep taxonomy, custom integrations): 12 to 20+ weeks

The single biggest variable isn't content volume. It's the number of custom Drupal modules and how much business logic they encode. A site with 5,000 nodes and zero custom modules migrates faster than a site with 200 nodes and twelve custom modules.

Cost reality

Honest ranges from real engagements:

• Small migration plus light redesign: $5,000 to $15,000
• Mid-size migration with theme rebuild: $15,000 to $40,000
• Complex migration with new content architecture: $40,000 to $100,000+

Migration plus redesign is almost always more cost-effective than migration alone, because by the time you're touching every page anyway, refreshing the design adds modest cost relative to total project hours.

Common mistakes

Trying to do it in-house without migration experience. Drupal-to-WordPress migration has specific edge cases (entity reference handling, taxonomy term re-mapping, file system migrations) that look simple until they break in production. Teams attempting their first one routinely take 2-3x longer than estimated.

Skipping the redirect map. This is the SEO killer. Without 301 redirects from every old URL to its new equivalent, you lose ranking on launch day and may not recover for months. The redirect map is non-negotiable, even if it's tedious.

Underestimating content rebuild. Migrating raw content is one thing. Cleaning it up, fixing internal links, replacing broken embedded media, updating outdated information: that's another job. Budget for it.

Trying to preserve every Drupal-specific behavior in WordPress. WordPress isn't Drupal. The migration is also a chance to simplify. If you find yourself rebuilding custom Drupal-style functionality on top of WordPress, ask whether you should have stayed on Drupal.

Launching without a 30-day monitoring window. Search Console rankings drift for the first few weeks after a migration. Form submission rates change. Error logs surface edge cases. Don't disappear the day after launch.

Drupal 7 hit its final end-of-life date in January 2025. If your site is still on it, this isn't a "we should probably get to that" problem anymore. It's a real one. The site is running, customers are visiting, the CMS still loads. But under the hood, every week that passes adds another small layer of risk that compounds.

This is a working agency's take on what to actually do about it. No platform evangelism, no fear tactics, just the options laid out the way we'd lay them out on a discovery call.

What "End of Life" actually means

When Drupal Security Team support ends, three things stop happening:

1. No more security patches. Vulnerabilities discovered in core or contrib modules don't get fixed.
2. No more module updates. The Drupal community stops maintaining D7-compatible versions of contrib modules. Many already have.
3. No more PHP support alignment. Newer PHP versions stop being tested against D7. Eventually your hosting provider deprecates the PHP version your site requires.

The site keeps working. Until something breaks. And when it breaks, the fix isn't "update the module." The fix is "migrate."

For sites handling forms, payments, member data, or anything regulated, the security exposure is the part to take seriously. For a low-traffic brochure site running on a shared host with no logins, the timeline pressure is softer. But the destination is the same.

The three realistic paths

When clients call us about Drupal 7 sites, we walk them through three options. There's no fourth option called "stay on D7 forever." That ship sailed.

Path 1: Migrate to Drupal 10 or 11

The natural next step. You keep your content model, your taxonomies, your editorial workflows, your URLs, your SEO. Drupal 11 is the current major version (released August 2024). Drupal 10 is still actively supported and is often where we land sites that aren't ready for 11's tighter requirements (newer PHP, dropped older library support).

This path makes sense when:

• The site has a legitimate need for Drupal's structured content model. Government, higher ed, multi-site networks, complex taxonomies, editorial workflows with multiple roles.
• You have an in-house team or budget for ongoing Drupal development.
• The custom modules you depend on have D10/D11 equivalents (or are simple enough to rewrite).
• Compliance requirements (accessibility, security audits) make Drupal's structured approach an asset.

Path 2: Migrate off Drupal entirely

For a lot of sites that ended up on Drupal 7 because that's what was "best in class" twelve years ago, the honest answer is: WordPress, Webflow, or Shopify can do most of what you actually need now, with less maintenance overhead.

This path makes sense when:

• The site doesn't really use Drupal's advanced capabilities. It's mostly pages, blog posts, a contact form, maybe a simple staff directory.
• Your team wants to update content without filing a ticket.
• Ongoing Drupal hosting and dev costs are out of proportion to the actual functionality.
• You're a small content team without dev resources.

We've shipped this exact migration path many times. WordPress is usually the destination because it preserves the most flexibility (custom post types, ACF, plugin ecosystem) while dramatically lowering the maintenance burden.

Path 3: Rebuild from scratch

If the design is also dated, the content model is wrong, and the existing site doesn't represent the brand anymore, sometimes a clean rebuild is faster than a migration. We don't recommend this often, but it does happen, especially for organizations that grew significantly since the original D7 build and need a different content architecture entirely.

How long does it actually take

Honest ranges based on the migrations we've shipped:

• Small brochure sites (under 50 pages, no custom modules): 4 to 6 weeks
• Mid-size content sites (50 to 500 pages, some custom views and blocks): 6 to 12 weeks
• Complex multi-site or membership sites (custom modules, integrations, member data, multiple content types): 12 to 20+ weeks

The variable that hits hardest isn't content volume. It's custom modules. Every custom D7 module needs to either find a D10/D11 equivalent, get rewritten as a D10/D11 module, or be retired entirely. That's where weeks turn into months.

What gets preserved

Done right, a migration preserves:

• Every URL via 301 redirects from old to new structure
• All content with formatting, embedded media, and metadata intact
• Search rankings with no measurable drop in 30-day Search Console comparisons
• User accounts including hashed passwords (yes, we can carry those over without forcing a reset)
• Editorial roles and permissions mapped to the new platform's equivalents
• Schema markup, sitemap.xml, robots.txt rebuilt and resubmitted to Search Console post-launch

What doesn't survive (be ready)

These are the things we flag in every D7 migration scoping call:

• Custom D7-only modules with no community equivalent. These get rewritten or retired.
• Theme work tied to the D7 templating system. PHPTemplate is gone in D10. The theme either gets rebuilt in Twig (D10/11) or replaced entirely.
• Old contrib modules that never got D10 versions. Some you replace with newer alternatives. Some functionality just doesn't exist anymore (and often it shouldn't).
• Heavy reliance on jQuery 1.x. Modern Drupal uses jQuery 3+ and increasingly favors vanilla JS. Custom front-end behavior may need refactoring.

Cost reality

Without a discovery call we can't quote a number. But honest ranges from real engagements:

• Small migration to D10/D11: $15,000 to $30,000
• Mid-size migration with redesign: $30,000 to $75,000
• Complex multi-site or enterprise migration: $75,000 to $250,000+

Migration off Drupal entirely (to WordPress, Webflow, etc) usually lands $5,000 to $20,000 lower than equivalent D10/D11 migration, because the destination platforms require less specialized engineering. But you trade that for ongoing platform differences that may matter to your team.

Common mistakes we see

Treating it as a "lift and shift." Migration isn't copy-paste. It's an opportunity to fix the content model, retire dead pages, consolidate duplicate content types, and clean up taxonomies. Teams that skip this end up with the same problems on a newer platform.

Running D7 and the new site in parallel for too long. A short overlap during QA is fine. Months of dual-running is a recipe for content drift, SEO confusion, and editorial fatigue. Pick a launch date and commit.

Not budgeting redesign time. A D7 site's design is twelve years old at this point. Migrating the same theme to D10 keeps it functional but ages it visibly. Most clients budget for migration but underbudget for design refresh.

Forgetting the redirect map. Every old URL needs a 301 redirect to its new equivalent. Without this, your SEO drops the day you launch. The redirect map is non-negotiable.

Doing it in-house without migration experience. D7 to D10 migration has specific edge cases (entity reference handling, view modes, file system changes) that consume real time when teams are learning them mid-build. Agencies that have shipped this before move 2-3x faster.

What we'd do if we were on your side of the table

1. Audit first. Inventory every page, post, custom content type, custom module, and integration. Don't migrate what you don't need.
2. Decide the destination. D10/D11 if Drupal still earns its keep. Otherwise, talk to someone honest about WordPress or Webflow.
3. Map redirects before you build. Old URL structure to new URL structure, in a spreadsheet, before any dev work starts.
4. Build on staging. Never on the live site. Coordinated push only after end-to-end QA.
5. Don't ship without testing every form, every login flow, every paid action.
6. Resubmit your sitemap to Google Search Console on launch day. Watch rankings for 30 days.