SAP Lumira (Discovery & Designer)

What it is

SAP Lumira is a brand that covered two products with different origins, different users and different migration paths — and conflating them is the most reliable way to misprice a Lumira engagement.

Lumira Discovery is the self-service line: a desktop tool where an analyst acquires a dataset, prepares it, and builds visualisations without a server-side semantic model. It grew out of SAP's response to the self-service wave, and its users are analysts working on their own data, frequently outside IT governance entirely.

Lumira Designer is Design Studio under a later name: the scripted BI application designer with an extension SDK, used by developers to build governed, event-driven analytic applications on BW and HANA. Its users are developers, its artefacts are applications, and its residue is code.

The two land in different places. Discovery content maps toward SAC's story and exploration surfaces, and its migration difficulty is dominated by an ungoverned data question — where did the analyst's dataset come from, and does the target let them get it the same way. Designer content maps toward SAC Analytic Applications, and its difficulty is dominated by custom SDK components that have to be rebuilt as custom widgets. A single plan that says "migrate Lumira" without splitting these two will be wrong about both.

What to establish first. Ask which Lumira is installed and who uses it. If the answer is analysts with desktop files, you have a governance and data-access problem wearing a migration costume. If the answer is a development team with an application catalogue, you have a code-rebuild problem. Many estates have both, in different departments, with no shared owner.

For a consultant, the brand collision is itself the insight worth selling: it explains why previous Lumira estimates at the same customer came back inconsistent, and it makes the first meeting productive rather than exploratory.

Why it matters

• Two products under one brand, with different users, different successors and different cost drivers. A plan that does not split them is wrong about both halves.

Key points

• 🔴 One brand, two products: Lumira Discovery (self-service desktop) and Lumira Designer (Design Studio renamed).
• Discovery users are analysts with their own datasets, frequently outside IT governance.
• Designer users are developers; its artefacts are scripted applications and its residue is SDK code.
• Discovery lands on SAC stories and exploration; Designer lands on SAC Analytic Applications.
• Establish which Lumira, and who uses it, before any estimate — many estates run both with no shared owner.

Common pitfalls

• Reading Lumira as one product — Signal: A single line item called "Lumira migration" Fix: Split Discovery from Designer before estimating. Different users, successors and cost drivers.
• Missing the Design Studio lineage — Signal: Old Design Studio documentation treated as irrelevant Fix: Lumira Designer is Design Studio renamed. The old material still applies.
• Ignoring where Discovery datasets come from — Signal: A migration plan that only lists visualisations Fix: The acquisition path is the migration. If the target cannot supply the same data, the visualisation is moot.

Decision framework

Sources

1. SAP Help — SAP Lumira, designer edition
2. SAP Help — SAP Analytics Cloud
3. SAP Product Availability Matrix (maintenance horizons)
4. SAP Community — Lumira board