The most dangerous line in your Shopware 5 project isn’t in the shop. It’s in the ERP: a cron job that has been collecting orders every night for years, written by someone who left the company long ago. As long as it runs, Shopware 5 feels stable. That is exactly why it is so tempting to put off the migration, even though the system hasn’t received security updates from the vendor since July 2024.
If you sell directly to consumers and supply retailers at the same time, the shop never stands alone: stock, prices and orders come from the ERP, and sales to retailers run through the same system. Measured against the online market as a whole, D2C is a sideshow: according to the annual presentation by bevh, the German e-commerce association, manufacturers selling direct accounted for 3.4% of German online revenue from goods in 2025. If retail carries your revenue, it must not notice the shop switch. If you only swap the shop here, the interface breaks.
How much breathing room safefive and PHP 8.2 still give you
Security support for Shopware 5.7, the last branch, ended on 31 July 2024, according to endoflife.date. On its developer page, Shopware itself now refers to safefive, and since September 2026 the repository on GitHub has carried a notice that it is no longer actively maintained.
According to its own FAQ, safefive supplies security updates via a plugin for five years from August 2024, billed by net revenue; compatibility patches for newer PHP and MySQL versions come on top as separate downloads. What the offer is not was made clear by co-founder Carmen Bremen back in March 2023 in an interview with maxcluster: no bug fixes, no new features, with the motto “secure, but not keep”. For a transition year, that is a clean offer. As a strategy, it isn’t one.
Then there is PHP. According to its composer.json, the last official version, 5.7.20, allows PHP 8.2 at most, and as of October 2026 the same applies to the safefive fork. According to php.net, PHP 8.2 only receives security updates until 31 December 2026. Art. 32 GDPR requires protective measures in line with the state of the art; how your shop measures up is something to clarify with your data protection officer. From 2027, a shop on 5.7.20 therefore runs without security updates from Shopware on a PHP version without security updates.
We took apart the other day-to-day risks in our article on Shopware 5 in 2026. Here, the focus is on the ERP side, which only comes up in passing there.
What falls away on the ERP side in a Shopware 5 migration
It’s tempting to read “Shopware 5 to 6” like “Windows 10 to 11”. But Shopware 6 was rewritten on Symfony, with an API-first architecture and a separate core, storefront and administration. There is no upgrade path that updates the old shop. You install Shopware 6 from scratch and migrate the data into it.
That makes every Shopware 5 plugin history, the ERP plugin included, along with your theme. According to the migration documentation, old templates can be neither reused nor migrated, Shopping Worlds cannot be transferred, and email and document templates have to be created anew. For manufacturers, one sentence on the same page carries more weight: B2B Suite data cannot be transferred to Shopware 6. Roles, approvals and budgets stored there need their own export.
The destination is a sound choice: according to the EHI survey 2025, Shopware remains the most widely used system among Germany’s top 1,000 shops, with 11.5%.
For manufacturers, the move is an opportunity to question the special customisations that have built up around the ERP over the years, such as a blocking flag that only the old ERP plugin evaluates, or a dealer price hard-coded in the template. In short: you are building a second shop and moving into it. Anyone who budgets this as an update discovers the truth in the third sprint.
One ERP, two channels: why the interface decides the channel conflict
The reflex is obvious: port the old ERP plugin one-to-one to Shopware 6. By that I mean a plugin or script that writes directly into the Shopware 5 database or uses the old REST API, fed over the years with special cases such as tiered prices for dealers, reservations and blocking flags. Technically, it can be ported, but I still advise against it: the copy ties up the budget the new integration layer would need and preserves special cases that only exist because of the old database.
A constructed example: a tool manufacturer with 6,000 items sells D2C through Shopware 5 and B2B through its field sales team, with stock coming from the same ERP. The old plugin pulls a CSV every 15 minutes and writes it directly into the database, while orders go back overnight as XML. Between two runs, field sales reserves the last 40 units of an item, and the D2C shop sells them a second time. In the morning there is an oversell, a cancellation and a dealer who can’t keep their promise.
The topology matters more. Three patterns are common: a plugin in the shop, middleware in between or an integration platform such as Shopware Nexus. A plugin is enough as long as the shop is the ERP’s only external connection.
As soon as a second consumer is added, whether a dealer portal, a marketplace or the PIM, the equation tips: if you route each of these connections through the shop, you turn it into an integration server, and the next platform switch becomes another ERP break. For manufacturers with retail sales, I therefore recommend middleware that holds stock and prices once and distributes them to shop, portal and marketplace.
For the tool manufacturer, this means that stock lives in the middleware, and Shopware 6 receives all 6,000 items as a bulk upsert via the Admin API’s sync endpoint. The dealer portal draws on the same source, and a field sales reservation immediately reduces the available stock in both channels. The ERP collects orders via the Admin API, while the Store API serves the front end (integrations guide).
Direct write access to the database, however convenient it was in Shopware 5, is something I would no longer build. Shopware calls the repositories of its Data Abstraction Layer the recommended way into the database, and only a write through them triggers the indexers.
This is the channel conflict that becomes technical for manufacturers: prices, stock and customer data run through the interface, and that is where it is decided whether retail and D2C get in each other’s way. A survey by techconsult on behalf of SYBIT among 200 consumer goods companies with 250 or more employees in the DACH region (press release of 1 October 2026) fits this picture: 56% see integrating D2C into existing sales structures as a hurdle, and a good third cite conflicts over prices and margins.
Orders, media, customers: where the Migration Assistant meets your ERP
Shopware’s Migration Assistant connects the old shop to the new installation via a connector plugin. It transfers products with variants and translations, customers and orders including their documents, media and SEO URLs.
| Data object | Migration Assistant | Your task |
|---|---|---|
| Products, variants, properties, translations | transfers | check the field mapping against the ERP |
| Customers, customer groups, orders incl. documents | transfers | check customer groups and dealer accounts against the ERP |
| Order, delivery and payment status | premapping during migration | reconcile the status mapping with the ERP |
| Media, reviews, promotions | transfers | clean up folder structure and duplicates |
| SEO URLs | transfers | add redirect mapping for changed paths |
| Payment methods, salutations, delivery times | manual mapping | create in Shopware 6 beforehand |
| Shipping costs | not automatic | create anew |
| Templates, Shopping Worlds, email and document templates | not possible | rebuild |
| Fields from plugins | additional mapping | map yourself |
| B2B Suite data | not possible | handle export and import yourself |
Whatever a plugin held in its own tables in Shopware 5, such as serial numbers, dealer assignments or project prices, the Assistant only knows as additional fields that you map yourself. For manufacturers, this may be exactly the data the ERP also holds.
Shopware 6 manages order, delivery and payment as three separate state machines with a few standard states, extendable via the API (order concept). During migration, the Assistant asks for each Shopware 5 status which Shopware 6 state it corresponds to; only the standard statuses are pre-filled (premapping in the source code). An order status such as “Backorder, delivery date from plant 2 pending” has no counterpart in Shopware 6.
If it already exists in Shopware 5, you assign it in the premapping. If you don’t create a custom state beforehand, all that remains is the closest standard state, such as “In progress”, and the customer sees less in their account than they used to hear on the phone. If only the ERP knows this status, nobody migrates it; then it belongs in the synchronisation from the ERP to the shop.
That is why my advice on the sequence is: first clarify which data will be mastered in the ERP in future and which in the shop, then migrate. Stock that is maintained in the shop even though the ERP knows it is doubly wrong after the migration: two places where it is maintained, two figures, and the dealer sees a different one from the D2C customer.
Roadmap: from the interface list to reconciliation on the first morning
The most expensive mistake a roadmap can make is the order: design first, then the shop, then “connect the interface” as the last item before go-live. For manufacturers, the interface belongs at the start, because it determines which data the shop holds and which it only displays.
It all starts with the interface list. It records every data flow between ERP and shop with direction, frequency and special cases, plus every plugin table with data the ERP doesn’t know. One line looks like this: stock, ERP to shop, every 15 minutes, deduct field sales reservations first. The quote for the migration is built on this list, and your ERP service provider signs it off.
The ERP flows then run against the empty Shopware 6 installation before a single customer has been migrated. Payment methods, delivery times, salutations and shipping costs are set up, the middleware is in place and the theme is built in parallel.
The data migration runs several times. The first full run is a test: you only see mapping gaps such as the backorder status or orphaned plugin fields once real data has passed through the connector. Delta runs transfer only new and changed records, until the last run before go-live only fetches the orders from the last few hours.
For go-live, I recommend an order freeze window of a few hours: the shop accepts nothing, so that the last run misses nothing, while dealer business continues in the ERP. The redirect mapping for changed paths remains manual work; how to do it without losing rankings is covered in our article on shop migration without losing SEO. On the first morning, you reconcile with the ERP whether stock, prices and open orders are correct, which are exactly the figures the tool manufacturer’s oversell hinged on.
On costs, just a frame of reference: our fixed-price page on Shopware migration starts at €15,000 for small B2C shops and puts shops with ERP integration well above that. For manufacturers, a large part of this goes into the interface to ERP, PIM and WMS.
Conclusion: rebuild the integration layer at the same time
The real question for manufacturers is whether you rethink the integration layer as part of the move or rebuild the old plugin in new clothes. If you copy the old ERP plugin, you pay for a complete rebuild and get the old interface back.
My position: rethink it. Start with the interface list, one line per data flow, before anyone talks about the theme. The cron job from the first paragraph can retire, but not so that a new cron job can write the same CSV into a new database. Build your interface so that it also survives the shop after next.