Metro Boutique and the honest numbers behind the migration decision

Metro Boutique runs 25 stores across Switzerland and speaks to a crowd between 16 and 34. The online store worked – but that was about it.

The NopCommerce system from 2015 was costing CHF 250,000 a year in maintenance alone. Every content change needed a developer. Black Friday campaigns had to be manually switched on at midnight. Scheduling simply didn’t exist.

The main driver was financial: platform costs were making it harder and harder to stay profitable.

Phase 0: Business case first, migration second

what. didn’t kick things off with development. Instead, we started with a structured Store Check & Migration Assessment – the goal being to figure out, based on actual data, whether a Shopify migration even made sense, and if so, how to approach it.

The assessment came back with concrete numbers:

• 55% TCO savings over 5 years
• CHF 2 million in projected savings over the same period
• 9 million URLs in the existing store – only 88,000 of which were indexed
• 1.04% conversion rate as a starting point

That’s a business case you can actually defend internally. Management could back the decision with real numbers, not just gut instinct.

One more insight from the assessment: Metro Boutique’s strong brand identity lived primarily in its physical stores. Online, it felt muted. “Same brand, different decibels.”

The system landscape before and after the migration

The three biggest technical challenges – and how what. solved them

Complex system landscapes always have spots that look straightforward on paper but aren’t in practice. At Metro Boutique, there were three of them.

Akeneo Connector

The existing Akeneo connector wasn’t up to the task for Metro Boutique’s specific data structure. The vendor was slow to respond and not particularly open to making adjustments. So what. built their own – clean, maintainable, and tailored to what was actually needed.

This comes up more often than you’d think. Off-the-shelf solutions rarely fit 100%. The difference is whether you’re willing to do something about it.

Physical Gift Cards as a Payment Method

Gift cards account for around 4% of online revenue. Shopify’s native gift card system isn’t built for physical in-store cards.

what. built a fully custom payment method that validates card balances via the external payment provider MF Group. It might sound like a minor detail – but letting 4% of revenue disappear simply wasn’t an option.

Worth noting: the old store already had this feature. The custom development simply closed the gap on the Shopify side.

App Wishlist Synchronization

The third-party solution originally evaluated caused synchronization issues. what. is currently developing their own script. This one is still in progress – and we’re being upfront about that here, because it’s part of the honest project picture.

Timeline: from proposal to go-live

The planned launch was October 2025. Actual go-live: mid-January 2026 – around 7 months after the project kicked off.

At go-live, there was no downtime, no data loss, and all critical integrations worked without a hitch.

The timeline shifted because integration quality took priority. That was the right call – going live with unresolved critical issues creates more problems than it solves.

What’s changed since launch

Denis Spycher from Metro Boutique puts it well:

“Internally, we’d been thinking about switching our shop system for a while – mainly because of high fixed costs and limited flexibility. From day one, I had a really good feeling about it. The collaboration was efficient, goal-oriented, and genuinely enjoyable. With Shopify, we now have significantly more flexibility, better efficiency in day-to-day operations, and a CMS that’s fast, intuitive, and easy to use.”

The conversion rate climbed from 1.04% to 1.08% in the first 90 days. That might sound small, but at the volume of a national fashion retailer, it adds up.

The qualitative changes are just as significant:

• The e-commerce team can now launch campaigns independently – no developers needed
• 95% of content changes are handled in-house
• Time-controlled campaign scheduling without manual activation is now possible (still to be implemented)
• The foundation for personalization, A/B testing, and SEO optimization is in place
• UX/UI improved
• Cost structure sustainably improved

And when it comes to day-to-day life for the team:

“Since going live, we’ve had a lot more freedom and can act much more proactively. For many things, we no longer need external support – we can step in ourselves, optimize the store, and test new ideas quickly. I’m convinced that Shopify Plus was the right decision for us.”

Platform costs are now around a quarter of what they used to be.

The complete technology stack

*The old store already had this feature; our custom development simply closed the gap on the Shopify side.

What this project says about the right migration approach

