The US CFO’s Guide to SAP Migration: How to Evaluate Estimates and True TCO Across Integrators

Discover how SAP combines logistics execution, carbon tracking, and ESG reporting to build more sustainable and efficient supply chains.

Two SAP S/4HANA implementation proposals can describe the same project and differ by thousands of dollars. The difference rarely comes from software licensing. It usually comes from assumptions, scope boundaries, delivery methodology, and the way future work is priced after the contract is signed.

For a CFO, the lowest estimate does not automatically represent the lowest financial exposure. Migration costs extend beyond implementation services. Custom code remediation, testing cycles, change orders, post-go-live support, SAP BTP services, and future upgrades all affect five-year total cost of ownership. A proposal that appears less expensive during procurement can become the costlier option after the project begins.

In this article, we will explain why SAP migration estimates vary, how to compare pricing models across integrators, where hidden costs typically appear, and which contractual safeguards reduce financial risk.

How Often Do SAP Migration Projects Exceed Their Budget?

More often than not.

Research from Horváth covering 200 SAP customer organizations found that six out of ten S/4HANA migrations run over budget, and only 8% finish on schedule. ASUG's member survey found a similar pattern from the other direction: 49% of companies already live on S/4HANA reported final costs above their original estimate. For a CFO comparing integrator proposals, the working assumption should be that the number on the page is a starting point, not a ceiling.

Why initial estimates miss so often

The gap rarely comes from a single miscalculation. It comes from how the estimate gets built in the first place. Many proposals are priced before a full technical assessment of the client's SAP landscape occurs.

A sales team runs a lightweight discovery, applies a standard rate card, and submits a number that looks competitive against other bids. The custom code inventory, the interface dependencies, and the data quality issues inside the legacy ECC system stay undiscovered until the SAP Activate methodology moves into the Explore or Realize phase. At that point, the integrator issues a change order, and the client absorbs a cost that a deeper assessment would have surfaced during procurement.

This dynamic explains a pattern CFOs should recognize when comparing bids from different SAP Global Systems Integrators: the lowest number in an RFP often reflects the shallowest discovery, not the most efficient delivery team. A Fixed-Price contract built on a two-week assessment carries a different risk profile than one built on a full technical audit, even when both quote the same total.

The CapEx to OpEx shift adds a second layer of exposure

RISE with SAP moved most enterprise SAP infrastructure from a CapEx model to an OpEx subscription. That shift changes how a CFO should read a migration estimate. Under the old on-premise model, hardware and licensing sat on the balance sheet as a depreciating asset with a known cost. Under RISE with SAP, the client pays a recurring subscription that bundles infrastructure, licensing, and a baseline of managed services.

The recurring structure makes a single migration estimate less informative on its own. A proposal that looks cheaper at the implementation stage can carry a higher recurring OpEx commitment once the subscription terms, consumption tiers, and SLA levels are factored in. Comparing SAP integrator proposals on implementation price alone, without modeling the five-year OpEx trajectory under RISE with SAP, produces an incomplete picture of enterprise ERP migration cost in the US market.

A realistic SAP migration TCO calculation needs to account for the categories that most initial estimates leave out:

• Custom code remediation identified after static analysis tools miss runtime-level issues

• Integration testing cycles beyond the initial test plan, particularly for third-party interfaces

• SAP BTP consumption once extensions and automation move to the Clean Core layer

• Recurring RISE with SAP subscription costs at actual usage volume, not the initial sizing estimate

• Internal FTE backfill during the project, when core finance and operations staff shift into the implementation

The pattern across all five categories is the same. Each one is real, predictable, and absent from a large share of initial bids. A CFO evaluating competing proposals gets more use from asking how each integrator arrived at their number than from comparing the numbers themselves.

Time and Materials or Fixed Price: Which SAP Pricing Model Actually Protects Your Budget?

Neither model protects a budget on its own. A Time and Materials (T&M) contract exposes a client to open-ended hours. A Fixed-Price contract exposes a client to scope disputes once work falls outside what the contract defined. The real variable that determines financial risk sits underneath both models: who does the work, at what rate, and how the estimate maps hours to deliverables.

What each pricing model actually requires of the integrator

A Time and Materials contract bills for hours worked against an agreed rate card. It gives an integrator flexibility to adjust staffing as the project reveals new complexity, and it gives the client visibility into what each hour costs. The risk runs in the opposite direction: nothing caps the total, so cost control depends entirely on how tightly the client manages scope and monitors burn rate against the SAP Activate methodology's phase gates.

A Fixed-Price contract caps the total at a defined scope. That protection holds only as long as the scope document is specific. A Fixed-Price proposal built on a shallow discovery phase leaves wide gaps between what the contract covers and what the project needs; every gap becomes a change order billed outside the fixed number. Fixed price SAP implementation contracts fail CFOs most often at this exact point — not because the pricing model is wrong —  but because the scope behind it was too vague to hold.

Why proposals with similar rate cards can staff the work differently

