Consulting for SAP Landscapes and S/4HANA Programs

SAP Consulting: Sound System Decisions in a Legacy SAP Landscape

SAP consulting revolves around a single, recurring question: Where in the system does a business requirement get solved — in the standard, in an approved extension outside the core, or in custom code within the core? This placement decision is the real decision. It determines the cost of the next release, how quickly a process can be changed, and how much knowledge is tied to individual people. The topic becomes important as soon as the core system is older than the processes running on it: when a migration to S/4HANA is imminent, when legal entities are merged or carved out, or when interfaces and custom developments make every adjustment costly. What’s needed here is less methodology and more experience with this exact scenario: process knowledge within the respective module, an eye for the state of integration, and the ability to justify an architectural decision in a way that will still hold up two releases later.

Clarify the Architecture Question View the Topic Areas

Discussion of an SAP system decision in an office tower

Leading companies trust our network

Scope and Accountability

What SAP Consulting Delivers — and What It Does Not

Assessment of a legacy SAP landscape as the basis for the placement decision

SAP consulting translates business requirements into system decisions and makes the downstream cost visible before it arises. The core of the work is the placement decision: Every requirement is solved in exactly one of three places — in the standard, in an approved extension outside the core, or in custom code within the core. The standard is cheap to run and awkward in the detail. An extension costs effort to build and stays untouched at a release upgrade. Custom code in the core fits at once and is paid for again at every upgrade. Whoever does not make this choice deliberately makes it anyway — only later and at a higher cost.

This includes a baseline assessment of what’s actually running: which modules are in use, which custom developments are still being used, and which interfaces are transferring data without documentation. And it places the target architecture: Which migration path suits a landscape in which three legal entities run different charts of accounts? What must be decided before the migration, and what can come afterward?

What it doesn’t do. It doesn’t answer the question of whether SAP is the right software for your business model — that’s a question that comes before SAP consulting, not inside it. It doesn’t replace your own responsibility for the system: Anyone who can’t advocate for the target architecture internally will lose it at the first conflict of interest between the business department and the budget. And it offers no guarantee regarding deadlines, which depend on data quality, testing capacity, and the speed of decision-making within the company.

Triggers

When External SAP Support Is Worth the Effort

Not every SAP task needs help from outside. If the system is running smoothly, module knowledge is spread across the team, and the backlog of changes is manageable, the internal route is the better one. In the following triggers, however, the calculation tips — for a structural reason: An internal SAP team experiences a release upgrade or a migration only once, whereas someone with twenty projects under their belt already knows the pitfalls. In these cases, external expertise doesn’t replace internal capacity; rather, it shortens decision-making processes.

1. End of Maintenance Is Approaching and the Target Design Is Missing

The deadline for the classic Business Suite has been set, but but no decision on migration path and scope exists.
Without a target design the migration turns into a rebuild of the old — with new licensing costs and without a single simplified process.
The order matters: first the placement decision per requirement; then determine the technical approach.

2. Custom Developments Block Every Release

Adjustments in the core have grown over the years; some of them are no longer used, and nobody dares to switch them off.
Every release upgrade turns into a testing marathon because it’s unclear which extension depends on which process.
A usage and dependency analysis is craft work, and it separates what’s non-essential from what’s business-critical.

3. A Legal Entity Is Added or Carved Out

After an acquisition or sale, clients, charts of accounts, master data and authorizations must be merged or separated.
The deadline is set externally — usually by contract — and leaves no room for a learning curve.
Anyone who has ever managed a system separation knows the order in which dependencies fall.

4. The Interface Landscape Has Grown and Nobody Knows All of It

Between SAP and the surrounding systems sit legacy point-to-point connections, some of which lack error handling.
Faults show up in the business first — as a missing delivery or a posting nobody can explain.
A reliable overview of data flows is the precondition for touching the core at all.

5. Module Knowledge Rests With a Single Person

A resignation, retirement, or extended absence can turn a module into a black box overnight.
Operations carry on, but every change becomes a risk because the rationale behind the settings is missing.
External depth keeps the module running while documenting what previously existed only verbally.

6. Authorizations and Evidence Do Not Survive an Audit