Shopify migration projects often don’t fail because of the technology. They fail because implementation starts too early, before anyone really understands the business case.

The assessment phase wasn’t a nice extra – it was the foundation that allowed Metro Boutique to make the decision and defend it internally. Understand first, decide next, then build.

And if an existing vendor connector doesn’t cut it, what. simply builds their own. That’s not a special case – it’s a principle. Complex system landscapes need solutions that actually fit.

Planning a similar migration?

If your platform costs are too high, your team depends on developers for every little change, or you just know your system is holding you back – the first step is an honest look at where things stand.

That’s exactly what our Shopify Migration Services are for: from the initial assessment through technical implementation to go-live and beyond. As Switzerland’s leading Shopify Plus agency with over 200 completed stores, we know where the real challenges tend to hide – and how to tackle them.

The post From NopCommerce to Shopify Plus: How what. Led Metro Boutique into the E-Commerce Future appeared first on what. AG.

Who is Schweizer Päckli and where did we come in?

Schweizer Päckli does something that’s harder to pull off than it sounds: they sell carefully curated packages filled with authentic regional Swiss specialties, and they make the whole thing feel like a genuine gift rather than just another online order.

Each “Päckli” is thoughtfully assembled to bring a piece of a specific Swiss region to the recipient. The contents aren’t generic. They’re selected with real attention to regional provenance, which is what gives the product its character. For someone looking to send something meaningful, that specificity matters.

By mid-2023, the technical foundation holding all of that together had started showing its age. We at what. took on a full platform migration, moving Schweizer Päckli from OctoberCMS to Laravel and Vue 3, with Laravel Nova as the backend. The project wrapped at the beginning of 2024.

Why a full migration made more sense than patching the old system

OctoberCMS had done its job. But the limitations had piled up to the point where working around them was no longer realistic.

Adding new features was nearly impossible. The dependency on CMS plugins meant little control over the underlying data structures. And scaling to new regions, a real strategic goal for Schweizer Päckli, was cumbersome at best.

The honest case for a full migration came down to this: when the architecture itself is the ceiling, incremental improvements just delay the inevitable. Going with Laravel and Vue 3 gave the project a proper foundation:

• Better performance and easier extensibility
• Cleaner data structures with fewer plugin dependencies
• A backend the client could manage independently, without needing to loop in an agency for routine updates

The technical challenges that slowed things down

SSR setup was harder than expected

The most demanding part of the project was configuring Server-Side Rendering (SSR) for the Vue 3 frontend. Because Schweizer Päckli’s shop runs as a Single Page Application (SPA), SSR is what makes it crawlable and indexable by search engines. Without it, the shop effectively doesn’t exist for Google.

The friction came from older JavaScript libraries that assumed a browser environment. The moment you try to render them server-side, they break. The team had to resolve these conflicts one by one.

What made this harder was an additional constraint: the frontend had to look exactly the same as before. The client didn’t want any visible changes to the UI. So the team was rewriting internals while keeping the surface identical, which made what would otherwise be a contained technical problem significantly more delicate.

Data migration and CSS continuity

The existing data had to move cleanly into new schemas without loss or integrity issues. Not the most exciting work, but it’s where migrations often go quietly wrong.

The CSS and SCSS situation was similar. Years of CMS-era stylesheets came with the usual baggage: specificity conflicts, undocumented overrides, styles tied to markup that no longer existed. Getting those to function correctly inside Vue 3 components, without triggering a full visual redesign, took real patience.

What we learned

The invisible work matters most

The most significant outcome nobody noticed was the PDF generation overhaul. Supplier documents look exactly the same as before on the surface. But the internal logic was completely rebuilt to handle a much larger volume of documents than the old system could manage.

It’s a pattern worth internalizing: the improvements that create the most long-term reliability are often the ones users never see. That’s not a reason to skip them. It’s a reason to protect them from being cut.

Modern stack as a prerequisite, not a luxury

On the old platform, almost every new feature request ran into the same wall. The answer was effectively: “we can’t, or it’ll cost a lot.” That’s not just a developer problem. It has direct business consequences.