SAP consulting hourly rates in the US market for functional and S/4HANA consultants generally range from roughly $80 to $175 an hour, with architect-level specialists reaching higher. Offshore delivery resources, commonly based in India or Eastern Europe, bill in a considerably lower range, often 50 to 60% below US-based rates, for comparable phases of work. Both figures are publicly documented and neither is a problem by itself. Correctly staffed, offshore delivery, brings legitimate cost efficiency to a project.

The financial risk appears when the proposal and the delivery team diverge. A common pattern among large multinational integrators involves a senior, US-based partner leading the sales process and the solution architecture conversations, then handing execution to a delivery team weighted toward junior offshore staff once the contract is signed.

The estimate reflects senior-level expertise. The delivered hours reflect a different staffing mix. The mismatch tends to surface as extended timelines, more revision cycles per deliverable, and a higher volume of change orders during the Realize phase, since junior teams need more iterations to reach the same technical outcome a senior team would reach directly.

A specialized integrator running a smaller number of concurrent programs typically staffs closer to the seniority level quoted in the proposal, because the firm's capacity does not depend on rotating junior bench resources across multiple large accounts at once. That staffing consistency shows up in the estimate as milestone-gated billing tied to specific SAP Activate deliverables, rather than a broad hourly allocation that can shift after signature.

What to include in an RFP to understand the staffing structure before signing

A CFO evaluating competing bids can request specifics that a Mega-GSI's standard proposal template often omits:

• Named seniority levels for each phase, not just blended team rates

• The percentage of delivery hours allocated to onshore versus offshore resources, by project phase

• Milestone definitions tied to Activate deliverables (Explore sign-off, Realize testing gates, Deploy readiness), not calendar dates alone

• The change order rate that applies once the fixed scope is exceeded

• A cap or collar on how much staffing composition can shift after contract signature

An RFP evaluation framework built around these five points gives a CFO a comparison that goes past the total price. Two proposals with the same bottom line can commit to very different delivery teams, and the delivery team is what determines whether the number on the contract survives contact with the project.

What Should a Five-Year SAP TCO Estimate Actually Include?

A defensible five-year estimate accounts for five cost categories that many proposals scope loosely or leave out entirely: data quality work, legacy code carried into the new system, the actual length of post-go-live stabilization, internal staff time, and third-party integration testing.

Each one is common enough that a CFO should expect to see it addressed directly in any serious proposal, and vague enough in most RFPs that it rarely gets priced correctly the first time.

Data cleansing and migration scope

Most proposals price data migration on the assumption that the source data is usable as it stands. In practice, master data accumulated over ten or fifteen years on an ECC system carries duplicate customer records, inconsistent material numbers, and outdated vendor entries that never got cleaned up because the old system tolerated them.

Loading that data into S/4HANA does not tolerate it the same way, since the new data model enforces stricter validation on fields the legacy system left loose.

When an estimate assumes clean data and the data is not clean, the cleansing work still has to happen. It just happens mid-project, under time pressure, priced as a change order instead of a planned workstream. A proposal that includes a data quality assessment as a distinct, scoped activity, before committing to a migration timeline, is pricing the project closer to what it will actually cost.

Legacy technical debt and the Clean Core factor

A lift-and-shift approach carries custom ABAP code directly into the new environment, with minimal modification. It gets the project to go-live faster, and it defers the real cost rather than avoiding it. Every custom object carried over has to be retested against every future SAP release, since SAP's cloud update cycle changes underlying tables and APIs on a schedule the client does not control.

A Clean Core strategy moves custom logic out of the core system and into SAP BTP as extensions, keeping the core as close to SAP standard as the business allows. This adds work during the initial implementation, since existing customizations need to be evaluated and rebuilt rather than copied over.

It reduces the retesting burden at every subsequent upgrade, which is where the clean core SAP TCO impact shows up. A proposal that quotes a lower price for lift-and-shift is quoting a lower year-one cost and, in most cases, a higher cumulative cost across the five-year window once upgrade cycles are factored in.

Hypercare and post-go-live support duration

A support period of two to four weeks after go-live covers basic issue triage. It does not cover a full financial close cycle. For a US enterprise running monthly close, quarterly reporting, and SOX-controlled processes, the first month-end close after go-live is typically where asset depreciation, cost center settlement, and currency revaluation processes run for the first time under real transaction volume. Problems in these areas surface during close, not during the first two weeks of daily use.

A proposal that scopes hypercare through at least one full close cycle, rather than a fixed number of calendar weeks, is pricing the stabilization period against how the business actually operates. A proposal that ends support before the first close cycle completes is likely to generate a support renewal or an emergency add-on right when the finance team can least afford the disruption.

Internal FTE backfill

An integrator's estimate prices the integrator's own hours. It rarely prices what the migration costs the client's internal team. Finance and operations staff who participate in workshops, validate test scripts, and review UAT results are not available for their regular responsibilities during that time. On a project running six to twelve months, that internal time commitment is a real cost, whether or not backfill staff gets hired to cover it.

A proposal that states expected internal hours by role and by project phase gives a CFO a number to model against internal ROI calculations. A proposal silent on internal time commitment is not scoping a smaller project. It is deferring that cost to the client's internal budget instead of the vendor's.

