The hard part wasn't the migration: BERING from Shopware to Shopify

We moved BERING's store from Shopware to Shopify and completely reworked the storefront. Instead of one store serving every market, there are now two – European and American. The European one runs several markets on its own through Shopify Markets. Two of the problems we hit along the way were not the usual kind:

• Assembling product variants out of separate products, because the client's catalogue isn't structured the way Shopify expects;

• Building custom logic into a ring configurator we had no source code for.

BERING was founded in Denmark in 2008. The brand makes watches and jewellery in Danish minimalism with Arctic motifs. It sells online, through partners and in branded stores across a number of countries. At the time of the migration the store's database held 270,320 registered accounts.

The store ran on Shopware, and over the years that implementation stopped holding up to what was being asked of it. The design had aged, the storefront had fallen behind the way premium eCommerce looks and behaves today, and the site was noticeably slow.

But that wasn't the main thing. The client put the pain simply: the site is slow, it's hard to configure, and the platform's limits make it almost impossible to develop further. So this wasn't about a particular bug. The store had hit the ceiling of its platform.

BERING had been looking at Shopify for a long time: the platform is more flexible and does more for ecommerce, and the brand wanted to be on it. What tipped it was the Shopify project we had already delivered for GLOCK, for the same partners. When the question came up of who should do BERING, the answer was already clear.

The task in one sentence: move the store from Shopware to Shopify, rework the storefront, and at the same time simplify what had been getting more complicated for years — support for several localized markets.

• The store can't go down. Orders come in every hour across every time zone – there is no quiet hour when you can switch the store off. That shaped both the release plan and the way changes ship today.

• A third-party ring configurator with no source code. The site runs an off-the-shelf Ring Configurator that reached us already compiled. We had no access to the source, and the behaviour had to change.

• A catalogue that doesn't fit Shopify's variants. In the client's data, every product variant exists as a separate product. To Shopify those aren't variants – they're different products.

Multi-market looks like configuration. It is actually an architectural decision. In a multi-market setup the difference between markets rarely comes down to language and currency. Usually it is also assortment, pricing, tax and legal requirements, logistics, and different content on the same pages.

When all of that lives in one store, every change becomes a question of how it looks in all the other countries. Split it across several stores and you get the opposite problem: product data has to be kept in sync by hand. So the real question on this project wasn't how to move the catalogue. It was where to draw the line between stores so that neither of those problems becomes the dominant one.

We proposed drawing the line between regions, not between countries. The logic runs like this. One store for every country looks cheaper – but only for as long as every market wants the same thing. The EU and the US needed to be run differently.

Keeping that in a single configuration means every change for the US gets checked against every European market, and the other way round. Splitting them lets the two regional teams work independently: content, merchandising and theme releases go per store.

A separate store per country would have been overkill, so inside Europe the markets run on native Shopify Markets: one store, several markets, their own languages and currencies. There was one price to pay for that choice: product data now has to be kept consistent across two stores. We closed that with a custom app.

• Multi-store architecture, EU / US. Two independent Shopify stores with separate theme releases and separate content management.

• Shopify Markets and localization. Languages, currencies and localized content inside the European store, with translations handled in the admin.

• A custom Shopify app. Keeps product data consistent across both stores, running on a schedule through the Admin API.

• A custom Shopify theme for the new design. Content and settings live in the admin, so the client changes them without a developer.

• The ring configurator. The existing Ring Configurator, adapted to the new design.

• SKU-based links between products. The mechanism that shows separate products as variants of a single item. Details in the technical section below.

Before launch we brought the client a set of CRO changes to the design – from what we had seen on other ecommerce projects, not because anyone had asked for them. The client approved them and they shipped with everything else.

The most visible ones are on the product page and in the catalogue:

• Show sold-out items as sold out instead of hiding them;

• Keep the size picker visible at all times;

• Make collection browsing continuous instead of paginated.

The first thing we had to work through was the product model. In Shopify a variant is part of a product: one item, with sizes, colours and materials inside it. In BERING's data, every variant is a separate product with its own SKU. The obvious move is to rebuild the catalogue and assemble real Shopify variants. We didn't take it.

