How to start your SAP implementation project right

To start an SAP implementation right, settle five things before anyone configures a transaction. Choose the deployment model. Sign a charter with scope and decision rights. Name business owners who will attend design workshops. Start data and cutover work early. Build a timeline with real contingency. Get those right in the first month and most of the expensive failures never happen.

I always thought that if the system was configured correctly, an SAP implementation would run just fine. Blueprint, build, test, go live. That was the mental model I followed for years.

I have been implementing ERPs, including SAP, for 25 years in the Middle East, South-East Asia and Europe. Even when teams followed SAP Activate step by step, projects still ran into trouble. The issues were almost never technical. Weak ownership. Assumptions nobody checked. Cutover planning that started too late. These cracks look harmless at the start. Once they spread, late effort cannot fix what early visibility would have prevented.

An SAP implementation is a business change programme with a software component. The workstreams are process design, configuration, data migration, integration, testing, training and change management. Each has its own timeline, risks and owner.

Teams that treat it as a configuration exercise underfund everything that is not configuration. That is the most consistent cause of difficult go-lives I see.

For a programme starting now there is one more workstream to settle first: the deployment model. S/4HANA Cloud Public Edition (GROW with SAP), Private Edition (RISE with SAP) or on-premise. That choice shapes how every other workstream runs.

SAP Activate is SAP's delivery method. It has six phases, each with quality gates at the end. This is what each phase is for, and the thing I would not let slip.

Phase	What happens	What I make sure is right
Discover	Business case, high-level scope, deployment model	A realistic cost and timeline, not the optimistic one
Prepare	Governance, charter, team, risk register, environments	Named decision-makers with real authority
Explore	Fit-to-standard workshops, gap decisions, design sign-off	Business owners in the room, not only IT
Realize	Configuration, development, integration, system testing	Cutover planning already under way
Deploy	User acceptance testing, data loads, training, cutover	At least one full dress rehearsal
Run	Go-live, hypercare, handover to support	Hypercare staffed through the first month-end close

The most common schedule failure is a slow Explore. It compresses Realize, which compresses Deploy. User acceptance testing (UAT) gets shortened, the data rehearsal gets skipped, and the go-live happens anyway because the date was announced. The first 90 days after go-live pay for it.

1. 01Explore runs lateFit-to-standard and design sign-off slip
2. 02Realize is compressedLess time to build and test
3. 03Deploy is compressedLess time for UAT, data loads and training
4. 04Testing is cutUAT shortened, data rehearsal skipped
5. 05Go-live on the announced dateBecause the date was announced

The cost lands in hypercare, in the first 90 days

1. Design sign-off without the business

Explore produces a design. Its quality depends on whether the process owners who signed it understood what they were signing. When workshops are attended by IT and consultants only, the design can be technically correct and still unrecognisable to the people who will use it. UAT then becomes discovery instead of validation.

A simple test: three months after sign-off, ask a process owner to walk you through how a purchase order will work after go-live. If they cannot, the sign-off was not real.

2. Governance that exists on paper

Without enforced governance, scope grows informally and decisions get deferred. Good governance means a named executive sponsor, a steering committee with defined decision rights, a project manager who can hold a phase gate, and a change control process with a named approver.

In most of my projects, the CFO took on the role of project champion. When departments could not agree on a process, she made the final call. That prevented the weeks of delay that come when issues sit unresolved. My guide to SAP steering committees covers how to set this up.

3. Late cutover planning

Cutover is the most operationally complex part of the programme. A plan started a few weeks before go-live will not be rehearsed, will miss dependencies and will not have a real rollback point.

Start cutover planning in Realize. Document the sequence, run at least one full dress rehearsal and agree the rollback criteria in advance. Cutover decisions made under pressure, by people who have been awake for twenty hours, with no pre-agreed criteria, are where post-go-live disasters begin.

4. Integration testing squeezed out

Honestly, I used to think testing was a task on a checklist. Configure the system, run a few test cases, move on. Then I saw a project fall apart simply because no one checked how purchase approvals affected finance postings. That moment changed how I looked at SAP testing.

Unit tests prove a transaction works alone. The failures that hurt after go-live appear when a full process runs across modules. A goods receipt blocked by a purchase order status. A billing run stopped by a missing account determination. Test full chains, order to cash and procure to pay, and do not let them slide to the last weeks before UAT.

5. Data migration underestimated

Source data is almost always worse than the first assessment suggests. Field mappings that look simple fail on load. Record counts include inactive data. Cleaning rules need business decisions, and those take time.

A manufacturing company discovered thousands of duplicate customer records during migration and had to delay go-live by three weeks to fix them. Plan extra load cycles from the start. My article on why SAP data migration fails goes into the detail.

6. Change management treated as optional

