Skylotec

The platform decision had already been made when we joined. Skylotec wasn’t looking for a consultant to help choose a platform, but for a reliable implementation partner. In the end, two things made the difference. First, early designs for the homepage – ambitious, with animations and multicoloured moving typography, anything but trivial technically. Second, and more important for Skylotec, several sessions in which we explained how we work.

Skylotec looks very closely at development practice and software delivery. How is the lifecycle organised, how does code get to production, what does quality assurance look like. Our processes met their expectations and in some areas exceeded them. An agency being measured on these questions rather than on its pitch deck happens less often than you’d think.

Alongside Magento, the previous platform, Skylotec evaluated several enterprise systems. Three criteria were decisive: a multi-tenant architecture, an API-first approach for deep integration of the Microsoft Dynamics ERP, and flexible content commerce features. In Skylotec’s B2B business, customer-specific prices and conditions have to come from the ERP – that was non-negotiable.

The choice fell on Shopware 6 Evolve, because this edition covers core requirements out of the box. These include native B2B features such as request for quote, quick order and sales rep logins.

A major advantage is Shopware’s sales channel concept. Skylotec uses it to run its main website and main B2B shop, plus an independent website and a second B2B shop for the outdoor sector, all on the same instance. With the Rule Builder and the integrated CMS, the team manages product-specific access rights, target-group content and B2B rules for both business areas in one place.

The first commit landed on 22 July 2024 at 3:26 pm. The soft launch was in February 2025, the full go-live in March 2025. The team consisted of two backend developers, one frontend developer, project management, QA and DevOps.

A relaunch with three sales channels can’t be switched over on a single date. Hence the staged approach: start softly, observe, follow up, then hand over completely.

Three major ones. We connected the Microsoft Dynamics ERP via REST interfaces. The PIM, an iPIM system, is connected via a data integration platform. On top of that, a media service for documents, warranties and user manuals is embedded in the shop via JavaScript.

The real work wasn’t in any single integration, but in the data model. All three systems feed into Shopware, and their structures don’t automatically match Shopware’s. One example: Skylotec’s PIM represents products differently from how Shopware understands products and variants. We solve this by giving even a single product one technical variant – pragmatic, but it keeps the model consistent. Adjustments like this had to happen at import level, for each system separately.

What carried the project was close coordination with the technical contacts at all three vendors. And the fact that every change went through a staging system first, then to production.

Customer-specific price lists. Skylotec calculates prices across hundreds of customer groups with very fine gradations. The mechanism Shopware provides for this works well for a manageable number of customers – with thousands, rule evaluation hits its limits.

We solved it with an additional caching layer for calculated prices. It is rebuilt whenever price updates are synchronised, instead of calculating on every page view. An interesting postscript: Shopware 6.7 brought a comparable feature into the standard, and the problem went away. That’s typical of a fast-moving platform – you build something because it’s missing, and one release later it’s there.

There are two B2B channels – one for the professional sector, one for outdoor and climbing – plus a B2C channel. Each with its own audience, its own pricing logic, its own behaviour.

The key was feature toggles. Most of the functionality is already in the production code, but switched off. The business then decides when a feature goes live and for whom – B2B only, B2C only, time-controlled. That turns the relaunch from a single event into a sequence of small switches. Each channel could soft-launch individually with practically zero downtime, and if something didn’t work as expected, the way back was a toggle rather than a deployment.

Skylotec sells internationally – Europe, the US, Australia and beyond. The shop runs in five languages: English, German, Spanish, French and Italian.

Combined with the three sales channels, that creates a matrix in which almost every feature raises the question of which channel, which region and which language it applies to. That’s less a technical problem than one of diligence.

That was one of the more interesting tasks in the project. We deploy to a Kubernetes stack operated by Skylotec. Both sides had established routines, and they didn’t match. You don’t solve that by having one side prevail.

The result is a shared responsibility model: Skylotec’s Kubernetes provides the infrastructure for the shop application, while configuration and delivery of the application follow our approach. Skylotec’s DevOps team keeps full visibility of building blocks and components, and we remain responsible for how our application is delivered and installed. Both sides see what’s happening, and nobody has to adopt the other’s way of working.

To keep watch over the application, we rely on continuous monitoring with alerting, plus application performance monitoring to find code-level performance issues before they show up in operations.

We supported the migration of the Kubernetes environment from a hyperscaler to a European hosting provider. Our standard platform is AWS, but we build our solutions to work without vendor lock-in – that’s not a marketing claim, it gets tested in exactly these moments.

The migration was uneventful, mainly because a CDN sits in front of the application, and its configuration was flexible enough to absorb the switch. Migrating infrastructure during live operations is the most honest test of whether an architecture is really portable. This one passed.

Shopware is powerful and evolves quickly. Even so, you still run into missing features or places where performance could be better.

Three specific points. I’ve mentioned the price lists – until 6.7 that was a real problem. We were missing product bundles. And the product/variant data model doesn’t fit every PIM, which forces workarounds.

The point that remains uncomfortable to this day is plugin installation and templating. We deliver deterministically, via containers and with read-only file systems – the right approach from an operations perspective, but it makes a lot of things less convenient. Anyone used to clicking a plugin in the Shopware backend and trying it out has to wait until it has gone through our pipeline.

From development to production that takes around 20 minutes. For a deployment, that’s fast. For someone who wants to try out an idea, it feels long. This trade-off between reliable delivery and quick experimentation isn’t solved, and I’m not sure it can be fully solved.