After the migration, that conversation changed entirely. New regions can now be added from the backend without development work. Features that were previously out of reach are now straightforward to build.

Automated testing protects you when business logic shifts

what. introduced test cases that run before each deployment. For a business like Schweizer Päckli, where the logic around regional packages, suppliers, and orders evolves as the product grows, that’s a genuine safety net. It catches issues early, before they reach customers.

What worked well

A few things landed particularly cleanly:

• CDN setup: Images, JavaScript, and CSS files are now served via CDN across Schweizer Päckli’s multiple regional domains. Assets load faster regardless of which regional version of the site a visitor lands on. A relatively straightforward decision with a disproportionate impact on perceived performance.
• Laravel Nova backend: The client can now manage content, regions, and packages without needing to involve what. for routine updates. That kind of editorial independence reduces dependency on an agency and frees up project time for work that actually requires technical input.
• Region management: Adding a new region, which used to require significant development effort, is now a backend task. There’s also a region switcher that gives an at-a-glance overview of any regional version of the site, useful as the business continues expanding.

What’s still in progress

The migration was the foundation, not the finish line. Schweizer Päckli is actively working on further improvements to the shop, which is exactly the right posture. The new architecture supports that kind of iterative development in a way the old system simply didn’t.

Ongoing topics include shop improvements and further regional expansion. The team isn’t standing still.

Key takeaways from this project

Platform migrations are never purely technical. The hardest constraints on this project were non-technical ones: keeping the UI visually unchanged, migrating years of data cleanly, and working around legacy JavaScript libraries that weren’t built for modern rendering approaches.

The things that created the most durable value weren’t the flashiest deliverables. The PDF overhaul, the CDN setup, the test suite: these are the structural improvements that will quietly prevent problems for years. They’re also the easiest ones to cut when timelines get tight, which is exactly why they shouldn’t be.

If you’re sitting on an aging CMS and finding reasons to delay a migration, the cost of that delay is probably higher than it looks. Every feature request that gets a “we can’t” is a business consequence, not just a technical one.

If you’re thinking about a platform migration or website relaunch, what. helps businesses work through exactly this kind of process, from requirements and system selection through to implementation and go-live. Take a look at what.’s website relaunch and development services to see how we approach it.

The post How We Migrated Schweizer Päckli from OctoberCMS to Laravel & Vue 3 appeared first on what. AG.

Together with ETH Zurich, we developed the ETH Companion: an AI leadership coach built exclusively on scientific sources that supports over 3000 ETH executives. Here’s an honest look at what we learned along the way.

ETH Zurich – world-class research

ETH Zurich is one of the most renowned research universities in the world. Since its founding in 1854, it’s stood for scientific excellence across the natural sciences, technology, engineering, and mathematics.

With over 13,000 employees from around 120 countries, ETH isn’t just a Swiss institution – it’s a global player in education and research. People who work here operate in a highly complex, international environment, with correspondingly high demands on leadership and decision-making.

That’s exactly where the ETH Companion comes in.

What really makes this AI coach special

The core question at the outset wasn’t a technical one – it was strategic: how do you make high-quality leadership coaching accessible to thousands of executives without pouring huge sums into individual coaching programs? Traditional one-on-one coaching doesn’t scale. Digital coaching does.

The key is the quality of the knowledge base. The ETH Companion draws exclusively from trusted articles by ETH psychologists. No random internet content – only scientifically validated material, developed by ETH for ETH.

And that difference matters more than it might seem. A personal leadership coaching program can easily run several hundred thousand francs a year – if you’re serious about leadership development at scale. The ETH Companion scales exactly that: scientifically grounded leadership coaching, accessible to every executive, at any time.

The goal isn’t to build a chatbot. It’s about creating a tool that supports leaders through real challenges – based on approaches that work because they’re scientifically proven.

That sounds straightforward, but it’s conceptually demanding. You need to clarify very early on: what content goes in? Who curates it? How do you make sure the coach stays within scope?

These questions need answers before you write a single line of code.

Defining the MVP is harder than building the MVP

The most challenging part of the project wasn’t technical – it was defining the MVP (Minimum Viable Product).