Roles have evolved over the years; critical combinations arise unintentionally, and there is no documentation.
Audits, internal audits, or certification turn this into a time-sensitive task.
An authorization concept is a professional assessment of responsibilities, not a technical cleanup.

Do you recognise one of these triggers? A first assessment takes twenty minutes: which question in your landscape has to be decided first, which profile is a good fit for it — and and whether you need anyone from outside at all.

Have Your System Reviewed

Topic Areas

The Topic Areas of SAP Consulting at a Glance

The topic areas interlock, but are rarely commissioned at the same time. It usually begins with a specific occasion — an upcoming migration, an integration problem, or a module without support — and the scope of the project is determined by which decisions still need to be made. The following overview organizes the fields according to how far they are from the core of the system.

Target Architecture and System Design

The system split and the question of where each requirement gets solved: one client or multiple clients; which processes stay in the core; and which extensions are built outside it. In addition, the decisions that must be made before each technical step — chart of accounts, organizational structure, and master data ownership.

Migration to S/4HANA

Evaluation of migration paths — a greenfield build, converting the existing system, or a selective path per legal entity — based on data quality, the volume of custom code, and schedule constraints. The result is a migration path with specified prerequisites; not a tool comparison.

Processes in the Core Modules

Professional work in finance and controlling, materials management and sales, production and warehouse logistics: Which configuration setting produces which behavior; which deviations from the standard are justified, and which are merely historical?

Integration, Interfaces and Data Flows

The connection between SAP and everything around it: middleware and integration services, error handling and recovery, and responsibility for data ownership. This is where it is determined whether a landscape remains adaptable or becomes locked into dependencies.

Custom Development, Extensions and a Clean Core

Take stock of adjustments, measure usage, plan the retirement: What disappears into the standard, what is moved to an extension outside the core, and what is deliberately kept as custom code — with justification and a designated owner.

Operations, Authorizations and System Hygiene

Role and authorization concepts with audit-ready documentation, transport management and approval paths, system monitoring, and performance. This is the part that rarely constitutes a project in and of itself, yet makes the difference between smooth and troubled operations over the years.

Which topic area matters first for you depends on your starting point — we can figure that out in a brief conversation.

Sharpen the Target Architecture

Engagement Types

How External SAP Expertise Is Embedded in a System Environment

In the SAP environment, in addition to technical expertise, what decides is accountability: Who is authorized to make an architectural decision, who implements it, and who is accountable for it once it is in operation? The engagement type follows from that. All four approaches work only if system responsibility remains in-house — external expertise reasons and builds, it does not decide in your place.

Choose an Engagement Type

Second Opinion

Review of an Architecture Decision

An experienced professional reviews a draft that has already been prepared, drawing on their own project experience: the placement decision per requirement, the system split and the assumptions about data quality. The scope of the assignment is narrowly defined and concludes with a reasoned recommendation, not with implementation.

Module Depth

Expert Reinforcement in a Subproject

One or a few specialists work inside your project team on a clearly defined portion of the project — a module, an integration path, or an authorization concept. You retain control, and the knowledge moves into the team while the work is done.

Bridging a Vacancy

Interim SAP Responsibility

An external person takes on leadership or module responsibility as long as the position remains vacant or a dual workload would otherwise be unmanageable. They run day-to-day operations and keeps pending decisions moving forward rather than postponing them.

Program Support

Guidance Through a Multi-Year Migration

A small unit overseeing multiple subprojects and legal entities: keeping dependencies visible, preparing decisions and flagging deviations early. This only makes sense once the organization reaches a size where nobody can keep track of every thread on the side.

System Environments

SAP Across Industries: Where the Core System Sets the Pace

An SAP landscape cannot be evaluated industry-neutrally, because the industry determines which processes must be at the core and which can be secondary. In series production, planning is at the heart of the process, and any deviation in the material flow impacts the production line within hours. In project-based business, the cost estimate carries for years and must account for change orders, partial invoices, and warranties. In the process industry, batch tracking and traceability are not optional features but requirements for regulatory approval. In retail, assortment changes and promotion logic set the pace; in logistics, it’s inventory control; and in the utilities sector, it’s regulated billing with its own deadlines.

