Initial situation: TYPO3 CMS and separate shop - a model of yesterday
Many companies have historically relied on TYPO3 as the CMS for their company website and a separate shop system for online retail. In theory, this sounds like the "best of both worlds", but in practice it means
two systems with their own updates, releases and security requirements
duplicate maintenance of content, structures and sometimes even product information
additional interfaces that need to be maintained, tested and monitored
Why TYPO3 should not be the basis for a shop system
TYPO3 is a powerful enterprise CMS, but not a commerce system. It was built to map complex websites, portals and editorial content - not to carry shopping baskets, checkout processes, payment methods or commerce logic at its core.
Typical weaknesses of a TYPO3-based shop
ECommerce only via extensions
The shopping basket, checkout, order logic and payment are not part of the TYPO3 core, but must be supplemented via third-party extensions or in-house developments. This increases the risk of incompatibilities during updates and results in considerable testing and maintenance work.
Complexity and high operating costs
TYPO3 is already considered a complex system; customised shop functionality on top makes implementation, updates and migrations even more complex. Major upgrades can quickly become expensive, especially if many extensions are in use.
Limited commerce ecosystem
Compared to specialised shop systems, there is no equivalent plugin ecosystem for TYPO3 for payment, shipping, promotions, marketplaces and B2B features. As a result, companies often pay for a higher proportion of customised development.
Vendor lock-in through customised extensions
As soon as central commerce functions run via customised TYPO3 extensions, the business is heavily dependent on the agency or individual developer in charge. This makes subsequent migrations more difficult and makes you inflexible in the long term
Lack of commerce focus in the roadmap
TYPO3 is primarily developing as a CMS, not as a commerce platform. Topics such as omnichannel commerce, rule builders, promotion engines, marketplace integration or AI-supported sales logic are not at the centre of the product strategy - but Shopware 6 is.
In short: TYPO3 can be "bent" into a shop with a lot of effort, but this results in a system that has to compete against specialised commerce solutions - with a higher risk and significantly higher operating costs. The consolidation approach of moving everything to TYPO3 is therefore not the right one, both technically and economically.
a mature commerce core (products, variants, shopping basket, checkout, payment methods, taxes, shipping, customer groups, B2B features)
Experience worlds as an integrated CMS, with which editorial content, landing pages, guides and brand pages can be created directly in the shop
an API-first architecture with headless options to play out content and functions in other channels (portals, apps, marketplaces)
Shopware 6 can therefore serve both classic storefronts and modern headless setups - and in many scenarios it completely replaces an external CMS.
Worlds of experience: CMS that understands commerce
With worlds of experience, content such as stories, guides, brand worlds or campaign pages can be set up in a modular way and linked directly to product data, categories, promotions and rules. Editors work in a visual interface, while commerce logics (e.g. dynamic product lists, personalisation, promotions) work in the background.
The result is a system in which content and commerce really belong together - without media disruptions and without synchronisation effort between TYPO3 and the shop.
Consolidation: From a two-world setup to a Shopware 6 target image
The sensible direction of consolidation is clear: away from a TYPO3+shop combination and towards a complete Shopware 6 system. TYPO3 remains a strong CMS - but is not suitable as the basis for a modern, scalable shop architecture.
Advantages of a single system in maintenance and care
Centralised updates and security
Instead of two system landscapes, each with their own security updates, plugin versions and release cycles, there is now just one centralised system. This reduces coordination effort, testing effort and the risk of overlooking critical patches.
Fewer interfaces, fewer sources of error
API connections between TYPO3 and the shop - including authentication, caching and fallback logic - are no longer necessary. This reduces downtime risks and maintenance cases, especially during peak loads or system updates.
Plannable maintenance costs
Instead of duplicate maintenance contracts and unclear dependencies, a clear maintenance framework can be defined for Shopware 6. Experience shows that consolidation significantly reduces ongoing expenses and makes them easier to plan.
Efficiency gains in day-to-day business
The effect is immediately noticeable for your teams:
editors and eCommerce managers work in one interface with one login.
content with a strong purchasing intention (e.g. use cases, industry worlds, campaigns) can be linked directly to product logics - without having to go through TYPO3.
changes to navigation, templates or content modules are effective system-wide and do not have to be maintained twice.
This saves time, reduces sources of error and creates more room for what really makes an impact: better content, more relevant offers and clearer customer journeys.
Performance, scalability and security: a stack instead of a patchwork quilt
With growing traffic, more complex B2B requirements and increasing security requirements, a fragmented tech stack becomes a risk.
A consolidated Shopware 6 system offers clear advantages here:
Performance
Modern architecture, caching, search and API optimisations ensure fast loading times without the need for an upstream CMS or complex proxy structures.
Security
A standardised rights and patch concept reduces attack surfaces. Two separate systems, each with their own user and rights management, are much more difficult to secure properly.
Scalability
New countries, clients, channels or commerce features (e.g. marketplaces, B2B portals, agent commerce scenarios) can dock onto a centralised commerce platform. The database is standardised, which greatly simplifies subsequent AI and automation scenarios.
Marketing, SEO and experience: one platform, one story
In a separate TYPO3/shop setup, SEO-strong content is often in the CMS, while conversion-strong pages are in the shop - connected by internal links and more or less optimised transitions.
With Shopware 6 as a complete system:
landing pages are created that combine content, storytelling and products on one URL
metadata, structures and internal links can be controlled consistently - without CMS/shop boundaries
campaigns can be built, tested and scaled more quickly because only one platform needs to be customised and rolled out
Especially with regard to modern commerce scenarios - e.g. AI-supported product recommendations, conversational commerce or agentic commerce - a clean, standardised database is worth its weight in gold.
TYPO3 + shop vs. Shopware 6 as a complete system
Aspect | TYPO3 + separate shop system | Shopware 6 as a complete system |
Number of systems | Two systems, two stacks | One system, one stack |
ECommerce focus | ECommerce only via extensions / third-party shop | Commerce anchored in the core |
CMS functionality | Strong as a CMS, but without a native shop | Integrated CMS can be expanded via plugins |
Maintenance & updates | Double effort, interface risks | Centralised updates, clear maintenance framework |
Risk & security | More attack surfaces, heterogeneous patch strategies | Standardised security strategy |
Extensibility | A lot of custom development required | Extensive plugin/extension ecosystem |
Future viability | CMS roadmap, limited commerce focus | Commerce roadmap with headless & AI focus |
Jochen Kernwein,
CSO at elio GmbH
Conclusion: Consolidation as a clear business case - not just a technology project
The consolidation of TYPO3 CMS and a separate shop system into a complete Shopware 6 system is much more than an architectural refactoring - it is a hard business case. Instead of two licence models, two hosting setups, two maintenance contracts and two training paths, you will be investing in exactly one system in future. This reduces licence and operating costs, noticeably lowerers maintenance costs and makes budgets easier to plan.
Teams no longer have to be trained, onboarded and continuously trained in two worlds, which results in direct savings in training and onboarding costs and also shortens the time-to-productivity of new employees. Less complexity in the stack also means fewer disruptions, fewer coordination rounds between IT, specialist departments and service providers and therefore measurably lower internal costs.
In short: consolidating today not only saves money in the here and now - it also shifts ongoing costs downwards in the long term and at the same time creates the freedom to invest budgets in growth, innovation and new commerce features instead of in maintaining an outdated patchwork of systems.