Third-party integration and tax engine testing

US enterprises typically run SAP alongside a set of external systems that a migration estimate needs to test explicitly, rather than assume will connect smoothly:

• Banking interfaces for payment processing and reconciliation

• Tax engines such as Vertex or Avalara for transaction-level tax calculation

• EDI connections with logistics providers and major trading partners

• Third-party payroll, treasury, or reporting systems tied to SAP through custom interfaces

Each connection listed as "out of scope" in a proposal becomes a client responsibility, priced separately, discovered late, or absorbed into hidden costs in the SAP implementation that were not part of the original comparison between bids.

A proposal that names each integration and states a testing approach against it, rather than listing them as assumptions, is the more complete estimate even when its total looks higher at first glance.

How Can a CFO's Contract Actually Prevent Budget Overruns?

Three specific contract terms give a CFO more control over an SAP migration than any general terms-and-conditions language. Payment structure, rate protection for post-launch work, and named staffing commitments each address a different failure mode covered earlier in this article, and each is negotiable before signature in ways most procurement teams do not promote.

Milestone-gated payments tied to SAP activate deliverables

A calendar-based payment schedule releases funds on dates, regardless of whether the work behind those dates holds up. A milestone-gated schedule ties payment to verified technical outcomes instead, evaluated against defined acceptance criteria before funds move.

In an SAP context, that means structuring payments around specific gates in the SAP Activate methodology: a successful mock data load with defined error tolerances, a completed integration test cycle with the third-party systems named in the scope, and a formal sign-off on UAT results by named business stakeholders.

The distinction matters, because a calendar milestone can be reached by declaring a phase finished. A technical milestone can only be reached by proving it. A typical structure holds back 10 to 15% of total contract value until after the warranty or hypercare period ends, giving the integrator continued financial incentive to resolve stabilization issues rather than treating go-live as the finish line.

This structure also gives change order management a clearer boundary. Work that falls inside a defined gate belongs to the fixed scope. Work that falls outside it becomes a change order, evaluated against a specific baseline rather than a general sense that the project has grown.

Rate locks for post-go-live support

The initial implementation contract usually gets negotiated hardest, since it carries the largest number. The support and enhancement work that follows go-live often gets priced at whatever rate applies when the need arises, months or years after the original proposal. That gap creates exposure for a CFO who modeled a five-year TCO based on implementation-phase rates and finds enhancement work billed at a different number entirely.

A rate lock clause fixes the hourly rate for defined categories of post-go-live work, commonly for 12 to 24 months following go-live, covering support tickets, minor enhancements, and configuration changes that fall short of a new project. Locking this rate at signature protects the OpEx side of the five-year TCO model the same way the milestone structure protects the CapEx side during implementation.

It also removes a negotiating disadvantage that shows up consistently after go-live, when the client's internal team is dependent on the integrator's institutional knowledge of the specific configuration built for that business.

The key personnel clause

An integrator's proposal is usually shaped by the specific architects and leads present during the discovery and sales process. Nothing in a standard services contract requires those individuals to remain on the project once the contract is signed, and staffing turnover between the sales phase and the delivery phase is one of the more common ways a project's actual execution diverges from what the CFO evaluated during procurement.

A key personnel clause addresses this directly. Standard versions of this clause across US enterprise procurement typically include:

• Named individuals, identified by role, listed as essential to the engagement

• A minimum commitment period for each named individual, tied to specific project phases

• A notice requirement, commonly 30 days, before any named individual can be reassigned or replaced

• The client's right to review and approve a replacement's qualifications before the change takes effect

Adding this clause does not guarantee that architects vetted during discovery will never leave. It gives the client visibility and approval rights when staffing changes occur, rather than discovering the change when a different consultant shows up to a working session already in progress.

How CFOs Can Compare SAP Integrators Before Signing the Contract

Selecting an SAP implementation partner requires more than comparing the total project price. A structured evaluation helps finance teams review how each proposal addresses scope, long-term operating costs, technical decisions, and delivery risks.

The matrix below provides a practical framework for comparing SAP integrators. Each category can be scored from 1-10, based on the level of detail, predictability, and alignment with the organization’s business requirements.

How LeverX approaches SAP migration estimation

At LeverX, SAP migration estimates start with detailed scope validation and financial impact analysis. The focus stays on making assumptions visible before implementation begins.

As an SAP Global Strategic Supplier for Technical Services, LeverX works with enterprise organizations on SAP S/4HANA, RISE with SAP, and SAP BTP initiatives. The estimation process considers factors that affect long-term TCO, including custom code strategy, integration requirements, data migration complexity, and future system maintenance.

The team applies SAP Activate methodology principles and Clean Core architecture practices to align implementation decisions with future operating costs. This approach helps finance and procurement teams compare proposals based on delivery assumptions and expected five-year impact.

If your organization is reviewing SAP S/4HANA or RISE with SAP proposals, LeverX can help validate estimates, review scope assumptions, and assess TCO drivers before contract decisions are finalized. Schedule a peer-level RFP review and TCO validation session with LeverX SAP experts to evaluate your current options.

FAQ