I have seen projects where the system worked perfectly and users still clung to old processes. Not because they were difficult, but because no one walked them through the shift. When change management is cut, workarounds appear in the first week and become permanent, and support tickets stay high for months.

Heavy customisation belongs in the same category. I once worked with a client who customised over 60 percent of the system. They struggled to upgrade later and lost vendor support.

The fundamentals above have not changed. Three things need to be settled at the start of a programme today.

The deployment model comes first. Public Edition gives the narrowest customisation options and SAP runs the system. Private Edition under RISE gives more room and SAP runs the infrastructure. On-premise gives the most control and the most responsibility. Decide it in Discover. Programmes that defer it spend Explore arguing about it.

Clean core belongs in the charter. Public Edition only allows extensions through released interfaces, so it enforces clean core technically. Private Edition and on-premise do not, so it becomes a governance decision. SAP now classifies extensions from level A (released APIs only) to level D (modifications), as set out in its August 2025 clean core update. Write the target level and the approval forum into the charter, or partners will default to modifications.

AI tooling belongs in the method from day one. Joule is available inside the SAP Activate Roadmap Viewer. Joule for consultants answers configuration questions, and Joule for developers generates ABAP Cloud code. These can speed up drafting and build tasks. They do not remove the business decisions, the data work or the change effort. Ask your partner where they use them and how that shows up in the plan.

The approach should follow your risk tolerance, complexity and capacity for change. These are the common options.

Approach	What it means	Best suited for
Big bang	All modules and entities go live together	Smaller organisations with standard scope, accepting a higher go-live risk
Phased by module	Finance first, then supply chain, then HR	Modules with few cross-dependencies; lets the team learn between phases
Phased by country or entity	A template goes live in one entity, then rolls out	Groups with a global template
Brownfield conversion	Existing ECC converted to S/4HANA	Mature ECC with stable processes
Greenfield	New S/4HANA implementation	Non-SAP legacy, or ECC with heavy technical debt
Selective data transition	Chosen entities or data moved into a redesigned system	Mergers, carve-outs, partial reuse

I have seen small rollouts go live in under six months. I have also seen projects drag for two years because decisions were not made on time. If you are weighing a first implementation against a template rollout, my implementation vs rollout guide compares them.

Use this in the first month, before configuration begins. Each item has a client-side owner.

1. Executive sponsor: deployment model decided and recorded, with the reasons.
2. Programme director: charter signed, covering scope, explicit exclusions, success criteria, decision rights and change control. Verbal scope agreements evaporate. My project charter guide has a template.
3. Business leads: a named process owner per area, with time actually freed up to attend workshops.
4. Solution architect: clean core target and extension approval forum agreed.
5. Data lead: data profiling started in Prepare, not after design sign-off.
6. Cutover lead: named in Realize, with a rehearsal date already in the plan.
7. Test manager: full process-chain test scenarios listed, including approvals through to finance postings.
8. CFO: timeline checked against comparable programmes, with contingency for a slow Explore and extra data cycles. A plan that assumes everything goes right is not a plan.

What is an SAP implementation project?

It is the programme that puts SAP software in place to run a business's operations. It covers process design, configuration, data migration, integration, testing, training and change management, usually delivered with SAP Activate. The effort varies hugely with the number of entities, countries and modules, and with the state of your existing data.

What are the phases of an SAP implementation?

SAP Activate has six phases: Discover, Prepare, Explore, Realize, Deploy and Run. Discover sets the business case and scope. Prepare sets up governance and the team. Explore runs fit-to-standard workshops and confirms the design. Realize builds and tests. Deploy covers UAT, data loads, training and cutover. Run is go-live and hypercare. Each phase ends with a quality gate.

How long does an SAP implementation take?

It depends on scope and on how fast decisions are made. I have seen small rollouts go live in under six months, and projects drag for two years because decisions were not made on time. The most common cause of overrun is a slow Explore phase that compresses everything after it.

What are the most common reasons SAP implementations fail?

Design signed off without real business involvement, governance that is not enforced, late cutover planning, compressed integration testing, underestimated data migration and cut change management. All six are usually visible early and cheap to fix at that point.

What should be in an SAP project charter?

Objectives tied to measurable outcomes, scope by module, entity, country and integration, explicit exclusions, decision rights with named people, governance and escalation, success criteria, change control, major milestones and key assumptions. For a cloud programme, add the deployment model and the clean core approach. Get it signed by the sponsor and business leads before configuration begins.

What is hypercare after SAP go-live?

Hypercare is the period of intensive support after go-live, typically 30 to 90 days. The project team and the business work side by side to fix issues and stabilise operations. Keep it staffed through at least one full business cycle, including the first month-end close, because that is when many problems first appear.