Franke's 90-Day SAP Commerce Cloud Launch: What Made It Work

We brought Franke’s SAP Commerce Cloud platform live in 90 days. That figure refers to the commerce launch, not to an ERP implementation: Franke’s S/4HANA was already in place, and the launch was one stage of a partnership with Franke that now spans six years.

I led the commerce side of the project, so this post is less about the headline and more about the decisions that made the timeline hold.

TL;DR: We brought Franke’s SAP Commerce Cloud platform live in 90 days (commerce launch), replacing a stalled, server-side-rendered shop with a headless B2B and B2C architecture integrated with S/4HANA and SAP Cloud for Customer. Manual orders fell by around 75%, the platform now connects more than 10 global channels, and the project won the SAP Quality Award for “Rapid Time to Value”. What made it work: standard before custom, weekly decisions with real authority, and integration work started on day one.

Where Franke started

When we began working with Franke, the platform was in poor shape. A previous partner had implemented it badly: outdated technology, no clean integration into the SAP landscape and no consistent service concept. A large share of orders still came in by phone and had to be keyed in by the service centre. The server-side architecture made every new country or channel expensive to connect.

Franke did not need someone to patch symptoms. They needed a partner to take technical ownership, including project management, and rebuild the platform on a stable foundation. The full background is in the Franke success story.

What made the 90-day timeline possible

SAP Commerce Cloud is a mature platform: SAP has been named a Leader in the Gartner Magic Quadrant for Digital Commerce for the eleventh time in a row (SAP News Center, November 2025). That maturity is a precondition. The timeline itself came from four decisions.

Standard first. We committed early to using SAP Commerce Cloud’s standard capabilities and storefront components wherever possible. Custom development was reserved for genuine gaps, not preferences. When someone asked “can we customise this?”, the first question back was “why?”

Decisions every week, not every month. A weekly steering meeting with Franke’s leadership, project managers and functional experts, with clear escalation paths. Everyone in the room knew what they were allowed to decide. In a 90-day project a decision that waits for the next monthly review costs you a sprint.

Visible progress every two weeks. Two-week sprints ending in a working demo. Stakeholders saw real features, not status slides, which kept momentum and made scope trade-offs concrete.

Both sides in the room. Franke’s teams brought the process and customer knowledge; we brought the SAP Commerce Cloud and integration experience. Because both were present in every decision, few questions had to travel.

The architecture we chose

Headless instead of server-side rendering. We replaced the old server-side storefront with a headless architecture for the B2B and B2C shops. Front end and commerce back end now evolve separately, which is what made it possible to add channels without touching the core. If you are weighing SAP’s own storefront framework against a custom React front end, our comparison of SAP Composable Storefront vs React/Next.js covers the trade-offs; SAP documents its Angular-based option in the Composable Storefront documentation.

Clean integration into S/4HANA and C4C. Orders, prices, availability and customer data flow between SAP Commerce Cloud, S/4HANA and SAP Cloud for Customer through defined interfaces rather than manual workarounds. That integration is what turns a shop into a process: the order that arrives online posts in the ERP without anyone retyping it.

A self-service area. Customers place and manage their own orders, check status and find their documents without calling the service centre. This is the part of the project that moved the biggest number.

What went wrong along the way

Every project hits obstacles; what matters is whether the governance can absorb them without moving the date. Two stood out.

External integrations were harder than planned. Connections to logistics and payment providers took longer than estimated. We integrated and tested each component in isolation before connecting it to the whole, which kept failures small and easy to trace.

Adoption needed more attention. Franke’s internal teams had to learn new workflows. We built training sessions and walkthroughs into the sprint rhythm, so the people who would run the platform learned it during the build, not after launch.

Neither moved the go-live, because the weekly steering could decide quickly how to respond.

The results

These are the figures from the published Franke story:

• Around 75% fewer manual orders. The self-service area took a large share of phone orders off the service centre and reduced operating costs.
• More than 10 global channels now run on the same platform, including the point-of-sale system in Australia.
• SAP Quality Award for “Rapid Time to Value”. SAP’s recognition of the delivery speed and quality of the project.

The longer-term result matters just as much: a stable platform Franke can build on instead of one it has to work around.

What other companies can take from this

Not every project needs to go live in 90 days. The patterns apply at any timeline.

Invest in governance from the start. Decision bottlenecks hurt a six-month project just as much; they only feel less urgent until they pile up in front of the go-live.

Default to standard. Every custom feature you build is a feature you maintain and upgrade. Keep the custom budget for what actually sets your business apart.

Start integration on day one. Payment, logistics and ERP connections ran in parallel with the storefront work. Waiting until the platform is “ready” is how short projects turn into long ones.

Train alongside the build. Teams who learn the system during development are productive at go-live; teams trained afterwards spend weeks catching up.

If you are still running SAP Commerce on-premise, what to do now that mainstream maintenance has ended is the more urgent read. For budgeting, see our SAP Commerce Cloud pricing and TCO guide, and if you are still choosing a partner, our overview of SAP Commerce Cloud implementation partners in Switzerland sets out the criteria that decide a project. What we deliver is summarised on our SAP Commerce Cloud solution page.

---

Planning an SAP Commerce Cloud project? We start with a discovery workshop that defines the architecture, maps the integrations and produces a realistic timeline, whether that is 90 days or six months. Talk to us.

Frequently asked questions

Can any SAP Commerce Cloud project go live in 90 days?

No, and we would not promise it. Franke’s 90 days refer to the commerce launch, within a long-running partnership and an existing S/4HANA landscape. Projects with heavy custom business logic, complex B2B workflows or a large data transformation need more time. The principles (standard first, fast decisions, early integration) shorten any timeline.

What exactly did the 90 days cover?

The launch of the SAP Commerce Cloud platform: the new headless B2B and B2C shops, the self-service area and the integration with S/4HANA and SAP Cloud for Customer. It was not a new ERP implementation; Franke’s S/4HANA was already running.

What results did Franke see?

Manual orders dropped by around 75%, which took a large load off the service centre and reduced operating costs. The platform now serves as the hub for more than 10 global sales channels, including the point-of-sale system in Australia. The project won the SAP Quality Award for Rapid Time to Value.

How much does a project like this cost?

We do not publish Franke’s budget, and no figure from one customer transfers to another. Cost depends on scope, number of channels, integrations and how much custom logic you keep. Our SAP Commerce Cloud pricing and TCO guide breaks down the typical cost blocks; a discovery workshop gives you a figure for your own scope.

What is a standards-first architecture?

It means using SAP Commerce Cloud’s built-in capabilities and storefront components as the default and writing custom code only where the platform genuinely cannot meet a requirement. Custom development is reserved for what differentiates the business, such as proprietary pricing rules. Every custom feature you skip is one you never have to maintain or upgrade.