What we use Magento for
Magento is not something we offer; it comes out of our clients' past. These are shops built on Magento 1 or Magento 2 years ago, running in daily business, with revenue, processes and interfaces hanging off them. Magento 1 installations have had no security updates since June 2020; there the question is not whether they will be replaced but when. Our job is to keep these systems running, secure and open to ongoing development — regardless of who originally built them.
The typical case is a B2B catalogue with many variants, customer prices and connections to an ERP or PIM system. Those connections are exactly why a change of shop system rarely fails at the front end and almost always at the data paths behind it. We take over maintenance, security patches and functional extensions, run the shop on our own servers in Germany and keep the interfaces to the ERP system working.
How we work with Magento
Extensions are built as modules of our own in app/code, not as an intervention in the core. Layout and templates are overridden through a custom theme, business logic extended through plugins and observers. Deployment runs via Composer, and configuration is versioned instead of clicked together in the backend. Touch the core and you buy the next update round as a project of its own — that mistake costs more later than it saved at the start.
In operation, a lot with Magento depends on its surroundings: MariaDB or MySQL, a key-value store for cache and sessions, a search engine of its own, Varnish in front, cron jobs for indexers and queues. That environment has shifted recently — from version 2.4.8 Adobe uses OpenSearch instead of Elasticsearch, and from 2.4.9 Valkey instead of Redis. If one of these services fails, the shop notices immediately. So we set the environment up reproducibly with Docker, monitor indexers and message queues, and test updates in a staging environment before they go live.
Limits — and when we advise Shopware 6
Magento is powerful, and that has a price. The hosting requirements are high, the update cycles tight, and developer hours cost more than in other systems. For a mid-sized shop with a manageable range, that effort is often out of all proportion to the benefit. We say so even when a Magento project would mean more hours for us than a migration.
For most mid-sized projects, Shopware 6 is the more economical choice — cheaper to run, closer to the German market, with a larger pool of developers. What speaks against a migration is a Magento shop that runs stably, is maintained, and whose special logic would be expensive to rebuild. A working system is no reason for a rebuild project. We do that sum in advance, not halfway through.