That would have meant rewriting the client's product model – no longer a migration, but a separate job with risks of its own. So we did the opposite: we left the products separate and moved the links between them into a layer of their own.

How it works:

1. A script groups products by SKU structure.

2. The links are written into the products-list metafield – a list of product references, so each product knows which other products are its neighbours in the same variant group.

3. The storefront reads that metafield and renders the group as a single product with a variant switcher.

On the storefront, a group of separate products looks like an ordinary product card with a variant picker. In the admin nothing changed: each variant is still its own product, with its own SKU and its own page. A side benefit: the grouping is defined by data, not by code. To change it you recalculate the links – the theme stays untouched.

The ring configurator on the site is an off-the-shelf product that reached us already built and minified. There was no source code, and the behaviour had to change – bring the configurator in line with the new design and make choosing easier for the shopper.

We built our own logic into the minified code with targeted insertions, without rewriting the bundle. Not the most elegant solution, but it does exactly what is needed and doesn't add a second configurator to maintain. There is a price for that: every vendor update to the configurator has to be re-checked.

Multi-market is the part of the project that touches everything at once: the theme, the content, localization and the release process.Inside the European store, each market has its own language, currency and its own set of content – on native Shopify Markets, with no separate build per country.

Translations are handled in Translate & Adapt – in the admin, by the client's content team, not in theme code. The machine-translation layer is covered by T-lab.

The custom theme was written from the start so that content is a parameter rather than a constant: copy, curated lists and settings live in metaobjects and metafields. That is what lets the client change page content per market without a developer.

Automations moved into Shopify Flow, and search and filtering onto Shopify Search & Discovery. We deliberately built no service of our own for any of this: whatever the platform's native mechanisms cover, we let them cover.

One of the key jobs after the split was syncing product data between the stores. Duplicating it by hand across two admins would have raised the risk of drift. We wrote a custom Shopify app for it. It calls the Admin API, runs on a schedule (cron jobs) and moves product data between the stores.

Data-collection consent was set up separately. Google Consent Mode sits in default-denied, and the consent banner loads ahead of any tracking.

Analytics tags don't fire until the user has made a choice; after that, the consent state updates to match their decision. For a brand selling into European markets, this is something you need to handle from day one.

Platform and native capabilities: Shopify, Liquid, JavaScript, HTML, CSS, Shopify Markets, Shopify Translate & Adapt, metaobjects and metafields, Shopify Flow, Shopify Search & Discovery, Shopify Admin API.

Built by us: custom Shopify theme, custom Shopify app for product data sync (Admin API + cron jobs), SKU-based product mapping through the products-list metafield, custom insertions into the minified Ring Configurator code.

Apps: T-lab AI-language translate, Ring Configurator (third-party).

Integrations: Google Consent Mode.

Migrated from: Shopware.

The store went live recently, so some of the numbers – sales, organic, conversion – simply aren't there yet. Below is only what has been measured or is a matter of fact.

• The storefront is roughly 20% faster than the previous Shopware store.

• Clearer choices on the product page. Out-of-stock items are shown as out of stock rather than hidden; the size picker is always visible.

• Continuous catalogue browsing – loading more instead of paging through.

• Localized content per market, rather than one text for all of Europe.

• Consent handled properly: the banner appears before the analytics tags, not after them.

• Content, translations and merchandising run without a developer. Theme customizer, metafields, Translate & Adapt – all in the Shopify admin.

• Regions release independently. An update for the EU doesn't wait on the US, and the other way round.

• No self-hosted platform to maintain. Instead of hosting Shopware and a set of plugins themselves – Shopify's managed infrastructure.

• Product data between stores is synced by an app, not by a person who has to remember to duplicate a change in the second admin.

Because orders come in around the clock, the move had to be planned without a maintenance window. Go-live itself was a planned DNS switch, removing the store password and an immediate smoke test: we checked a real purchase path on production, not on staging.

Since launch, theme changes are prepared in a dev theme, go through QA and roll out per region – so they can be seen before release and rolled back if something goes wrong. The project is in maintenance now. The next step is to collect the first months of data and look at the numbers that didn't exist at release.