What should be included? What comes later? Where’s the line between “good enough to test” and “too raw to show real value”? These discussions take longer than expected, but they’re crucial.

We ran scope definition workshops with the ETH team, created user stories, and built the framework step by step. It was absolutely worth it – but it takes time you need to factor in from the start.

A clear tip: start small, then scale. Focus the MVP on the absolute essentials, see if it works – and only then layer in additional features. Anything you didn’t clarify in the MVP will cost you twice as much to fix later.

User testing reveals what documents never will

The best moment of the entire project came during the user testing interviews.

Watching executives interact with the Companion – and seeing their genuine enthusiasm – was something else. It validated not just the product, but every decision that led up to it.

But user testing also gave us concrete insights we simply didn’t have before:

• How executives phrase their questions – and what that means for the coach’s conversational style
• Where the dialogue felt too generic and needed more depth
• Which entry points felt intuitive – and which didn’t

Without this phase, the product would have been worse. No document, no internal test replaces real interactions.

Security is not an optional add-on

A security audit was part of the development process – and that was absolutely the right call.

For a tool that handles sensitive leadership situations and is used by thousands of executives, security isn’t a nice-to-have. It’s a must-have.

Plan for it from the very beginning – not as a last-minute step just before launch.

What really counts: long-term integration, not short-term usage

Right after launch, the focus naturally shifts to: are users happy with the answers?

That’s a fair question – but it’s too narrow. The actual vision for the ETH Companion is bigger: the AI leadership coach is meant to become a genuine part of everyday working life over the long term, and to sustainably improve the quality of decisions executives make.

And the vision goes even further: what was built today for ETH leaders should eventually be available to large organizations outside ETH – as a scalable solution for companies that take leadership development seriously, without investing hundreds of thousands of francs in individual coaching programs.

That sets a different standard. And it calls for different metrics than “did the AI give a good answer today?”

What we’ve delivered – and what comes next

The result is a functional, stable AI leadership coach with a well-thought-out design that’s already in productive use. But what happens after launch matters just as much as the launch itself.

We’re continuing to develop it in ongoing sprints – because an AI tool like this isn’t a finished project. It’s a living product.

What you can take away from this

If you’re planning a similar project, these are the insights that really matter:

• Differentiation comes from content, not technology – the quality of the scientific knowledge base and the coach’s clear focus make all the difference.
• Start small, then scale – define the MVP scope in writing, validate it, then expand.
• User testing is not optional – treat it as a real project phase, not just a checkbox at the end.
• Security and scalability need to be considered from day one, not as an afterthought.

Curious about what AI automation could look like specifically in your company? That’s exactly what we work on every day.

The post ETH Zurich AI Leadership Coach: Our Lessons Learned appeared first on what. AG.

That was the core tension in our work with BMW Classic: how do you modernize without disrupting a highly specialized, globally shipping operation? Here’s what actually happened, and what we learned.

The real problem wasn’t the old technology

BMW Classic runs one of the most specialized online shops in the motorcycle world – genuine parts for everything from 1920s classics to current models, with worldwide shipping. The platform they were running had done its job for years, but it had reached its limits:

• SEO was essentially broken. The site was barely indexed, which meant customers searching for long-tail spare parts – often very specific queries – simply couldn’t find the shop. 
• Content updates were slow and risky. 
• The system wasn’t built to support modern marketing workflows or a smooth purchasing experience.

The hidden complexity: a significant portion of the business logic lived inside FileMaker, a legacy database system that had accumulated years of operational knowledge – product structures, compatibility rules, fulfilment logic. That’s not something you just switch off.

Keeping the business running while rebuilding it

The biggest architectural decision we made early on was this: don’t replace FileMaker in a big bang. Build around it, carefully.

This meant designing a dedicated sync layer – a structured integration that connects FileMaker with the new custom-built storefront, keeps product and catalog data in sync, and insulates the shop from the risks that come with legacy data sources. If FileMaker becomes temporarily unavailable, the shop keeps running. That stability is only possible because of the abstraction layer between them.

