Shopware shops
What a Shopware shop costs and how long it takes comes down to three things: the pricing logic, the connection to your ERP and the amount of data that has to come across from the old system. Design and page count come after that. Sharpness Solutions GmbH in Oldenburg builds Shopware 6 shops for retailers and manufacturers, B2B and B2C alike: as a new build, as a relaunch or as a move from Shopware 5, WooCommerce or Magento. This page is for the time before the quote. It explains which edition and which hosting fit, how a project runs and how to recognise an implementation that will survive the next update. The current version is Shopware 6.7; a new shop starts on that line.
Hardly anyone starts from scratch. There is usually an old shop, an ERP, a sales team with terms that are not fully written down anywhere, and a deadline that keeps getting closer. Six starting points come up again and again. What they have in common: the expensive decisions are made before the quote, not during the project.
The quotes are far apart because each one assumes a different scope. Without a feature list you are comparing assumptions, not prices. A quote that says nothing concrete about pricing logic, ERP integration and data migration leaves open exactly the three items that set the price.
Shopware 5 has had no manufacturer maintenance since the end of July 2024. No update leads from there to Shopware 6 — it is a new build that takes the data along: theme, extensions and interfaces are built again. Cost the move as a version jump and you get a figure that falls apart during the project.
More products, more customer groups, tiered prices, an ERP that needs connecting. In WooCommerce each of these requirements means another plugin; a Magento installation on an old version turns even the next update into a project. The question then is not which system is better, but which one will carry the next few years.
The shop shows different prices from the field sales quote, approvals are missing, and the key account wants to order from its procurement system. A business customer only uses a shop if it finds its own terms there. A wrong price costs more trust than any load time.
The old shop has built up rankings over the years, and a change of system gives categories and filters new addresses. Without a complete redirect list, the very pages that used to bring in customers are missing on switch-over day. That loss is avoidable — but only if it is planned before go-live.
Since 28 June 2025, online shops through which consumers buy have had to be accessible under Germany’s Accessibility Strengthening Act (BFSG). Retrofitting a grown theme full of page-builder layouts and third-party widgets is laborious. A relaunch is the cheapest moment to build accessibility in from the start.
Three drivers decide what a Shopware 6 shop costs: the B2B pricing logic, the ERP integration and how much data has to be migrated. Pricing logic means: does one price apply to everyone, or does the shop calculate per customer, customer group and quantity — with tiers, special prices at item level and terms that come from the ERP? ERP integration means: which data flows in which direction, how often, and what happens when a sync breaks off halfway? Data migration means: how many products, variants, customer accounts and orders come across, and what state are they in? The number of products alone rarely drives the price. The quality of the data does.
Sharpness (Oldenburg) calculates in person-days, not package prices. Audit, concept, theme, interfaces, data migration and testing are separate items in the quote, so you can see what you are paying for and move or drop individual items. Alongside the project there are running costs that appear in no project quote but belong in every budget: the Shopware licence, depending on the edition; extensions from the Shopware Store, which since 28 December 2023 have only been available as rental licences; hosting and maintenance; payment providers’ transaction fees; and your own staff time for data upkeep, testing and training. A shop is only cheap if it is still cheap in its third year of operation.
Duration follows the same logic, plus one factor that only you control: how quickly data, decisions and approvals arrive from your side. A shop project is planned in months. We give a reliable schedule and a price after the assessment, not on the phone. For an existing shop, that assessment is a findings report on data, extensions and interfaces — a clearly bounded first piece of work, at a fixed price we put in writing before we start. For a new build, it is a requirements workshop followed by a concept. Ask us for the hourly rate and for what the findings report costs.
The free Community Edition will do as long as the standard plus your own plugins covers what you need. That holds for some B2B shops too: customer groups, tiered and customer-group prices and the Rule Builder for terms are all part of the open core. A paid plan pays off if you want company accounts, order approvals and quote processes to come with the product instead of being built for you — Shopware supplies them as B2B Components — or if your contracts require manufacturer support. Shopware’s price overview puts the entry points at Rise from 600 euros and Evolve from 2,400 euros a month, excluding VAT. The B2B Components are not included in every paid plan, so check the scope before you book. The comparison is licence against custom development, over the lifetime of the shop.
Shopware Cloud takes servers and updates off your hands and draws a line in return: no shell, no classic plugins. Extensions run there only as apps: the logic lives on a separate server and reaches the shop via the Admin API, the Store API and webhooks. For a shop close to the standard, that is a relief. For a shop that reaches deep into checkout, pricing or the data model, it is a hard limit — one you should know about before the decision, not after.
Self-hosted means someone runs PHP, the database, cache, search index, message queue, staging system and backups — permanently, not just for the launch. At Sharpness this runs on our own Proxmox VE clusters in the Hetzner data centre in Falkenstein, Germany, each customer environment on its own, with Valkey or Redis and OpenSearch where catalogue size and load justify them. After go-live we take on maintenance under a service level agreement — with a response time of 24, 8, 4 or 2 hours, billed as a flat monthly fee per shop, net. Operation and maintenance are then in one hand. We are available Mon–Thu 9:00–16:00, Fri 9:00–13:00 (CET); on-call cover outside those hours exists only with an SLA.
A good Shopware theme extends the standard Storefront instead of replacing it. Colours, typography and components live in a theme of their own; changes are made by overriding specific Twig blocks with sw_extends, not by copying templates, and never in the core. The reason is the next major update: at that point every overridden block must be compared with the new version of the original. The effort behind a theme therefore scales not with how it looks but with how many interventions it makes. A design that works against the Storefront is paid for once when it is built, and again with every update.
For payment methods, shipping carriers, reviews, invoice layouts and marketplace connections there are maintained extensions in the Shopware Store; building your own alongside would be waste. Custom development belongs where your process departs from the standard: pricing, order approvals, configurators, logic from the ERP. Every extension, bought or built, is an item in operations that gets re-checked with every update. An extension that is not installed cannot break during an update. Sharpness — 250+ projects since 1999 — is a Shopware Extension Partner, publishes extensions of its own in the Shopware Store and develops plugins against the intended extension points: events, service decoration, entity extensions.
Payment providers bring their methods as extensions of their own — PayPal, credit card, SEPA direct debit, Klarna, plus multi-method services like Mollie, Stripe or Unzer. In B2B, purchase on account and prepayment carry most of the volume, frequently with a credit limit supplied by the ERP. Two things matter more than the selection: card data never touches your server but goes straight to the payment service provider, and the payment status arrives cleanly in your ERP — otherwise accounting ends up doing rework. Shipping methods and shipping costs are controlled by the Rule Builder, for example by destination country, customer group or basket value. Before go-live, a test order runs through every payment method and every shipping method.
An ERP integration is decided by the question of direction, not by technology: which system owns prices, stock, product texts and customers, and which one only reads? Settle that, and the rest is solid engineering. Technically it runs over Shopware’s Admin API, using its sync endpoint for bulk data, with syncs that log every run and restart after an abort without damaging data. Which ERP sits behind it matters less, as long as it hands out its data through an interface, an export or its database. The effort lies in the state of the data: item numbers, variants, units of measure, price lists, and attributes that today exist only as running text in the product description.
At M&S Armaturen, a B2B shop for industrial valves on Shopware 6, attributes such as nominal size, pressure rating and material are modelled as filterable properties, not as text. Item master data, prices and availability come from the leading systems, and orders go back in structured form. That is the pattern of a B2B shop buyers actually use: the catalogue shows the same state as the back office, and nobody maintains prices twice.
B2B is more than a login in front of a catalogue. It includes customer-specific prices — tiered and customer-group prices via the Rule Builder, per-customer prices from the ERP through the routes intended for them rather than one customer group per customer —, company accounts with several buyers, approvals and budgets. At Diderk Heinje Pflanzenhandel, a plant wholesaler, range and prices only become visible after a vetted registration. At Lijnco, buyers order via OCI punch-out straight from their procurement system; the basket goes back there instead of being placed as an order in the shop. Punch-out via OCI or cXML is not a core feature but an extension or a custom build — which is why it belongs in the scope from the start.
Moving from Shopware 5, WooCommerce or Magento to Shopware 6 is always a rebuild with the data carried over. Products, customers, order history and media come across; theme, extensions and interfaces are built again. From Shopware 5, Shopware’s free Migration Assistant transfers the data — and only the data. Every old function is decided afresh: standard, store extension, custom build, or dropped because nobody uses it any more. Rebuild the old system one to one and you rebuild its old problems with it. The old shop keeps selling until the new one demonstrably works; after every trial run, customers and orders are counted against the old data.
Rankings survive a relaunch when every old address Google knows forwards with a 301 to the page carrying the matching content. The list for this comes from crawling the entire old shop — addresses, titles, texts — not from memory. Category and filter pages lose the most, since their paths change along with the system. The redirect list is checked on the test system before go-live; afterwards we evaluate log files and Search Console and close the remaining 404s. Nobody guarantees position 1. The list only makes sure you keep what you already have.
Since 28 June 2025, Germany’s Accessibility Strengthening Act (BFSG) has applied to online shops through which consumers buy; testing follows EN 301 549 and with it WCAG 2.1 at level AA. Pure B2B shops are generally outside its scope, and services have an exemption for micro-enterprises; whether your case is covered is for a lawyer to decide. Technically, a new build is the cheapest moment: contrasts fixed in the colour system, every component operable by keyboard, forms with labels and understandable error messages. The Shopware 6.7 Storefront has made its accessibility rework the default; a custom theme must not take it apart again. An overlay script replaces none of this.
Process
Send us the address of your current shop or a few sentences about the project: range, customer groups, ERP, target date. You get an initial assessment of which route and which edition fit and what the effort depends on in your case — before the quote, not after it. Phone +49 441 21 21 63 0, Mon–Thu 9:00–16:00, Fri 9:00–13:00 (CET). We work remotely across Germany, with meetings in Oldenburg and the north-west by arrangement.
You describe the project: new build, relaunch or migration, B2B or B2C, which systems are attached, which date is fixed. We tell you whether Shopware 6 fits and which edition is in question. If another system is the better choice, we say that too.
If there is an old shop, we look into its data, extensions, interfaces and URL inventory and write a findings report. For a new build, the workshop settles range, pricing logic, order processes and systems — ideally with the people from sales, warehouse and accounting at the table.
You receive a feature list that draws the line between what is built and what is left out, with a decision for each function: standard, store extension or custom development. Added to that: the effort in person-days per item and a schedule with milestones. Clearly defined parts we offer at a fixed price.
The shop is built in two-week iterations on a test system that is open to you throughout. Approvals are given on the running shop, not on screenshots. The code is kept in a Git repository owned by you; theme, plugins and interfaces are built against Shopware’s extension points.
The data migration runs in trial runs, each checked against the old data. The redirect list is built from the crawl of the old shop and tested on the test system. Before acceptance: a test order through every payment and shipping method, an ERP run, and accessibility checked both automatically and by hand.
The switch-over happens in the agreed window outside your sales peaks, with a backup taken immediately beforehand. Afterwards we keep an eye on log files, Search Console and incoming orders and close the remaining 404s. Then operation and maintenance under an SLA on our servers in Germany, from a single source.
Projects on this system
A selection — not the full client list.
Across the north-west
We work for companies from Wuppertal and Münster via the Emsland and East Frisia to Hamburg and Hanover. Meetings on site by arrangement, the ongoing work remotely. Each region has a page of its own.
The cost depends on three drivers — B2B pricing logic, ERP integration and the scope of the data migration — which is why Sharpness has no package prices. A B2C shop with one price for everyone, no ERP and little legacy data sits in a different order of magnitude from a B2B shop with customer prices from the ERP and a long order history. We calculate in person-days, with separate items for audit, concept, theme, interfaces, data migration and testing. On top come running costs for the licence, store extensions, hosting and maintenance. We name a price after the findings report or the concept; the hourly rate is available on request.
A Shopware project takes months; how many depends on the same drivers as the cost, and on how quickly data and approvals arrive from your side. When coming from Shopware 5, it is the extensions that set the pace, not the product data: no Shopware 5 plugin works in Shopware 6, so each one is replaced or rebuilt. We fix a reliable schedule with milestones in the concept. A go-live date promised before the assessment is a hope, not a plan.
The Community Edition is enough as long as standard features and your own plugins cover your needs; it costs nothing, is open source and includes customer groups, tiered prices and the Rule Builder. A paid plan pays off if you want company accounts, order approvals and quote processes as B2B Components from the manufacturer rather than as custom development, or if you need contractual manufacturer support. Going by Shopware’s price overview, Rise costs from 600 euros and Evolve from 2,400 euros a month, excluding VAT; the B2B Components are not included in every plan. We compare both routes over the lifetime of the shop.
Self-hosted suits you as soon as the shop reaches deep into checkout, pricing, the data model or interfaces; Shopware Cloud suits shops close to the standard that do not want to run anything themselves. In the cloud, the manufacturer takes care of updates and infrastructure, but there is neither a shell nor classic plugins — extensions run as apps with their own app server, via the Admin API, the Store API and webhooks. Self-hosted, every kind of extension runs, but someone has to operate the server, staging and updates. At Sharpness that means our own servers in Germany.
Shopware 6 is the right choice when pricing logic, variants, customer groups or an ERP integration go beyond what a lean system can carry — above all in B2B. For a small range with one price per item and no ERP, it is oversized. WooCommerce is then often cheaper, especially if WordPress is already running, and for a quick start without operating anything yourself, Shopify is an option. A marketplace with third-party sellers and commission accounting also works against Shopware’s data model. We say so in the first conversation, even when the answer is not Shopware.
The move is a new build that takes the data along, not an update: products, variants, customers, orders and media come across, while theme, extensions and interfaces are built again. From Shopware 5, Shopware’s free Migration Assistant transfers the data; it does not transfer functions or appearance. For every old function we decide with you whether it becomes standard, comes from a store extension, is rebuilt or is dropped. After every trial run we count customers and orders against the old data, and the old shop keeps selling until the new one demonstrably works.
Not if every old address Google knows forwards with a 301 to its counterpart in content, and those redirects have been tested on the test system before go-live. The list comes from crawling the entire old shop; category and filter pages are most at risk, as their paths change with the system. After the switch-over we evaluate log files and Search Console and close any remaining 404 errors. Nobody can give you a ranking guarantee, and we do not either. The redirects protect what you have; they do not promise what you want.
Yes, if consumers buy through it: Germany’s Accessibility Strengthening Act has covered online shops that sell to consumers since 28 June 2025. Pure B2B shops are generally outside its scope; but as soon as private individuals can order too, it becomes a case-by-case question for a lawyer to assess. For services, micro-enterprises are exempt: under 10 staff and an annual turnover or balance sheet total of 2 million euros at most. Testing follows EN 301 549, meaning WCAG 2.1 at level AA. We build this into the theme and test both automatically and by hand, with keyboard and screen reader.
In most cases, no: Shopware 6.8 is expected in 2027, Shopware gives no fixed date, and a new shop starts today on the current 6.7 line. What matters is less the version at launch than the way the shop is built. A theme with few overridden blocks and plugins that use only the intended extension points keep the later jump to 6.8 small; changes to the core make it expensive. We have good reason to expect the step to 6.8 to be smaller for extensions than the one to 6.7 — but Shopware has not promised it.
Three things save the most time: settled data ownership, tidy product data and one person on your side who is allowed to decide. Data ownership means it is fixed which system leads for prices, stock, texts and customers. Tidy means item numbers, variants, units of measure and images are consistent, and attributes are not buried in running text. Add your sales terms written down as rules rather than held as experience, access to the old shop, the hosting and the ERP interface, and time for testing on your side — which appears in no quote and still has to be planned.
You recognise a good implementation by the next update remaining a maintenance window rather than turning into a project. In concrete terms: no changes to the core, a custom theme based on the Storefront with as few overridden blocks as possible, plugins built against the intended extension points, and only as many store extensions as necessary. Add a staging system, updates via the command line, interfaces with logging and a test order through every payment method before every go-live. Ask about this when you discuss the quote. Whoever has no concrete answer will make the next major release expensive.
Sharpness runs and maintains the shop under a service level agreement. The levels range from 24 through 8 and 4 to 2 hours’ response time, as a flat monthly fee per shop, net; without an agreement, requests are dealt with first come, first served, within 48 hours, during our business hours of Mon–Thu 9:00–16:00, Fri 9:00–13:00 (CET). The code is yours: the source code sits in your repository, licences and the Shopware account are registered to your company, and the domain is always registered in your name.
Enquiry
A few sentences are enough: new build, relaunch or migration, B2B or B2C, which systems are attached. We come back with questions and an initial assessment — before anyone talks about a quote.