SAP Activate: A Practitioner’s Reference

What the methodology actually requires, from someone who has run it.

henkadigital | Insights | SAP | Methodology

We have used SAP Activate on multiple S/4HANA Cloud and On-Premise implementations. It is the methodology SAP expects its partners and customers to follow, and for good reason: when applied with discipline, it works. When applied carelessly, which is more common, it becomes a checkbox exercise that adds process without adding value.

This reference covers the methodology’s structure, its phases, and what each phase actually demands from a delivery perspective. It is written for program leaders, project managers, and delivery teams who need to understand not just what SAP Activate prescribes, but where the real risks and decision points sit.

SAP Activate Methodology

SAP introduced the Activate Methodology in 2015 to accelerate delivery using agile principles. It is one of three components within the broader Activate framework, alongside SAP Best Practices and Guided Configuration. The core message is straightforward: start with pre-built content, stay as close to the standard as possible, and accelerate time to value.

In practice, this standard-first philosophy is where most programs either succeed or begin to unravel. The methodology provides clear guardrails, but only if the delivery team enforces them. The moment a project team starts treating fit-to-standard workshops as requirements-gathering sessions for custom development, the methodology’s value collapses.

The Three Components

The Six Phases

The methodology defines six phases: Discover, Prepare, Explore, Realize, Deploy, and Run. In practice, a delivery team focuses on four. The Discover phase belongs to the sales cycle, and the Run phase is post-transition to support, outside the project boundary. That leaves Prepare, Explore, Realize, and Deploy as the operational core of any SAP Activate project.

Each phase has a specific goal, a defined set of deliverables, and a quality gate that must be passed before the next phase begins. The quality gates are where governance earns its keep, or where it fails silently when teams treat them as formalities.

Discover

The Discover phase exists to understand what the solution can do, what the business needs, and whether the two can be aligned into a viable adoption strategy. By the end of this phase, the implementation scope, project timelines, and target solution model should be defined and the project should be ready to begin.

In the methodology, the Project Manager has no formal role during Discover. But if the PM has already been selected and is available, getting involved early pays dividends. The Discover phase is still part of the sales cycle, which means the budget is typically scoped within a specific statement of work. Some clients treat spend during Discover as part of the overall project budget; others treat it separately. Either way, the PM should be tracking it.

More importantly, the Discover phase is the right time for the PM to build familiarity with SAP Activate itself, understand the client’s organizational context, and begin establishing the relationship with the customer team. The methodology has a specific way of working. Discovering that during Prepare is too late.

Prepare

The Prepare phase covers project initiation, planning, team assignment, and infrastructure readiness. This is where the project is formally started, plans are finalized, and the foundation for everything that follows is laid.

This is where the Project Manager starts, and it is the most critical phase from a delivery governance perspective. The key activities and deliverables do not differ dramatically from non-Activate projects: project charter, governance model, communication plan, risk register, resource plan, infrastructure provisioning. What differs is the integration with SAP’s work package structure and the emphasis on starting with executable content rather than a blank slate.

Key work packages in Prepare:

Project Management: Project initiation, execution monitoring, controlling, and kickoff workshop.
Integration Management: Confirm integration prerequisites and establish the integration architecture.
Customer Team Enablement: Level 1 self-enablement on SAP Best Practices and the solution scope.
Solution Adoption: Value determination and initial adoption planning.

For Public Cloud implementations, the Prepare phase also includes provisioning the initial system and beginning self-enablement activities. The team should exit this phase with a clear understanding of the SAP solution they are implementing, a functioning project governance structure, and an infrastructure environment ready for the Explore phase.

Practitioner observation: The governance decisions made during Prepare, specifically who has authority to approve scope changes, how quality gates are enforced, and how RAID items are escalated, determine whether the rest of the project runs on discipline or on hope. We have seen more programs fail from weak Prepare-phase governance design than from any technical decision made later.

Explore

The Explore phase is where fit/gap analysis happens. The goal is to validate that the solution functionality included in the scope can satisfy business requirements, identify gaps, and determine configuration values for the Realize phase.

In practice, this means a series of structured workshops led by industry and solution experts. The format differs slightly between deployment models. For S/4HANA On-Premise, these are show-and-tell sessions where the team reviews SAP best practice functionality, identifies delta requirements or gaps, and documents the conceptual design of the target solution. All functional and technical requirements, project issues, and gaps are captured. For S/4HANA Cloud, the workshops focus on reviewing best practice functionality, identifying delta requirements, and determining the configuration of the cloud solution.

The Explore phase is critical to the success of the entire project. The PM must ensure that the implementation team understands the methodology and enforces the standard-first principle. Deviations from SAP standard must be challenged and thoroughly documented, because every deviation introduces complexity, cost, and additional time to deploy.

This is also where change management pressure first appears. Key users participating in the workshops will naturally resist solutions that differ significantly from current processes. The project team must have enough experience to distinguish between legitimate business requirements and resistance to change. That distinction is a judgement call, and it requires practitioners who have navigated it before.

Key work packages in Explore:

Solution Design: Scope validation, fit-gap analysis, and configuration determination.
Integration Preparation: Confirm integration prerequisites and begin integration architecture.
Customer Team Enablement: Level 1 and Level 2 enablement on solution functionality.
Custom Extensions Management: Identify and prepare solution extensions where standard is insufficient.
Solution Configuration: Begin system configuration based on workshop outcomes.
Data Migration: Develop migration plan and begin data preparation.
Solution Adoption: Value realization planning and value audits.

