Shopify vs OXID eSales

OXID eSales is a shop system from Freiburg that you run yourself. Server, database, PHP version and deployment sit with you or your host. Shopify delivers that same layer as a service: you get storefront, checkout and admin, but no access to the infrastructure underneath.

This difference decides more than any feature list. Running it yourself, you determine where the data sits, when an update goes in and which library runs in which version. In exchange you carry availability, security and load peaks yourself, with your own staff or a partner on call.

With Shopify that layer disappears. Scaling on peak days, security patches and platform updates happen without your involvement. The price is commitment: checkout logic, data storage and release dates follow the vendor. Anyone who has to justify where order data sits should settle that question early rather than late.

OXID provides a Community Edition as open source, with commercial editions above it offering a wider feature set and vendor support. We deliberately give no figures here, because they change. The structure matters more: a free download is not yet a cost model.

Self-operation includes hosting, monitoring, backups, security updates, test environments and the developer time for version jumps. None of these appear in a licence overview, yet they show up in your budget every month. They are predictable once you have captured them properly, and expensive when you have not.

Shopify bundles operations, scaling and updates into a subscription, joined by transaction-based components and the apps your business needs. Costs grow with revenue rather than with infrastructure. The two models only become comparable across several years, not across a single annual invoice.

OXID is a PHP system whose classes you can extend. Modules reach straight into price calculation, ordering flow and data model. Almost any requirement can be built that way. The price sits in the future: every extension of the core has to be checked again at every version jump.

Shopify turns that around. The core stays untouched and extensions attach through apps, APIs and defined extension points. Updates therefore rarely break anything, but there are limits: deep intervention in the checkout only opens up on the Plus tier, and some bespoke logic cannot be modelled at all.

OXID has its strength in B2B across the German Mittelstand. Customer groups, tiered and negotiated prices, approval workflows, several tenants under one installation and tight coupling to an ERP have been everyday practice there for years rather than a later addition. The system shows it.

Shopify models B2B through company profiles with assigned catalogues, payment terms and ordering permissions. That carries many trading models cleanly, but it belongs to the Plus tier and is therefore a question of contract level. Highly idiosyncratic pricing logic or multi-stage approval chains need extra work through apps or custom extensions.

Decide on your actual processes, not on feature lists. Take the ten most frequent operations in sales and check each one individually against both systems. Whatever ends up in more than two special cases is the real cost driver of your project and belongs on the table.

Shopify layers markets over one storefront: languages, currencies, prices and domains per market, but one theme base and one catalogue. That keeps maintenance low as long as the markets carry a similar range. Strongly diverging catalogues per country, by contrast, quickly lead to compromises.

OXID works with tenants and subshops. Each country or brand gets its own configuration, its own range and its own rules. That is more powerful when markets genuinely differ, and more laborious when they do not: every change wants to be repeated and tested in every tenant.

OXID has a smaller partner and developer network than Shopware or Shopify. That is not a judgement on quality but a question of resources: there are fewer ready-made extensions, fewer publicly documented solutions and a tighter market when you need to refill a role or change service provider.

With Shopify the situation is reversed. The market for apps, themes and developers is large, which creates choice and evaluation work in equal measure. You shift part of your dependency from your own code onto third parties whose roadmap and pricing you do not control.

A move is worth it when operations absorb more attention than the business does. Typical signs: a version jump has been postponed for months, changes to the shop hang on one single person, and every campaign starts with the question of whether the infrastructure will survive the rush.

It argues against a move when your core processes sit deep in the code and belong there. Anyone binding checkout to bespoke rules, keeping order data in house for compliance reasons or running an ERP without an API will not find a fitting answer in Shopify, only detours around one.

Between those two poles sits the normal case. A sober cut helps there: which bespoke logic is genuinely business critical, and which is merely historical. After that review, less usually remains than the discussion suggested, and the move becomes something you can plan.