Migrating from Shopware to Shopify without losing rankings

Shopware runs on your own infrastructure: your server, your database, direct access to every template line and every plugin. Shopify is hosted and does not give you that access. The move therefore does not simply swap one storefront for another; it shifts the line between what you configure and what you write yourself.

The catalog itself almost always travels well. Products, prices, images, categories and customer accounts can be exported and read back in. The hard parts are the places where Shopware gained logic through plugins or custom templates: configurators, pricing rules, B2B approvals, extra fields inside the ordering flow.

Three things drive visibility: every indexed address keeping a destination, the destination genuinely answering the same question, and the new page being served cleanly. Shopify handles the technical side, but it imposes a fixed path scheme that you cannot rename at will.

Shopware has two layers of addresses: the technical routes and the SEO URLs layered on top. In Shopware 5 products run technically through a detail path with an article ID, in Shopware 6 through a detail path with a product ID. Both systems also generate readable addresses that are flat or carry a category path, depending on configuration.

Shopify files every product under a product prefix and every category under a collection prefix. Those prefixes are fixed. A flat Shopware address without a prefix cannot be reproduced in Shopify, so it inevitably becomes a new address. That is exactly why the redirect list is part of this migration rather than cleanup afterwards.

Collect addresses from several sources, not just the sitemap: Search Console, server logs, your analytics tool and the SEO URL table in the Shopware database. Only the combination reveals which old technical routes are still being called and which addresses from earlier rebuilds still carry external links.

A workable concept answers one question per old address: which new page serves the same intent. Where no such page exists, the next best answer is the matching collection, not the homepage. Bulk redirects to the homepage are treated as a soft error by search engines and pass no signals along.

Redirects are set as permanent, meaning status code 301. Chains and loops are the most common failure: if an old address points to an intermediate address first and only then to the final destination, you waste crawl budget and risk the chain breaking during a later rebuild. Resolve every chain before the cutover.

Shopify keeps redirects as a list of paths that you can import from a file. Two limits are worth knowing early: addresses that differ only by query parameters cannot be separated reliably that way, and the list applies to the domain pointing at Shopify. Old subdomains need their own rule in front of it.

Shopware separates filterable properties, custom fields for everything else, and variants that can be built from any number of characteristics. Shopify has options, variants and metafields. Mapping between them is therefore not a translation but a series of decisions about what becomes a variant and what stays information on the product.

The hardest limit is the option dimensions: Shopify allows at most three per product. An assortment with color, size, material and finish will not fit without restructuring. The usual answer is to turn the weakest characteristic into separate products and link them in the theme. That is a decision with consequences for navigation and reporting.

Properties move into Shopify as metafields with a clean definition. They only become filterable once they are also set up as filters. Use the migration as a chance to review the stock: in grown Shopware catalogs, many properties are used exactly once and carry neither a filter nor a display.

In Shopware, prices often hang off customer groups, and tiers sit as rules on the product. Shopify solves this differently: prices for specific buyers come from catalogs assigned to a company profile. That is cleaner to maintain, but it is a different model: a customer group is no longer a field on the customer; it is an assignment.

These B2B features belong to Shopify Plus. Anyone running a handful of customer groups on stock Shopware today faces a real decision: move up the plan, model the pricing logic through an app, or deliberately keep the B2B business outside the storefront. All three are defensible, but they cost different things.

Work out early how many price variations are genuinely in use. Grown Shopware installations often still carry groups nobody has touched for years. A migration is the best moment to shorten that list, because every group you carry across later has to be maintained and tested as its own catalog.

Shopware works with sales channels and subshops that can each have their own language, currency and sometimes their own catalog. Shopify bundles this into markets: a market defines which countries, currencies and languages belong together, and the theme decides how language and region appear in the address.

The practical difference sits in the catalog. If your Shopware subshops carry different assortments, you have to decide whether to model that through market catalogs in Shopify or through separate stores. Separate stores give more freedom and cost more upkeep; one store with markets keeps the data together but demands discipline around visibility.

For visibility, what matters is that language versions reference each other cleanly and that the redirect list differs per language path. A German product page must not point to the English version just because that destination was found there first. Check this mapping per language, not once for the main catalog.

The checkout belongs to Shopify. You can extend it, but you cannot build it freely, and the deeper extension options require Plus. If you added steps, fields or approvals to the ordering flow in Shopware, review each of those additions before migrating and ask whether it is still needed or merely a habit.

The address structure is fixed as well. Product and collection prefixes cannot be removed, and a fully free path hierarchy across several category levels is not part of the Shopify standard. None of that harms visibility as long as the redirects are right, but it is something you should know beforehand and decide once.

The honest way to handle these limits is to name them before the project rather than rebuild around them later. Each case has three answers: solve it differently within the standard, rebuild it through an app or custom extension, or drop the process. The third answer is right more often than it sounds at kickoff.

The sequence follows a simple rule: decide first, then import, then build. Import the catalog before the option model is settled and you will import twice. Build the theme before the catalog exists and you build against sample data, only to find late that filters and listings look different against real stock.

Redirect work runs alongside catalog work, not after it. As soon as the product handles in Shopify are fixed, you can populate the list and validate it against the destination pages automatically. That leaves only the import of a finished list on cutover day instead of hunting for destinations under time pressure.

The cutover is the moment the domain points at Shopify. Put it in a low-traffic window with no campaign running, and make sure the redirect list is already loaded before the domain is switched. One hour without redirects produces exactly the error pages you were trying to avoid.

Right after the switch, a handful of checks matter: reachability on the primary and redirecting domains, a correctly served sitemap, a working test order, correct data handover to tracking and ERP. After that comes a phase of watching rather than intervening. Search engines need time to absorb the new address scheme.

In the weeks that follow, the most useful report is the list of error pages. Every old address showing up there is a gap in the redirect list and can be filled in. Positions fluctuating for a while after an address change is normal; a destination page that stays empty is not.