Smarty to Twig: why a 1:1 template port is the most expensive way to migrate

The syntax is the easy 10 percent

Every Smarty-to-Twig conversation starts in the wrong place. Yes, {$sArticle.articleName} becomes {{ page.product.translated.name }}. Yes, {if} becomes {% if %}, {foreach} becomes {% for %}, and the modifier pipe survives almost unchanged. A developer who has never touched Twig is productive in it inside a day. If syntax were the problem, template migration would be a scripted find-and-replace and nobody would need to read this.

The problem is that a Shopware 5 template and a Shopware 6 template are not the same document written in two languages. They describe different page structures, they receive differently shaped data, they sit on different CSS foundations, and they extend differently. Translating the words gets you a Twig file that renders a Shopware 5 page badly inside Shopware 6 — which is the worst of both worlds, because you have paid for a migration and inherited every quirk you were trying to leave behind.

Blocks look the same and behave differently

Both systems have blocks, which is exactly why people get hurt. In Shopware 5 you write {extends file='parent:frontend/detail/index.tpl'} and then {block name='frontend_detail_index_buy'}{$smarty.block.parent}...{/block}. In Shopware 6 you write {% sw_extends '@Storefront/storefront/page/product-detail/index.html.twig' %} and {% block page_product_detail_buy %}{{ parent() }}...{% endblock %}. The shapes rhyme. The block names do not, the file paths do not, and the granularity does not.

The one that costs real money is sw_extends versus plain Twig extends. Shopware's own directive is what makes multi-level inheritance work — your theme extending a plugin extending another plugin extending the Storefront. Use vanilla {% extends %} in a theme and you break that chain silently: your override wins, everything below it disappears, and nobody notices until a plugin update stops appearing on the page three months later. This is the single most common template bug we find in migrated shops.

A 1:1 port is a trap because the data is not there any more

Shopware 5 templates were fed arrays assembled by the controller — $sArticle, $sBasket, $sCategoryContent — flat structures full of legacy field names that had accreted over a decade. Shopware 6 hands the template a page object built by a page loader, with entities, associations, translated fields and struct extensions. There is no mechanical mapping. Half the values your old template reads do not exist under any name; the other half exist somewhere you have to go and find, and sometimes you have to add a page-loader subscriber to put them there at all.

Underneath that, the CSS story changed too. Shopware 5 themes sat on Bootstrap 3 and LESS; Shopware 6 Storefront sits on Bootstrap and SCSS with its own variables and a different grid vocabulary. Your old markup is full of classes that either no longer exist or now mean something else. Porting the HTML class-for-class produces a page that looks approximately right on a designer's monitor and falls apart at 768 pixels, and you spend the last third of the project fixing responsive bugs you imported on purpose.

Rebuild these, translate those

The useful discipline is to sort every template into three buckets before anyone opens an editor. Delete: everything that exists because Shopware 5 could not do it and Shopware 6 does natively. Rebuild: everything where the old markup encodes an old page structure. Translate: the small remainder that is genuinely just your content in someone else's syntax. In every migration we have done, the delete bucket is bigger than the client expects and the translate bucket is far smaller.

The delete bucket is where the money is. That custom landing page template with the hand-built teaser grid is a Shopping Experience layout now, and a marketing person can maintain it without you. Those emotion-world overrides are gone by definition. The little template hacks that inject a badge or reorder a block are often a CMS block or a two-line override in Shopware 6. Every file you delete is a file nobody has to test, nobody has to fix on the next minor, and nobody has to explain to the developer who inherits this in 2027.

• Always sw_extends, never plain extends, in themes and plugins — silent inheritance breakage otherwise.
• Override the smallest block that does the job; never copy a whole template to change one line.
• Emotion worlds and custom landing templates become Shopping Experiences — delete, do not port.
• Data the page object does not carry needs a page-loader subscriber, not a database call in the template.
• Rebuild markup against the current Storefront classes instead of importing your Bootstrap 3 grid.

What this actually costs, and how to keep the bill down

Template work is usually the largest single line item in a Shopware 5 to 6 migration, and it is the one clients underestimate hardest, because the old shop looks finished. A heavily customised SW5 theme with a few hundred template overrides is months of work — not because Twig is hard, but because somebody has to open each of those overrides, work out what it was for, find out whether that reason still exists, and decide. That decision, repeated three hundred times, is the project.

So the cheapest lever is not a faster developer, it is a shorter list. Go through your SW5 overrides with the person who asked for them and kill the ones that exist because of a campaign in 2019, a manager who has left, or a fashion that has passed. Then rebuild on a near-standard Shopware 6 theme and add customisation back only where somebody can name the revenue it protects. Shops that do this land near the bottom of the estimate. Shops that insist on pixel-identity with a design from 2017 land near the top, and then ask why.

Frequently asked questions