SAP implementation templates: the SAP Activate set by phase

SAP Activate templates are the implementation templates and accelerators SAP publishes for each phase of an S/4HANA programme, from the scoping document in Prepare to the cutover plan in Deploy. You find them in the SAP Activate Roadmap Viewer and, on cloud programmes, in SAP Cloud ALM.

Short answer: you do not need all of them. You need about a dozen, each with a named owner and a sign-off point, and you should keep around 80 percent of SAP's standard structure. The table below is the set I insist on across the 21 SAP programmes I have led or rescued.

Finding the templates is easy. Knowing which ones to take seriously is the hard part.

This is the SAP implementation template set I expect to see signed off, with the owner and the point each one has to clear.

Phase	Template	Owner	Signed off before
Prepare	Project scoping document	Programme manager (sponsor approves)	Explore starts
Prepare	Business case	CFO or business owner	Funding is released
Prepare	Stakeholder matrix	Programme manager	Explore workshops are booked
Explore	Requirements and fit-gap sheet	Design authority (business and IT)	Realize starts
Realize	Configuration log	Functional leads	Each transport moves to QA
Realize	Custom development register	Development lead	Build starts on any object
Realize	Test strategy	Test manager	System integration testing starts
Realize	Data migration plan	Data migration lead	First mock load
Deploy	Cutover plan	Cutover manager	Final dress rehearsal
Deploy	Go-live readiness checklist	Programme director (sponsor signs)	Go/no-go meeting
Deploy	Hypercare support model	Service delivery lead	Go-live
Run	Performance monitoring sheet	Basis lead	Go-live

SAP Activate has six phases: Discover, Prepare, Explore, Realize, Deploy and Run. It combines SAP Best Practices content, a methodology and guided configuration. Discover is the non-committal research phase, so for most customers it ends before the contract is signed and the templates below start at Prepare.

1. 01DiscoverUsually before the contract is signed
2. 02PrepareScoping document, business case, stakeholder matrix
3. 03ExploreRequirements and fit-gap sheet
4. 04RealizeConfig log, dev register, test strategy, migration plan
5. 05DeployCutover plan, go-live readiness, hypercare
6. 06RunPerformance monitoring

Every template signed off before its gate

In the Roadmap Viewer each roadmap is broken into phases, deliverables and tasks. The templates are filed as accelerators: how-to guides, sample documents and checklists linked to the task that needs them. You can filter by phase, workstream or accelerator, which is the fastest way to pull the SAP Activate deliverables for one phase.

When you adapt them, keep around 80 percent of the standard structure. Change only what reflects your context: industry requirements, regulatory controls, regional specifics. Rewriting everything throws away the reason to use them.

What changed in the tooling

The phase structure is the same. The tooling around it has moved.

1. SAP Cloud ALM is where the templates live on cloud programmes. It is provided to customers with SAP Enterprise Support and comes with SAP cloud subscriptions such as RISE with SAP. Solution Manager 7.2 has mainstream maintenance to the end of 2027 and extended maintenance to 2030 for selected functions.
2. Joule is inside the methodology tooling. SAP added Joule to the Roadmap Viewer in 2025 and to SAP Cloud ALM, so a team can ask for task guidance or a first draft. It does not replace the person who signs the fit-gap.
3. Clean core now has levels. In August 2025 SAP introduced four clean core levels, A to D, where level A uses only released APIs and level D is not clean. Your fit-gap sheet needs a column for where each gap will land.

Projects that skip this groundwork pay for it in Explore and Realize. These three documents are the ones teams skip to get to configuration faster.

Project scoping document

It defines what the programme includes and what it does not. When someone tries to add scope three months in (and they will), this is the reference point.

The sections I expect:

1. Title, sponsor and programme manager.
2. Background: current state and the reason for change.
3. Objectives in numbers, for example "close cycle from 14 days to 5".
4. In scope, by module and process (FI/CO, MM/SD integration, data migration, UAT, go-live).
5. Out of scope, written as explicitly as the scope (HR, legacy report migration, non-ERP integrations).
6. Assumptions and constraints, such as sponsor availability for a monthly steering committee and a fixed go-live date.
7. Timeline by phase, with sign-off by the sponsor and PMO before Explore begins.

Set the timeline against what is realistic. In my experience GROW programmes take 6 to 9 months, RISE 9 to 18 months, brownfield conversions 12 to 18 months and greenfield 18 to 24 months; my SAP implementation timeline guide breaks that down by phase.

Business case template

It sets out the cost-benefit analysis in a format the finance team can read. I have had clients get programme approval on the first submission using this structure, because the numbers are clear and the assumptions are written down.

The structure:

1. Owner and summary: why now, what changes, what stays the same.
2. Problem statement: close cycle length, manual workarounds, system age.
3. Proposed approach: greenfield, brownfield or selective, with a scope summary.
4. Quantified benefits: days off the close, FTE time, error rates, audit risk.
5. Cost and funding: implementation, licence or subscription, internal time, contingency.
6. Top three risks, with probability and impact.
7. Recommendation: proceed, proceed with conditions, or defer.

One rule I hold to: the system integrator who will deliver the work should not write this document. Their incentive is to start. Yours is to finish, and my SAP business case template goes deeper on the benefits model.

Stakeholder matrix

It maps everyone affected by the implementation, their influence and how you will engage them. It tells you who needs a weekly update and who needs a heads-up before go-live.

For each group, record role, interest, influence and engagement. A typical set: the CFO as sponsor (monthly steering committee), the IT director as technical owner, the finance director as key process owner, plant managers and AP/AR users as impacted users, and internal audit at the quality gates.

Use the same matrix to plan the Prepare workshops that capture high-level requirements. Number them now in the format you will use in Explore (REQ-001 and so on), so the trace back to the original ask survives.

Explore is where the design is fixed in fit-to-standard workshops against SAP Best Practices. It is also where SAP budgets overrun, because the WRICEF count (workflows, reports, interfaces, conversions, enhancements and forms) grows here.

Do not let the phase sequence slip. On a European retail engagement in 2023 the client tried to skip Explore and spent three months building against incomplete requirements. My SAP implementation cost breakdown shows how that kind of rework turns into budget.

Requirements and fit-gap sheet

Requirements mapping traces each business need to a system component and a test case. The fit-gap analysis then shows where standard SAP meets the need and where it does not.

I keep both in one sheet, with a column for the resolution path. On S/4HANA every gap needs an explicit answer: standard configuration, key user extension, developer extension in the system, or a side-by-side extension on SAP BTP.

Req ID	Requirement	SAP component	Fit / gap	Resolution path	Test ref
REQ-001	Automated month-end close journals	FI-GL period-end closing	Fit	Recurring document configuration	TC-001
REQ-002	Purchase order approval on mobile	MM purchasing, Fiori approval app	Fit in S/4HANA	Standard app and workflow configuration	TC-003
REQ-003	Intercompany billing automation	SD billing, FI integration	Fit	Intercompany billing configuration	TC-010
REQ-004	Data archiving for privacy rules	Information Lifecycle Management	Gap	ILM policy configuration	TC-025
REQ-005	Real-time cost centre reporting	CO, embedded analytics or SAC	Gap	Embedded analytics or SAC live connection	TC-030
REQ-006	Supplier self-service portal	SAP Ariba or supplier portal	Gap	Ariba integration	TC-020

This is where the money is saved. On a European manufacturing ECC-to-S/4HANA migration in 2023, the fit-gap workshops reduced planned enhancements by 35 percent, and the saving ran into six figures.

Two rules make the sheet work. The vendor must not control scope, because every gap they mark as a build is billable work for them. A design authority of business and IT owns the clean core decisions, and modifications to SAP code need a named approver; my SAP clean core strategy explains the levels.