That’s why we staff for industry experience and not just on module knowledge: Anyone who has mapped batch traceability, change orders, or grid billing in the standard system recognizes the requirement as a special case — and knows exactly where the standard has an answer for exactly that and where an extension is actually necessary. The following six areas are the ones our clients inquire about most frequently; they represent a selection and not an exhaustive list of what we can staff.

Initiatives

SAP Initiatives and What Each One Decides

What gets commissioned in an SAP environment falls largely into a few patterns. They differ less in effort than in what is decided at the end. The following four are examples, not an exhaustive list — and they often follow one another.

Migration to S/4HANA

Starting point: The maintenance deadline is set, the path is not. Decided are the migration path per legal entity, the scope of the process work and what is deliberately dropped. What success depends on: ensuring that the placement decision is made per requirement before the first technical step is taken.

Retiring Custom Developments

Starting point: Custom code in the core makes every release more expensive, and some of it is no longer used. A decision is made per adjustment: standard, extension outside the core, or deliberate retention. What success depends on: a usage measurement nobody disputes any more.

Separating or Merging Legal Entities

Starting point: An acquisition or a sale sets a contractual deadline. Decided are the client structure, the handling of master data and historical records, and the split of authorizations. What success depends on: a sequence of steps that takes these dependencies into account.

Renewing the Integration Layer

Starting point: Starting point: legacy point-to-point connections without error handling, faults noticed in the business. Decided is which data flows will run through an integration service and who holds data ownership. What success depends on: restart and monitoring, not the tool.

The Stages of an SAP Program

Scope and order differ with the starting point, the number of legal entities, and the existing stock of custom developments. The stages themselves repeat; skip one and you make it up later under deadline pressure.

System inventory and interfaces are consolidated for an SAP baseline assessment

1. Take Stock

Inventory modules, clients, custom developments and interfaces — including a measurement of what is actually used.

Check data quality where it slows the migration down: master data, open items, history.

The result is an inventory the business departments and IT no longer argue about.

Technical coordination within the team regarding the target state for an SAP landscape

2. Set the Target Architecture and the Placement Decisions

For every requirement the place is set: the standard, an extension outside the core, or custom code inside the core.

Organizational structure, chart of accounts and master data ownership are decided up front, not during the project.

Whatever is deliberately left behind is on the list, with a reason.

Management team decides on the migration path for an SAP landscape

3. Choose the Migration Path

Greenfield build, conversion of the existing system, or a selective path per legal entity — assessed against data and deadlines.

The cutover sequence is fixed to dependencies, not to preferred dates.

The path names the prerequisites that have to be met before the start.

Test run of an adjusted process in the SAP system

4. Build and Test

Configure processes, build extensions, connect interfaces — in small increments that can be signed off.

Test with real data and real volumes; the business departments sign off, not the project management.

Every deviation from the standard is justified and documented the moment it is created.

Approval of the system migration prior to the go-live

5. Hand Over to Operations

Data migration, authorizations, approval paths and the fallback plan are settled before the cutover.

Users are trained on their own transactions, not on sample cases.

Operations takes over with named responsibilities per module and interface.

Reassessment of system performance after the migration is complete

6. Stabilize and Measure

Incidents are sorted by cause: configuration, data, extension or handling.

Measurement runs against the baseline recorded before the start — cycle times, closing duration, error rates.

The handover point is fixed from the outset: after that your organization runs the system.

Cost Framework

What SAP Consulting Costs: Daily Rates and Budget Ranges

We bill for external SAP expertise based on a daily rate. This rate is determined by five factors: seniority and the number of migrations supported, module and specialization (architecture, integration and authorizations sit above the mean), percentage of on-site presence, duration of the mandate — longer engagements carry a lower rate per day — and availability of the desired profile.

The ranges across our current pool in the SAP & Enterprise Systems practice area are currently between €750 and €1,650 per day. The tiles below show these rates by role, as they are also listed on the respective role pages.

Freelance SAP Architect

€1,050 – €1,650 per day
Freelance SAP FI/CO Consultant

€960 – €1,500 per day
Freelance ServiceNow Solution Architect

€950 – €1,500 per day
Freelance SAP BTP / Integration Consultant

€950 – €1,500 per day
Freelance SAP Solution Architect

€1,000 – €1,500 per day
Freelance SAP S/4HANA Consultant