What this taught us is that preparation and understanding of the existing system matters more than the technology you’re migrating to. We spent significant time with the architects of the old shop before writing a single line of the new one. That investment paid off directly in the quality of the integration.

Two systems, two responsibilities: why Payload CMS was the right call

A shop like BMW Classic needs two fundamentally different things working in parallel: a structured commerce layer for parts data, pricing, compatibility, and stock – and a flexible content layer for landing pages, campaigns, and editorial storytelling.

Trying to force both into a single system creates compromises in both directions. So we separated them intentionally.

Payload CMS became the content brain. It gave the BMW Classic team the ability to publish and update marketing content, build campaign pages, and manage editorial material without needing a developer for every change. That kind of operational independence matters – especially for a team managing a catalog this size.

The custom commerce layer handled the rest: product data, checkout, pricing, and order flow. Connected through the sync layer, both systems together gave BMW Classic something they didn’t have before – speed without risk.

SEO as a product requirement, not an afterthought

One of the clearest decisions we made going in was to treat SEO as a core requirement – not a layer added after development. For a shop selling 40,000+ spare parts, organic discoverability isn’t a nice-to-have. It’s the difference between capturing long-tail search demand and missing it entirely.

In practice, this meant:

• A clean, indexable URL and navigation structure from day one
• Fast page loads via Next.js and Digital Ocean infrastructure
• Scalable metadata and content architecture that grows with the catalog
• A navigation model built around the way real customers actually search – by model family, then category, then part

The previous platform had essentially no SEO foundation. Fixing that structurally, rather than patching it, was one of the most commercially relevant things we did in this project.

What we’d do the same – and what we’d watch more closely

The design and technical architecture held up well. Building a storefront around the real buyer journey – find the right model, navigate categories confidently, validate part details, purchase without friction – is the right approach for a parts shop at this scale.

What we’d watch more closely next time: even more rigorous documentation of FileMaker data structures before migration begins. Legacy systems often contain edge cases that only surface under real conditions. The more thoroughly you map the old system upfront, the fewer surprises appear during sync testing.

The other key learning – and this applies beyond BMW Classic – is that a sync layer isn’t just a technical workaround. It’s actually a long-term architectural feature. Future migrations, additions, or replacements of any single component don’t require rebuilding the whole platform. That’s a real advantage as the business evolves.

Where things stand

The shop is live, stable, and continuing to develop. We’re ongoing with SEO improvements, UX refinements, and expanding the content layer. A project like this doesn’t end at launch – it enters a growth phase, and the foundation needs to be solid enough to support that.

If there’s one thing worth taking away from this project: the hardest part of migrating a legacy system isn’t the new technology. It’s respecting and understanding the old one well enough to build around it safely.

Working with a content-heavy platform or considering a CMS migration? Our Payload CMS services are built for exactly these kinds of projects – complex data, editorial independence, and no big-bang risk.

Related: Learn how we developed an ERP-Shopify connector and merged the e-commerce store for Rokker.

The post E-Commerce and CMS Migration for BMW Classic appeared first on what. AG.

What we built: a live data bridge between Shopify and SAP S/4 HANA

Rausch GmbH needed a fully automated connection between their Shopify Plus store and SAP S/4 HANA. No manual exports, no spreadsheet handoffs.

We built a custom SAP connector handling four core jobs: orders, payment terms, tracking numbers, and inventory sync. Working alongside Eddyson – an external SAP integration partner – we owned the Shopify side while Eddyson bridged the gap to SAP.

The flow works like this:

• Shopify sends order data via webhook to our connector
• We enrich the files with missing information and deposit them on an FTP server for Eddyson to pick up
• In the other direction, SAP sends tracking and inventory updates to Eddyson, which forwards them to us – we enrich and push them into Shopify

Clean loop, when it works.

File enrichment and payment flows: where the real complexity lives

Shopify’s order webhook payload doesn’t include everything SAP S/4 HANA needs – and that gap is where most of the work happened.

