If you come from on-premise SAP projects, your instinct is: collect requirements → write a blueprint → configure whatever the business asks for. In SAP Cloud ERP (S/4HANA Cloud Public Edition) that instinct will get you into trouble.
SAP Activate is the methodology SAP designed for this world. This article explains what each phase really means on a public cloud project, what you produce, and the mistakes juniors most often make.
The one-sentence version: In Cloud ERP you don't design the system from a blank page — you start from SAP's preconfigured best practices, show them to the business, and only treat what truly doesn't fit as a gap.
1. Three ideas behind Activate
| Idea | What it means in practice |
|---|---|
| Start with ready-to-run processes | The system comes with SAP Best Practices: hundreds of preconfigured business processes ("scope items"), each with a process diagram, test script and setup content. You pick and adjust; you don't build from zero. |
| Fit-to-Standard, not blueprint | Instead of asking "how do you work today?", you demonstrate the standard process and ask "can you run your business this way?". |
| Agile and iterative | Configuration and testing happen in short sprints with the business watching, not in one big build followed by one big test. |
And one rule that sits above all three: keep the core clean. You cannot modify SAP's code in Public Edition. Extensions go through approved, upgrade-safe channels (see section 4).
2. The six phases
Discover → Prepare → Explore → Realize → Deploy → Run
▲Q ▲Q ▲Q ▲Q ▲Q
(quality gate before each phase transition)
Discover — "Is Cloud ERP right for this company?"
- Understand the business, its process scope and its current IT/integration landscape.
- Check what's available: scope items, localization for the countries involved, additional licenses.
- Explain the cloud model honestly: standard processes, release upgrades the customer cannot skip, regression testing every release, and change management.
- Output: agreed scope, timeline and target solution model.
Prepare — "Set up the project and the systems"
- Project kickoff, team roles, plan, governance.
- Provision the system landscape. A typical Public Edition project uses a starter system (preconfigured, for Fit-to-Standard demos) and then a three-system landscape: development, test and production.
- Set up the implementation tooling — typically SAP Cloud ALM for tasks, requirements, process documentation and testing.
- Start configuration groundwork in Central Business Configuration (CBC): scope selection and organizational structure.
- Output: project plan, ready landscape, confirmed scope items.
Explore — "Fit-to-Standard workshops"
This is the heart of a Cloud ERP project and the phase where most value (or damage) is created.
- For each process area, demo the standard scope item in the starter system using realistic data.
- Walk through the process step by step with the key users.
- Record each difference as either:
- Configuration value (e.g. your company codes, plants, payment terms) — normal, expected;
- Delta requirement (a real gap) — must be justified, prioritized and given a solution approach.
- Challenge every gap: is this a real business need, or a habit from the old system?
- Output: confirmed processes, configuration values, a delta requirements backlog (with integration, data migration, output forms, roles and extensions identified).
Realize — "Build and test in sprints"
- Configure in CBC and the development system; build approved extensions and integrations.
- Load data repeatedly into test systems using the standard migration tool (Migrate Your Data) and its templates.
- Test in sprints with key users: unit → string → integration → user acceptance. Use test automation where available — you will need those scripts again at every upgrade.
- Prepare roles, training and the cutover plan.
- Output: a tested solution, migration rehearsals done, trained key users.
Deploy — "Go live"
- Final migration rehearsal, cutover plan execution, production data load.
- End-user training, go/no-go decision, go-live.
- Output: a running production system.
Run — "Hypercare and continuous improvement"
- Hypercare support right after go-live.
- Then a rhythm that never ends in the cloud: every release, review new features, run regression tests, and decide what to adopt.
- Output: a stable system and a plan for adopting innovations.
Quality gates
Before each phase transition, the project passes a quality gate: a checklist reviewed with the customer and partner (scope confirmed? gaps mitigated? integration listed? resources in place? sign-offs done?). Treat Q-gates as your friend — they catch expectation mismatches while they're still cheap to fix.
3. What's different from an on-premise project
| On-premise habit | Cloud ERP reality |
|---|---|
| Write a long as-is / to-be blueprint | Run Fit-to-Standard workshops on a live preconfigured system |
| Configure anything in the IMG (SPRO) | Configure through CBC and configuration apps (SSCUIs) within the scope you activated |
| Modify standard code if the business insists | Not possible — extend in upgrade-safe ways only |
| Upgrade when the company decides | Releases arrive on SAP's schedule; you regression-test and adapt |
| Lots of custom reports | First check standard Fiori apps and analytics; build custom CDS views only when needed |
| Data loaded with custom programs (LSMW etc.) | Standard migration templates and the Migrate Your Data app |
4. Handling gaps: the extension ladder
When a delta requirement is confirmed, try the options from top to bottom:
- Change the process — can the business adopt the standard? (Cheapest, most upgrade-proof.)
- Configuration — another setting or another scope item may already solve it.
- Key-user extensibility — custom fields, custom logic, custom CDS views, custom business objects, forms — built in apps, no developer needed.
- Developer extensibility — ABAP Cloud development on released APIs only.
- Side-by-side on SAP BTP — a separate app or integration on SAP Business Technology Platform.
Each step down costs more to build and to maintain through every release.
5. Common mistakes juniors make
- Turning Fit-to-Standard into a requirements interview. If you ask "what do you need?", you'll get the old system back. Demo first, then discuss.
- Accepting every gap. Each gap is a cost forever. Ask "what happens if we don't build this?"
- Ignoring integration until Realize. Integrations (HQ systems, banks, MES, e-invoicing, tax platforms) often decide the timeline. List them in Explore.
- Underestimating data migration. Data cleansing is a business task and starts in Explore, not two weeks before go-live.
- Forgetting the release cycle. Build test scripts you can re-run; you'll need them twice a year.
- Promising features from the roadmap. Separate what is released today from what is planned.
6. Where to learn more (official, free)
- SAP Activate Roadmap Viewer — the full task list per phase, with accelerators (templates).
- SAP Signavio Process Navigator — every scope item with process diagrams and test scripts.
- SAP Learning — free onboarding courses for SAP Cloud ERP.
- SAP Help Portal — product documentation for S/4HANA Cloud Public Edition.