Practitioner observation: The biggest risk in Explore is not missing a requirement. It is accepting too many custom requirements without challenging them. Every gap that gets approved without rigorous justification becomes scope in Realize, testing in Deploy, and a maintenance burden in Run. The PM’s job is to protect the standard-first principle, even when the client team pushes back.

Realize

The Realize phase is where the solution is incrementally built and tested. The project team takes the process requirements and backlog captured during Explore and translates them into a configured, integrated, and tested system environment.

This phase runs in iterative sprints. The project team uses a series of iterations to configure, test, confirm, and document the end-to-end solution. Data conversion programs are created. The team works actively with business representatives to ensure good fit between the built solution and the requirements from the backlog. Multiple iterations are released to business users to accelerate time to value and provide early access to finalized functionality. Each release is tested through end-to-end integration testing and user acceptance testing.

Configuration decisions and the solution design are documented in the project management or agile tool. All development, including interfaces, integration points, data conversion programs, reports, and enhancements, is documented. Once these activities are complete for a particular release and business approval is obtained, the release is made available in the production environment.

Key work packages in Realize:

Customer Team Enablement: Level 2 enablement and deeper solution training.
Custom Extensions Management: Solution extension development and validation.
Solution Configuration: System configuration including forms, reports, and access/authorization.
Solution Walkthrough: Business walkthrough sessions for each sprint release.
Data Migration: Data preparation, load, and validation cycles.
Integration Setup: Integration setup in test and production systems.
Solution Testing: Test preparation and execution across integration and UAT.
Solution Adoption: Value audits, change management planning, and end user training.
Support Readiness: Production support plan development.
Cutover Management: Prepare cutover plan and begin rehearsal planning.

Practitioner observation: Realize is the longest phase and the one where scope drift compounds silently. Change requests submitted during Realize should be evaluated not just for their immediate effort, but for their downstream impact on testing, data migration, integration, and cutover. Most programs track CRs by count and effort. The ones that succeed also track cumulative schedule impact and pattern analysis: are the CRs coming from the same workstream? The same stakeholder? The same gap that was supposed to be closed in Explore?

Deploy

The Deploy phase covers production system setup, organizational readiness confirmation, cutover execution, and go-live. This is where the project transitions from build to operations.

The phase is compressed and high-stakes. Production setup, support readiness handover, and cutover management are the three critical workstreams running in parallel. Cutover rehearsals are essential, not optional. Each rehearsal should be tracked for completeness and elapsed time, with gaps flagged and resolved before the live cutover window.

Key work packages in Deploy:

Project Management: Execution monitoring, controlling, and project close.
Support Readiness: Handover to support organization and production support activation.
Cutover Management: Production setup and production cutover execution.

Practitioner observation: The Deploy phase is where poor governance decisions from earlier phases manifest as real consequences. Incomplete testing, unresolved data quality issues, and untrained users do not surface gradually. They surface on go-live day, all at once. The PM’s primary job during Deploy is not execution management. It is ensuring that every prerequisite for a successful go-live has been genuinely met, not just signed off on.

Run

The Run phase is about optimizing and automating the operability of the deployed solution. It sits outside the project boundary and belongs to the support organization: maintaining IT systems in a functioning and operating condition, guaranteeing availability, and ensuring performance levels support business operations.

From a project perspective, Run begins when the handover to support is complete and the project is formally closed. The quality of this handover, specifically the completeness of documentation, the clarity of known issues, and the readiness of the support team, directly determines how smoothly the organization transitions from project mode to operational mode.

What Makes the Difference

SAP Activate provides the structure. What determines whether that structure delivers value is the quality of governance applied at every phase gate, the discipline of the standard-first principle during Explore, and the experience of the practitioners leading the program.

A few things consistently separate programs that succeed from programs that struggle:

Agile fluency matters. The PM and the delivery team should be comfortable with Scrum or a similar framework. SAP Activate assumes iterative delivery. Teams that try to run it as a waterfall project with agile labels will produce waterfall results on an agile timeline.
Tooling accelerates governance. The project team benefits from using an agile tool (Jira, Targetprocess, Azure DevOps) to manage collaboration. Phases and deliverables can be loaded into the tool, and activities tracked by sprint. An alternative to a standalone agile tool is SAP Solution Manager itself, which includes project management and focused build capabilities.
RAID discipline is non-negotiable. Risks, assumptions, issues, and decisions must be captured continuously, not updated retroactively before steering committees. The RAID log is the single most important governance artifact in any SAP Activate project. If it is not current, the steering committee is making decisions with incomplete information.
Quality gates must be enforced. Every phase transition should include a formal quality gate review. The gate is not a status update. It is a decision point: does the project meet the defined criteria to proceed, or does it not? Treating gates as formalities is how programs accumulate hidden risk.

Resources

SAP Activate Roadmap Viewer (roadmaps.sap.com)
SAP Best Practices (rapid.sap.com)
Scrum Guide (scrumguides.org)

henkadigital provides senior program leadership and AI-powered delivery intelligence for enterprise ERP transformations. If your SAP Activate program needs experienced practitioners, not just process documentation, let’s talk.