Barcodes, for example, aren’t part of the order data. The connector loops through each line item, fires an additional API call using the variant ID, and fetches the barcode separately. Same logic for gift cards: we detect the payment gateway name, hit the transactions endpoint, and pull the gift card data before packaging the file.

None of this is complex in isolation. But when you’re mapping fields across two systems with fundamentally different data models, it adds up fast.

Buy on account required its own solution entirely. SAP handles these orders with a delivery block – the order exists but doesn’t ship until payment is confirmed. That meant orders/create and orders/paid couldn’t follow the same flow. We built two distinct flows, each triggering different downstream logic. Getting the SAP behavior properly documented took longer than expected.

Three-party project coordination: the hidden cost of misalignment

Any project involving a client, an agency, and a third-party integration partner has natural friction points. Mapping decisions took time to finalize, and some delays came from waiting on alignment between parties rather than from the technical work itself.

We navigated it – but it taught us something important about how these projects should be set up from the start.

What we’d do differently on a Shopify ERP integration

We went into this project without a detailed requirements list or milestone-based roadmap. That gap cost us time.

Upfront documentation is non-negotiable. When you’re coordinating between Shopify, a custom connector, and a third-party SAP middleware partner, ambiguity is expensive. A requirement that seems obvious to one party is news to another.

A few things we now treat as mandatory on any Shopify ERP integration:

• A detailed requirements list before kickoff – especially for payment flows, tax logic, and edge cases like gift cards or custom payment methods
• A shared Slack channel with all parties onboarded from day one – context scattered across emails and calls slows everything down
• Data mapping completed early and in detail – the gap between what Shopify sends and what SAP expects is where projects lose weeks

Key takeaways for your Shopify SAP integration

If you’re planning a Shopify SAP or broader Shopify ERP integration with a third-party middleware partner, here’s the short version of what this project taught us:

• Define requirements before kickoff – not a rough scope, an actual list. Payment flows, tax logic, edge cases.
• Map your data early – the Shopify-to-SAP field gap is real and takes time to resolve properly.
• Build on a stack you’ll maintain – technical debt from legacy codebases surfaces as migration costs, not if but when.
• One shared communication channel from day one – when three parties need to align quickly, async fragmentation kills momentum.

The connector works. The lessons were worth it.

We also delivered the full Shopify services scope for Rausch GmbH – building their Shopify Plus store, migrating from Shopware 5, and implementing a custom product configurator for their Pick&Mix solutions. The ERP connector sits inside a larger, working ecosystem.

The post Shopify ↔ SAP S/4 HANA Integration: What We Learned Building a Custom ERP Connector appeared first on what. AG.

Turns out, even well-planned web development projects come with surprises – and this one taught us more than we bargained for.

Content Management Requires Significant Investment

When you’re dealing with specialized technical systems like irrigation and illumination solutions, content isn’t just about filling pages – it’s about precision. Our high standards for quality and accurate representation of Rudolf Hirt AG’s complex product range meant this phase required substantially more time than initially planned.

We had the structure ready, the design approved, and development moving along. But gathering, uploading, and formatting images and technical specifications for specialized equipment demanded careful attention to detail. Each product needed proper context, accurate technical data, and visual assets that truly represented the quality of the systems.

The real lesson? Never treat content as an afterthought. If you’re planning a website relaunch, budget serious time for this phase – especially when technical accuracy and quality presentation are non-negotiable.

Scope Clarity Prevents Painful Surprises

In specialized industries like irrigation and illumination technology, details matter enormously – especially for SEO and discoverability. During this project, we discovered just how critical elements like comprehensive alt texts are for helping potential customers discover highly technical products through search.

Alt texts weren’t explicitly scoped in our initial agreement. When we realized their importance for SEO performance in this niche market, we needed to address them – but it required additional coordination that could have been smoother with upfront planning.

This was a valuable learning for both sides: when you’re committed to maximum quality and detail, you need equally detailed planning. Today, we work with comprehensive checklists from day one that account for these SEO-critical elements, especially for businesses with specialized technical offerings.