€1,000 – €1,500 per day
Freelance SAP MM/WM Consultant

€950 – €1,400 per day
Freelance SAP MM / SD Consultant

€900 – €1,400 per day
Freelance SAP EWM Consultant

€900 – €1,300 per day
Freelance SAP CPI Consultant

€900 – €1,300 per day
Freelance SAP Ariba Consultant

€900 – €1,300 per day
Freelance ServiceNow Developer

€850 – €1,300 per day
Freelance SAP Rollout Manager

€850 – €1,250 per day
Freelance SAP Basis Administrator

€850 – €1,250 per day
Freelance SAP Security Consultant

€850 – €1,200 per day
Freelance SAP PP Consultant

€850 – €1,200 per day
Freelance SAP Fiori Developer

€800 – €1,150 per day
Freelance SAP SD Consultant

€800 – €1,100 per day
Freelance SAP ABAP Developer

€750 – €1,050 per day

Every range is stated on the matching role page too, not on request.

How to set up an SAP budget. We calculate in person-days per stage, not as a single total. A baseline assessment of custom developments, including usage measurements, typically involves a manageable two-digit number of person-days for a mid-sized landscape. Defining a target architecture with a placement decision per requirement is a matter of decision-making rounds, not of effort. The migration itself is calculated per legal entity and per wave, so that after the first wave, a decision can still be made as to whether the second wave will proceed in the same manner. Interim responsibility is calculated differently: fixed weekdays over the duration of the vacancy.

What matters is not the daily rate, but its relationship to what depends on the system. Where a release upgrade regularly ties up weeks of testing effort due to unresolved custom developments, a decision to retire them pays for itself inside a year. Where a module runs stably and no one wants to change it, external support offers no benefit — we provide this answer before submitting a proposal.

This is what sets us apart from a system integrator or a consulting firm. You engage individual specialists, not an apparatus: no project management layer that you help pay for, no partner margin and no base charge for methodology. In return, you do not get end-to-end accountability from one hand — the professional lead stays with you. We do not price system outcomes as fixed fees: they set the incentive to keep the scope small rather than to make the right decision.

Which profile fits depends on the open question: An architectural decision requires a different set of skills than retiring a custom development in the core. The full overview sits under SAP & Enterprise Systems — including Freelance SAP Architect, Freelance SAP S/4HANA Consultant, Freelance SAP Basis Administrator, and Freelance SAP Rollout Manager. The six cards above are an extract from twenty roles in this practice area; adjacent fields are IT Consulting, Business Intelligence Consulting, and Process Consulting.

54 %

of the SAP customer organisations surveyed still run SAP ECC or the Business Suite — in 2024, that figure was 68 percent.

DSAG Investment Report 2026, 198 participants

2030

extended maintenance for Business Suite 7 ends — regular maintenance runs out at the end of 2027, and the extension costs a two-percentage-point surcharge.

SAP Business Suite 7, maintenance deadlines

28 %

expect a shrinking SAP budget — down from 19 percent in the previous survey. The migration therefore falls into a period of tighter funds.

DSAG Investment Report 2026, 198 participants

SAP consulting helps companies translate business requirements into system decisions and make the downstream cost visible in advance. The core of it is the placement decision: Each requirement is addressed either in the standard, in an approved extension outside the core system, or through custom code within the core system. This is complemented by a baseline assessment of the current landscape, an assessment of migration paths, hands-on work inside the modules, as well as integration, authorizations, and operations.

General IT consulting asks which systems a company needs and how they interact. SAP consulting takes the decision for SAP as given and works inside that landscape: module behavior, standard scope, extension model, and release consequences. Where the system choice itself is still open, the path leads through IT consulting; where processes are being recut independently of the software, the path leads through process consulting.

We bill based on a daily rate. In the SAP & Enterprise Systems practice area, our current rates range from €750 to €1,650 per day; the tiles in the cost section show these rates by role. Architecture, integration, and authorization profiles fall at the upper end of the range, while development profiles fall below it. We scope in person-days per stage, not as a flat project fee — this allows you to decide after the first stage whether the next one justifies the effort.