This is the build phase. These templates are the audit trail for every configuration decision, every development and every test result.

Configuration log

It records every system change: who made it, why and which transport it went in. When something breaks later, you trace the issue in minutes rather than days.

Each entry needs:

1. Configuration ID and module (for example MM-CONF-001).
2. Configuration path and object changed.
3. Business process affected and the reason.
4. Who configured it, and when.
5. Transport request number.
6. Key values before and after.
7. Linked test cases and approval status.

Custom development register

Every custom object gets a row before anyone writes code: ID, description, developer role, effort, status and extension type. The extension type column is where clean core is enforced.

On a European retail S/4HANA implementation in 2024, the register cut planned custom code by 30 percent. It showed where standard SAP would work just fine.

Test strategy

It puts all testing in one place: who tests what, when, in which environment and to what standard.

1. Scope: functional, integration, regression, performance and UAT across the in-scope modules.
2. Environments: development, QA, UAT and pre-production.
3. Tools: test management in SAP Cloud ALM or your existing tool, with automation and performance tools named.
4. Defect lifecycle, with severity and priority set at triage.
5. Exit criteria: all critical defects closed, UAT signed off, a regression pass rate you have agreed in advance.

SAP Activate ends Realize with integration testing and user acceptance testing. Write the exit criteria before testing starts, not when the results come in.

Data migration plan

Data migration is the workstream most likely to hurt you. The plan covers scope (business partners, materials, open items, balances), source systems, mapping rules, tools (the SAP S/4HANA Migration Cockpit), mock loads, validation and rollback.

Validation is the part teams underplan: agree record counts, sampling and balance reconciliation before the first mock load.

In SAP Activate, Deploy covers the production set-up, cutover, go-live and hypercare. These templates turn a chaotic weekend into a managed event.

SAP cutover plan template

The cutover plan maps the blackout window hour by hour. Every task has an owner, a start time and a dependency. Nobody should be standing around at 2 AM wondering what to do next.

Agree four things before you write the task list: the window (for example Friday 22:00 to Saturday 06:00), the rollback trigger, how fast the legacy system can be reactivated, and the smoke tests that prove the new system works. Then the sequence:

Step	Task	Owner	Start	Status
1	Freeze the legacy system (no postings)	Basis	22:00	Pending
2	Final data extract and reconciliation	Data migration lead	22:30	Pending
3	Production migration load	Data migration lead	23:00	Pending
4	Import remaining transports	Basis	00:30	Pending
5	Switch interfaces and network routing	Integration lead	01:30	Pending
6	Smoke test: FI posting, goods receipt, sales order	QA lead	02:00	Pending
7	Business confirmation and go/no-go	Programme director	03:00	Pending
8	Open the system to business users	Basis	06:00	Pending

Go-live readiness checklist

It decides whether you are actually ready to switch. Every item is answered yes or no, with evidence.

1. Functional: key processes and cross-module scenarios tested, open P1 and P2 defects listed, key users confirm readiness.
2. Data: master and transaction data loaded and reconciled, reconciliation reports approved, legacy freeze confirmed.
3. Finance: the period-end close configuration tested for every company code and entity.
4. Technical: cutover plan approved, transports in production, batch jobs scheduled, monitoring configured.
5. People: training coverage, access roles validated, hypercare team staffed.
6. Decision: critical risks and mitigations, go / no-go / conditional, approved by name, role and date.

The finance line is there for a reason. On a GCC retail programme in 2024, the go-live review caught a finance close configuration issue across all 25 entities two days before go-live; it would have triggered a six-figure recovery.

I have used this assessment to recommend a two-week delay on two programmes. That is what it is for.

Hypercare support model

It organises how you handle issues after launch. Without it, every problem becomes a P1.

1. Hypercare window and coverage, for example four weeks with extended hours.
2. Support channels: the incident queue, a chat channel and a phone bridge for P1s.
3. Support tiers: service desk, functional consultants, then Basis and development.
4. Response and resolution times by severity.
5. Exit criteria: no open P1 or P2 issues and a signed handover to the support organisation.