What changed after this project: We now define responsibilities, deliverables, and expectations in detail before development starts. We highlight what’s included, what’s optional, and where trade-offs might be needed. Early clarity isn’t bureaucracy – it’s how you prevent misunderstandings that cost time and trust later.

Prioritizing User Experience Over Visual Complexity

The overall design got approved. Great. Development started on complex scrolling animations that added visual polish – and significant technical complexity.

Then we made a conscious decision: prioritize user experience and page load speed over decorative elements. While the animations looked impressive in development, we recognized they could compromise performance – something critical for a business website where prospects need quick access to technical information and contact options.

This wasn’t anyone’s fault, really. Animations are hard to evaluate in static mockups. What looks exciting on paper might feel distracting in practice, or simply not worth the performance cost once you see it live.

The takeaway: Complex design elements like animations need better preview options before full implementation. Quick prototypes or interactive demos help clients understand the trade-offs between visual appeal and technical performance, enabling informed decisions early and reducing costly changes during development.

Workflows Matter More Than You Think

We inherited a WordPress workflow from the initial developer. It worked, technically. But it required constant modifications and created extra work throughout the project.

Since this experience, we’ve moved all WordPress projects to a unified, streamlined workflow. Choosing efficient tools and processes upfront – or being ready to adapt when something’s clearly not working – saves massive amounts of time and keeps budgets under control.

If you’re curious about how we handle WordPress development now, check out our WordPress services.

Quality-Focused Decision-Making

Real talk: Every web development project involves trade-offs. Throughout this relaunch, we made conscious decisions to prioritize overall quality and long-term value over certain features.

That’s not a compromise on quality – it’s strategic focus. The key is communicating these trade-offs transparently, so both teams understand which elements deliver the most value and which might be approached differently or phased over time.

This collaborative approach to decision-making – always asking “what serves the end user best?” – shaped the project’s direction and ultimately contributed to its success.

Why It Still Worked

Despite the challenges, the relaunch delivered real results. The quality of incoming inquiries improved noticeably, and feedback from new customers about the website design has been overwhelmingly positive. Rudolf Hirt AG reports being complimented on their new web presence almost weekly – with several prospects specifically mentioning the website as a factor in their decision to reach out.

Beyond subjective feedback, the SEO improvements speak for themselves. Between August 2025 and February 2026, Rudolf Hirt AG achieved significant ranking gains for their most important keywords. Multiple search terms moved into top-10 positions, dramatically improving visibility for their specialized irrigation and illumination solutions.

The project proved that even with unexpected obstacles, focusing on collaboration, quality, and honest communication leads to measurable success.

Check out the redesign of Rudolf Hirt AG Bewässerung, Brunnentechnik und Beleuchtung to see the final result.

What You Can Take Away

The Rudolf Hirt AG relaunch is a success – not just because of what was delivered at launch, but because of the foundation it created for ongoing growth. what. continues to support Rudolf Hirt AG with SEO and continuous improvements. After all: after the launch comes the growth.

If you’re planning a website relaunch or working with a web development team, here’s what actually matters:

• Budget real time for content. It’s never as quick as you think – especially when quality and technical accuracy matter.
• Define scope upfront. Use checklists. Be specific about what’s included, particularly SEO-critical elements for specialized industries.
• Preview complex features early. Don’t wait until development is done to evaluate animations or interactions – and be ready to prioritize performance over decoration.
• Choose efficient workflows. The right tools and processes compound over time.
• Communicate trade-offs openly. Every project involves decisions about where to invest effort – transparency about these choices builds trust and better outcomes.

These aren’t theoretical best practices – they’re lessons learned from a real project that continues to deliver results, and they’ve fundamentally shaped how we approach web development and long-term client partnerships.

The post Lessons from a Website Relaunch: What We Learned About Content, Design, and SEO appeared first on what. AG.

We rebuilt the connector from scratch, merged their stores, and cut monthly costs by CHF 2000. Here’s what actually happened.

The Connector Went Live – But Not Without Pain

Mid-December 2025, we launched the new ERP connector. It replaced an outdated FTP-based system that relied on custom ColdFusion code and a Shopify API version from 2020.