Based on five factors: seniority and the number of migrations already supported; module and specialization, with architecture, integration, and authorizations ranking above average; percentage of on-site presence, because travel time reduces availability; duration of the mandate, since longer engagements carry a lower rate per day; and the availability of candidates matching the desired profile at the time of the request.

Regular maintenance for the last enhancement packages of SAP Business Suite 7 will end in late 2027. Anyone booking extended maintenance has until the end of 2030 and will pay a two-percentage-point surcharge on top of the base maintenance fee. After that, customer-specific maintenance will continue without any new legal or functional adjustments. Older release levels run out earlier — so the date that counts depends on your own release level.

The fact that adjustments no longer sit in the core of the system, but rather in extensions beside it, connected through approved interfaces. The benefit becomes apparent during a release upgrade: whatever sits outside the core does not have to be retested again. The price is build effort and one more operational responsibility. In practice, therefore, it’s not about purity, but about making a reasoned decision per adjustment — with a designated owner.

A system integrator assumes overall responsibility and brings capacity across the board; that fits when nobody in-house can take the professional lead. Individual specialists fit when the lead is internal and experience is missing in one spot — for an architectural decision, a module left without an owner, an integration path, or a vacancy. The difference lies less in the daily rate than in the question of who is ultimately responsible for the decision.

Against metrics recorded before the start: cycle time of the affected processes, duration of the month-end close, error rate in the interfaces, testing effort at the next release upgrade, and the number of adjustments still active in the core. Without this baseline, the only thing you can show afterwards is that the deadline was met — and that is the weakest of all statements about a system project.

You can rely on us

Excellent. We are not the only ones who think so.

consultingheads has received several awards from leading trade magazines and independent third parties.

Award for consultingheads: F.A.Z. Institut TOP Berater 2026

Award for consultingheads: kununu Top Company 2025

Award for consultingheads: kununu Top Company 2024

Award for consultingheads: kununu Top Company 2023

Initial Consultation

Let's bring order to the system question.

An assessment of your system landscape in twenty minutes

One named first decision instead of a methodology overview

The daily rate range per role is stated openly on this page

Twenty minutes during which we'll assess your starting point and identify the first decision you need to make.

Suggest a Time

SAP Consulting: Sound System Decisions in a Legacy SAP Landscape

Leading companies trust our network

What SAP Consulting Delivers — and What It Does Not

When External SAP Support Is Worth the Effort

1. End of Maintenance Is Approaching and the Target Design Is Missing

2. Custom Developments Block Every Release

3. A Legal Entity Is Added or Carved Out

4. The Interface Landscape Has Grown and Nobody Knows All of It

5. Module Knowledge Rests With a Single Person

6. Authorizations and Evidence Do Not Survive an Audit

The Topic Areas of SAP Consulting at a Glance

Target Architecture and System Design

Migration to S/4HANA

Processes in the Core Modules

Integration, Interfaces and Data Flows

Custom Development, Extensions and a Clean Core

Operations, Authorizations and System Hygiene

How External SAP Expertise Is Embedded in a System Environment

Review of an Architecture Decision

Expert Reinforcement in a Subproject

Interim SAP Responsibility

Guidance Through a Multi-Year Migration

SAP Across Industries: Where the Core System Sets the Pace

Automotive & Supplier Industry

Machinery & Plant Engineering

Chemicals & Pharmaceuticals

Retail & Consumer Goods

Logistics & Transportation

Energy & Utilities

Automotive & Supplier Industry

Machinery & Plant Engineering

Chemicals & Pharmaceuticals

Retail & Consumer Goods

Logistics & Transportation

Energy & Utilities

SAP Initiatives and What Each One Decides

Migration to S/4HANA

Retiring Custom Developments

Separating or Merging Legal Entities

Renewing the Integration Layer

Which Role Profiles an SAP Environment Needs

The Stages of an SAP Program

1. Take Stock

2. Set the Target Architecture and the Placement Decisions

3. Choose the Migration Path

4. Build and Test

5. Hand Over to Operations

6. Stabilize and Measure

What SAP Consulting Costs: Daily Rates and Budget Ranges

The Migration Is Pressing, Budgets Are Growing More Slowly

54 %

2030

28 %

Frequently Asked Questions About SAP Consulting

Excellent. We are not the only ones who think so.

Let's bring order to the system question.