Run is the support and management of the live system. The template most teams drop too early is the one that watches performance.

Performance monitoring sheet

It tracks system health day by day so you spot slowdowns before users complain. On a European financial services programme in 2024, it caught a database issue in week 3 of hypercare that would have crashed the system during month-end.

The metrics I track, with a target, an alert threshold and an owner for each:

1. Dialog response time (95th percentile): target under 1 second, alert at 2 seconds, Basis.
2. Background jobs: 100 percent complete on schedule, alert on any failure, operations lead.
3. Database query time: target under 200 ms, alert at 500 ms, database administrator.
4. Interface error rate: under 1 percent, alert at 2 percent, integration lead.
5. Month-end close job runtime: within the agreed window, alert at 30 percent over baseline, finance operations.

SAP Activate builds quality gates into the phase roadmaps, with checkpoints for each phase. My guide to SAP quality gates covers how to set them up; here is why they need teeth.

Set pass and fail criteria at each gate. "95 percent of regression tests pass." "All FI integration scenarios are green." Criteria like these let you hold the line when the business wants to launch on a date regardless of quality.

A quality gate on a European manufacturing programme in 2024 stopped us when the integration test pass rate was at 74 percent. We held, fixed the issues and went live two weeks later. Post-go-live support tickets in the first month were half what comparable programmes typically see.

Executive sign-off should not be a rubber stamp either; the GCC retail finance close issue above was caught at exactly that review. A gate the sponsor can overrule with one phone call is not a gate. Write down who can waive it before you need to.

For the full process around these templates, see my step-by-step SAP implementation guide.

Where can I download SAP Activate templates?

In the SAP Activate Roadmap Viewer at me.sap.com/roadmapviewer. Open the roadmap for your deployment, then filter by phase or by accelerator to see the templates, guides and checklists for each task.

On cloud programmes the same content is available in SAP Cloud ALM, where tasks and deliverables can be tracked against the project.

What are the SAP Activate deliverables in each phase?

Prepare delivers the scope, plan, governance and business case. Explore delivers the fit-to-standard results, the requirements and fit-gap backlog and the solution design. Realize delivers the configured and tested system, including integration and user acceptance testing.

Deploy delivers the cutover, go-live and hypercare. Run covers the support and improvement of the live system.

Which SAP Activate phase has the most important templates?

Prepare. The scoping document, business case and stakeholder matrix set every decision that follows, and they are the ones teams skip to reach configuration faster.

Explore is a close second, because the fit-gap sheet decides the WRICEF count and that is where budgets overrun.

Can you customise SAP Activate templates?

Yes. Keep around 80 percent of the standard structure and change only what is specific to you: validation rules in pharmaceuticals, public sector procurement, SOX controls. Make those changes at the start of Prepare, not in Deploy.

Do not customise away the phase sequence, the quality gates or the go-live readiness assessment.

What should an SAP cutover plan template include?

A timed task list for the blackout window with an owner, start time and dependency for every task. Before the task list, agree the window, the rollback trigger, the time needed to reactivate the legacy system and the smoke tests.

Agree who makes the rollback call, and by what time, before cutover begins. Rollback decisions made at 4 AM without agreed criteria are where post-go-live problems start.

What is on an SAP go-live readiness checklist?

Functional, data, finance, technical and people readiness, each answered yes or no with evidence, plus a recorded go / no-go decision with names and dates.

Test the period-end close configuration for every entity before go-live. It is the check most likely to save you from a six-figure recovery.

Do SAP Activate templates work for greenfield and brownfield?

Yes. The difference is mainly in Explore. A brownfield conversion carries configuration forward, so the fit-gap focuses on what must change and which custom code standard S/4HANA can now replace; a greenfield programme starts from SAP Best Practices.

The cutover plan also differs, because a system conversion follows a different technical sequence from a greenfield data load.