The old setup? Unreliable at best. Stock levels were wrong, order transmission broke regularly, and nobody could trace where things went sideways.

The new connector stabilized things – but not immediately. We spent the first two weeks of 2026 fixing edge cases and syncing issues. By week 2, it was solid.

The lesson: Even when you rebuild something properly, expect a transition period. FTP dependencies and legacy APIs don’t just disappear – they hide problems you only discover when real orders start flowing.

Price Calculation Differences Nearly Killed Automation

Here’s a fun one: Shopify calculates B2C prices including VAT per line item. Dataforce calculates B2B prices excluding VAT.

Sounds manageable, right? Wrong.

Rounding differences meant totals didn’t match between systems. Dataforce couldn’t generate invoices automatically because the numbers were off – sometimes by cents, but off enough to block the entire process.

We had to align the calculation logic on both sides, add missing VAT rates in the ERP, and fix incomplete shipping cost data. Only then could orders flow through without manual intervention.

What we’d tell anyone doing ERP integration: Test your price calculation logic with real-world orders before you go live. B2C/B2B mismatches, rounding rules, and tax handling will break things in ways mockups never reveal.

Store Merge Freed Up Budget and Simplified Operations

The Rokker Company AG ran multiple Shopify stores in parallel. Different pricing, different apps, overlapping functionality – and monthly costs piling up.

We consolidated down to a cleaner setup, harmonized pricing across markets, and cut unnecessary app subscriptions. That alone saved around CHF 2000 per month.

The merge itself finished by end of December 2025. One less store to manage means fewer errors, less admin overhead, and clearer data.

The trade-off: Merging stores sounds simple until you hit payment providers, tax rules, and marketing tracking. Which brings us to…

Subdirectories Got Blocked – by an External Agency

We designed and prepared a proper Shopify Markets structure with subdirectories (ch-de, de-de, at-de, etc.). Clean URLs, better SEO, proper market segmentation.

It was ready to launch, but a delay came up. Why? The performance marketing agency was not informed at the right time. Instructions were passed to us by proxy, generating some confusion and delay until it has been properly resolved.

The takeaway: If you’re merging stores or restructuring markets, loop in everyone who touches URLs, tracking, or ad campaigns. Marketing agencies need lead time – and surprises tank launch schedules.

What’s Still Open (and Why It Matters)

The following procedure remains unresolved:

Internal Dataforce mapping for some customer-specific quirks can only be solved three ways: extend the orders API, change Rokker’s internal process, or create custom mapping inside Dataforce itself.

We’ve laid out the options. The decision sits with the client.

Why this matters for you: Even when the technical work is done, organizational alignment determines whether you actually use what you built. Budget time for internal coordination – it’s rarely quick.

What Actually Worked

Despite the friction, the project delivered:

• Connector live and stable – orders, stock, and customer data flow reliably
• Store merge complete – cleaner structure, harmonized pricing
• CHF 2000 saved monthly – through app consolidation and smarter tooling
• GLS shipping automated – labels, tracking, and imports work without manual steps

The connector proved that even messy ERP situations (outdated APIs, mismatched calculation logic, incomplete master data) can be fixed – if you’re willing to dig into the details and rebuild properly.

Key Takeaways

Start with a Proof of Concept. We did, and it surfaced the price calculation mismatch early. Without that PoC phase, we’d have discovered those rounding issues in production – way worse.

Scope the non-obvious stuff upfront. Address logic, VAT handling, customer creation rules – these aren’t sexy, but they’re where projects break. Checklist them from day one.

Involve all stakeholders before the merge. Marketing agencies, payment providers, analytics teams – if they touch URLs or tracking, they need to be in the planning room.

Important: Customizing ERP systems incurs additional costs, which are typically not covered by agency offers.

If you’re looking at Shopify ERP integration or considering a store consolidation, check out our Shopify services to see how we approach these projects.

Reading tip: Learn more about connecting your Shopify store with ERP systems.

The post Dataforce (Palos) ERP Connector Redesign & Shopify Store Merge: Rokker Case appeared first on what. AG.