SAP Activate vs. ASAP: What Really Changes in Your Daily Work?
If you are leading or participating in an SAP project and still thinking in terms of Business Blueprint documents, you must be ready for a major change in how you work. SAP Activate was introduced as the successor to ASAP back in 2013, and since then, it has been the recommended, actively developed implementation approach, while ASAP content is no longer updated. Many teams are aware of this, but few truly understand what it concretely changes in daily work.
This article arose from my research into SAP Activate, my experience in traditional SAP project management, and my experience in agile project management – and their similarities and differences.
In this text, we go through what SAP Activate is, how it fundamentally differs from ASAP, what changes depending on your role in the project, when this methodology tends to creak, and what needs to be prepared before the project even starts.
ASAP vs. SAP Activate in a Nutshell
| Criteria | ASAP (Old Approach) | SAP Activate (New Approach) |
|---|---|---|
| Number of Phases | 5 (Project Preparation → Blueprint → Realization → Final Preparation → Go-Live & Support) | 6 (Discover → Prepare → Explore → Realize → Deploy → Run) |
| Philosophy | Predominantly waterfall, strict phase sequence | Combination of agile and waterfall elements, with an emphasis on iterative work |
| Starting Point | Empty system, everything built from scratch based on requirements | Functional system with embedded SAP Best Practices |
| Requirements Analysis | Business Blueprint documents | Fit-to-Standard workshops |
| When Client Sees the System | Only in the realization/testing phase | From the Explore phase onwards (“show and tell”) |
| Target Platform | ECC, primarily on-premise | S/4HANA, with support for cloud, on-premise, and hybrid environments |
| Status | Content is no longer being developed | Active, recommended methodology |
An important note, as this is often exaggerated: Activate is not “purely agile,” nor was ASAP “pure waterfall.”
Activate is primarily a prescriptive approach that combines both elements – agile sprints dominate in the Realize phase, while some parts of the project, especially in regulated industries, still require a strict, predefined sequence.
What is really different is not “agile vs waterfall” but the starting point: ASAP starts from an empty system and the question “what does the user want the system to do,” while Activate starts from a ready-made system and the question “what can the standard already do, and why would we deviate from it.”
What Exactly is SAP Activate?
SAP Activate stands on three pillars that work together:
- SAP Best Practices – ready-made, pre-configured business processes, built on experience from over 180 industries and more than 440,000 customers worldwide.
- Guided Configuration – tools and guides that lead the team through system setup step by step, instead of building everything from scratch.
- The methodology itself – a structured, iterative project approach, with six phases that guide it from idea to stable operation in production.
With Activate, from day one, you work in an already functional system that contains ready-made business processes, and the project focuses on determining which parts of that standard fit the company and which require adaptation (gap).
The Six Phases of SAP Activate
| Phase | Main Question |
|---|---|
| 1. Discover | Is this the right solution and what do we want to achieve? |
| 2. Prepare | Who is working on the project and how will we organize it? |
| 3. Explore | How much of the standard can we utilize? |
| 4. Realize | Can we deliver configuration and testing iteratively, in sprints? |
| 5. Deploy | Are we ready for production? |
| 6. Run | How will we maintain and continuously improve the solution? |
A few notes not visible in the table, but crucial in practice:
Explore is the phase where the difference from ASAP is most felt. Instead of writing thick blueprint documents, Fit-to-Standard workshops are organized. The client is shown how the standard process looks in the system, and together it is determined what fits and what represents a gap.
Realize takes place through sprints. The team delivers functionality in smaller cycles and immediately seeks feedback, instead of waiting until the end of the project to test something. It is precisely here that many SAP teams first come into contact with an agile way of working, and this is where they most often get stuck if sprint, backlog, and regular review are not clear concepts.
Deploy includes something that is often underestimated: data migration. In Activate projects, this is not done as a one-off task at the end, but iteratively – first a mock transfer, data quality check, cleansing, a new cycle, reconciliation, and only then the final migration. Teams that take this seriously only in the Deploy phase typically pay the price in delays.
Does SAP Activate Mean You Must Now Use Scrum?
No. And this is important to clarify, as this confusion often comes up in discussions about Activate.
SAP Activate is an implementation methodology that combines Best Practices, guided configuration, and an agile way of working. It is not Scrum, nor does it prescribe it as a mandatory framework.
What is true is that the realization phase takes place through sprints, and this structure is close in spirit to Scrum. Teams that have at least a basic understanding of Scrum – what a sprint is, what a backlog is, what a regular demonstration of completed work looks like – tend to navigate an Activate project much more easily than those accustomed exclusively to waterfall.
In other words, understanding agile principles makes your job easier within Activate, but Activate and Scrum are not the same, and you do not need to formally “do Scrum” to successfully carry out an Activate project.
What Changes Depending on Your Role
If you are a Project Manager: less management through large phase deliveries, more continuous monitoring, more dependencies between parallel work streams, and the need for faster decisions than you are used to in ASAP projects.
If you are a Business User / Key User: you don’t wait until the end of the project to see the system; you participate in Fit-to-Standard workshops from the Explore phase onwards, and you are expected to make decisions about what fits and what doesn’t much earlier than before.
If you are an SAP Consultant: you do not start from the assumption that the system will be tailored to every client request. You work within the standard, and gaps become exceptions that are specifically justified and approved, not a default option.
If you are a Scrum Master or Agile Coach entering an SAP project: your task is to translate agile principles into the SAP context. A sprint here is not an abstract concept of “two weeks of work”; it is tied to specific configuration and testing activities, and stakeholder feedback becomes a critical point without which you do not move to the next sprint.
Why Mindset is a Bigger Problem than Tools
The transition to Activate is not just a technical matter; it is a change in mindset, on several levels at once:
- From “build the system according to us” to “how much of the standard can we use?”
- From documenting requirements to demonstrating the standard and noting deviations.
- From large phase deliveries to iterative work in sprints.
- From late feedback (at the end of the project) to continuous feedback (every two to three weeks).
- From an IT-led project to a project jointly led by business and IT.
A concrete example of the first point: if a warehouse worker is used to approving orders in three steps through the old system, and SAP Best Practices envisions two steps, the new mindset means the team first assesses whether the business can accept the standard two-step process, instead of automatically demanding that SAP be adapted to the old pattern.
If the team does not go through this change before the project starts, several things happen, and all are costly. Unnecessary documentation wastes time, Best Practices are not properly utilized, missing out on the savings standardization brings, and the team plans using old ASAP logic but executes using the Activate approach, creating confusion and delays all around.
When Activate Doesn’t Deliver Expected Results
Honestly, Activate is not a guarantee of success in itself, and any professional reader knows this. The methodology most often creaks when:
- the organization insists on mirroring every existing process in SAP instead of adapting to the standard,
- business users do not actively participate in Fit-to-Standard workshops,
- decisions about gaps and priorities are systematically delayed,
- agile events (Daily Scrum, Sprint Review, Sprint Retrospective) are introduced only formally, without real substance,
- standardization is misinterpreted as “SAP dictates everything,” and the team loses the will to propose deviations,
- data migration is left for the end instead of being done iteratively,
- the team tries to combine ASAP governance (approval through large phases) with the Activate delivery model (sprints); this combination very easily creates bottlenecks and confusion in decision-making.
A Simple Example from Practice
Let’s imagine a company “Small Manufacturer Ltd.” from Banja Luka migrating from an old ECC system to S/4HANA.
Using the old ASAP approach, the scenario would look like this: 3 months of writing a Business Blueprint document, a bunch of meetings where business users describe their current BBP processes, and only then does the actual configuration begin. The client first sees what the system really looks like near the end of the project.
With the Activate approach, the team spends the first two weeks in the Discover phase, using a demo system to see how S/4HANA works in practice. Then Fit-to-Standard workshops follow, where instead of describing their old habits, the team is shown standard processes, and they decide what fits and what requires adaptation. Realization takes place in sprints of two to three weeks, where something concrete is delivered and tested each time, not at the end.
The key difference worth remembering: In the Activate approach, people see the system before they decide what it will look like, not the other way around, as was the case with ASAP.
Activate Readiness Checklist (What to prepare before kick-off?)
Before the project officially starts, check if the team and organization have a clear answer to the following:
- Do key people understand what Fit-to-Standard means and why it is used instead of a blueprint?
- Is it clear who and how decides on gaps?
- Does the team understand the basic sprint model and what is expected at the end of each cycle?
- Is there a clearly defined product ownership on the business side?
- Is it defined how the backlog of requirements will be managed during the project?
- Does data migration start early, not just in the Deploy phase?
- Is the business side genuinely involved, not just formally invited to meetings?
If the answer is “no” for more than two or three items, it’s worth organizing a short, focused training for the entire project team before kick-off. It doesn’t have to be long – e.g., a one-day training dedicated to the Fit-to-Standard philosophy and the basics of agile work can save weeks of delays later.
Conclusion
SAP Activate is not just a “new version” of ASAP with changed phase names. It is an approach built around the idea of using proven practices instead of reinventing everything, and making decisions continuously, not at the end of the project.
If you are entering an Activate project tomorrow, you now know what is expected of you depending on your role, where projects most often get stuck, and what to check before kick-off. Only one question remains: do you and your team really understand how a sprint, backlog, and regular feedback work, or will you learn it along the way, during the first real sprint?
If sprint, backlog, and retrospective are not entirely clear to you, it’s worth understanding them before you enter your first Activate sprint.
I have prepared a set of Agile courses on www.whatisscrum.org that will help you understand how sprints, backlogs, and agile roles work before you find yourself in a situation where you must apply them for the first time on a project.
This bundle covers:
- What sprints are and how to plan them
- How backlog and prioritization work
- What are the roles in an agile team (and which ones you need for SAP projects)
- What daily standup, sprint review, and retrospective look like, and much more…
And of course, if you have questions, write them in the comments. How are you navigating the transition from ASAP to Activate?
