SAP BW 7.5 and BW/4HANA End of Maintenance 2027: Migration Options, Costs and What to Negotiate

What Is Ending and When

SAP BW (Business Warehouse) version 7.5, the last major release of the classic BW architecture on HANA, is approaching the end of its mainstream maintenance lifecycle in 2027. This means SAP will no longer deliver legal change patches, security updates, or standard fixes as part of the included support contract. Customers who remain on BW 7.5 after the deadline face a choice between paying for expensive extended maintenance or operating unsupported software.

This is a distinct situation from the SAP ECC end of maintenance in 2027, though many enterprises face both deadlines simultaneously. SAP BW customers often run BW alongside ECC or S/4HANA, which means the data warehouse migration must be coordinated carefully with the broader ERP transition strategy.

BW/4HANA, SAP's next-generation data warehouse platform, also has its own timeline considerations. While BW/4HANA 2.0 is currently in full mainstream maintenance, SAP has been steering customers towards SAP Datasphere — its cloud-native data fabric platform — as the longer-term strategic direction. This creates a layered decision problem: migrate to BW/4HANA, migrate directly to Datasphere, or find a hybrid path.

Your Three Migration Paths

Enterprise BW customers have three credible migration paths, each with materially different licensing structures, total cost of ownership, and commercial negotiation dynamics. Understanding these before entering any conversation with SAP is essential.

Path 1: In-Place Migration to BW/4HANA

BW/4HANA is SAP's HANA-native data warehouse, architected specifically for in-memory processing. It offers a familiar environment for BW administrators and carries the lowest migration risk of the three options. The in-place migration toolset provided by SAP can convert many BW 7.5 objects directly to BW/4HANA equivalents, though not all — custom ABAP code and non-standard InfoProviders often require manual remediation.

From a licensing perspective, BW/4HANA is sold under the SAP HANA Enterprise Cloud model if taken as a managed service, or as a perpetual licence with maintenance if deployed on-premise. Customers already holding BW 7.5 perpetual licences can typically convert to BW/4HANA licences through a conversion credit, though the conversion rate SAP offers as standard is rarely optimal — this is a direct negotiation point where SAP contract negotiation advisory typically delivers 20–40% improvement on the default offer.

Ongoing HANA infrastructure sizing is a critical cost variable. BW/4HANA requires careful sizing to avoid over-purchasing HANA memory licences, which are sold in blocks and can result in significant shelfware if projected data volumes are inflated. See our guide to SAP HANA licensing for the full detail on memory-based pricing and negotiation levers.

Path 2: Migration to SAP Datasphere

SAP Datasphere (formerly SAP Data Warehouse Cloud) is SAP's cloud-native data fabric platform, intended as the long-term successor to both BW/4HANA and traditional BW. It is priced on a consumption model based on capacity units (storage and compute), which looks attractive in small deployments but can escalate significantly at enterprise scale.

The migration effort from BW 7.5 to Datasphere is materially higher than the BW/4HANA path. BW objects cannot be directly converted — the data models must be redesigned using Datasphere's native constructs. For large, complex BW environments with hundreds of InfoCubes, DSOs, and custom transformations, a Datasphere migration represents a multi-year data warehouse modernisation programme rather than a licence conversion.

The licensing model is also fundamentally different. Datasphere is a subscription service charged on SAP's cloud consumption framework, which means your costs scale with data volume and query load rather than user count or software licences. This can be advantageous if usage is predictable, but requires careful modelling before committing. Independent cost modelling through our SAP licensing cost modelling service is strongly recommended before accepting SAP's standard capacity estimates.

Path 3: Third-Party or Hyperscaler Data Platform

A growing number of enterprises are using the BW 7.5 end-of-maintenance deadline as the trigger for a broader data platform review, considering options such as Snowflake, Databricks, Microsoft Fabric, or Google BigQuery alongside or instead of a BW/4HANA or Datasphere migration. This path carries the highest migration complexity but the greatest commercial flexibility — and it entirely removes ongoing SAP data warehouse licence costs.

This option is particularly compelling for organisations that are already advancing their hyperscaler relationships, as Azure or AWS committed spend can often be leveraged to offset migration costs while generating negotiation pressure on SAP for the remaining ERP estate. The licensing implication to understand carefully is SAP's indirect access rules: if a third-party data platform reads data directly from SAP systems through non-licensed interfaces, SAP indirect access charges may apply to the integration layer.

Licensing Cost Comparison Across Migration Paths

What SAP Won't Tell You About Extended Maintenance

Extended maintenance is the option SAP presents as a temporary bridge — a way to buy time while you plan your migration. In practice, it is a significant and growing cost that SAP uses strategically to create urgency around cloud migration deals.

Under SAP's extended maintenance pricing, customers pay an additional premium on top of their existing maintenance fee. The exact percentage varies by contract, but the range is typically 2–4% of your total licence fee per year on top of the standard 22% annual maintenance charge. For a large BW estate valued at €5 million in software licences, this can add €100,000–€200,000 per year in pure maintenance cost above your baseline.

Extended maintenance also does not provide the same service level as mainstream maintenance. Legal change patches may be available on a case-by-case basis rather than as standard deliverables, and SAP's engineering prioritisation shifts away from extended maintenance releases over time. Organisations in heavily regulated industries — financial services, healthcare, pharmaceuticals — need to understand the compliance implications of running software outside mainstream support. Our financial services SAP licensing guide addresses these regulatory dimensions in detail.

How to Negotiate Your BW Migration Deal

SAP's end-of-maintenance deadlines are negotiating opportunities if you approach them correctly. The following principles should guide your commercial strategy regardless of which migration path you choose.

1. Start the conversation early, before Q3 2026. SAP sales teams operate under quota pressure, and the further you are from a deadline, the more leverage you carry. Customers who approach SAP in crisis mode — inside six months of an end-of-maintenance date — receive materially worse commercial terms than those who engage 18–24 months ahead.
2. Get independent licence conversion valuations before negotiating. SAP's standard conversion credit for BW 7.5 to BW/4HANA rarely reflects the full value of your perpetual licence investment. An independent assessment of your current ELP (Effective Licence Position) will establish a credible baseline for negotiation.
3. Use the competitive landscape as leverage. SAP knows that Snowflake, Databricks, and Microsoft Fabric are credible alternatives to BW/4HANA and Datasphere. A documented proof-of-concept with a competitor platform signals that you have a genuine BATNA (Best Alternative to a Negotiated Agreement) — which changes the tone of the conversation significantly.
4. Separate the migration deal from the maintenance renewal. SAP will often bundle extended maintenance relief into a cloud migration deal in a way that obscures the true cost of each component. Evaluate both elements independently before accepting any bundled offer. Our SAP contract negotiation team regularly unpicks these bundles to expose the real economics.
5. Negotiate future-proofing clauses. Any BW/4HANA or Datasphere agreement signed today should include rights to convert or transfer licences if SAP's product roadmap changes again. SAP has a track record of rebranding and repackaging data products — protect your investment with contractual flexibility provisions.

Technical Migration Considerations

Beyond the commercial strategy, technical migration planning must run in parallel. The key areas to assess for a BW 7.5 migration include custom ABAP code, non-standard InfoProviders, SAP BEx reporting built on top of BW, and any near-real-time replication configurations using SAP Landscape Transformation (SLT) or SAP Data Services.

BW/4HANA introduces strict constraints on modelling approaches — many of the flexible but inefficient InfoProvider types available in BW 7.5 are deprecated or restricted. The BW/4HANA migration cockpit provides automated analysis of object compatibility, but experience shows that the tooling consistently underestimates the remediation effort required for heavily customised environments. Plan for the migration cockpit assessment to be a starting point, not a final estimate.

If your BW environment is tightly coupled to S/4HANA migration licensing — for example, if you are running embedded BW in ECC and planning to migrate to S/4HANA — the data warehouse migration can sometimes be combined with the ERP migration to reduce duplication of effort, but this requires careful sequencing to avoid creating a critical-path dependency that delays the entire programme.

The 12-Month Action Plan

1. Months 1–2: Licence and landscape audit. Establish your current BW 7.5 ELP, identify all HANA infrastructure licences, and document the full BW object inventory. This is the foundation for any commercial negotiation.
2. Months 3–4: Migration path evaluation. Run a structured evaluation of BW/4HANA, Datasphere, and at least one third-party alternative. Involve finance in the TCO modelling — 5-year cost differences between paths can be substantial.
3. Months 5–6: Commercial engagement with SAP. Open discussions with SAP armed with independent analysis. Test conversion credit offers against your independent ELP valuation. Do not sign during this phase — use it to understand SAP's opening position.
4. Months 7–9: Negotiate the migration deal. With competitive leverage established and your preferred path selected, negotiate the complete migration package including conversion credits, extended maintenance waiver, and implementation support terms.
5. Months 10–12: Contract execution and migration programme initiation. Sign only when all commercial terms are agreed. Initiate the technical migration programme with realistic timelines that do not create delivery risk against the 2027 deadline.

Related SAP Licensing Topics

Understanding the BW end-of-maintenance decision requires a broader view of SAP's commercial strategy in 2026–2027. We recommend reading our guides on SAP ECC end of maintenance 2027, SAP Datasphere licensing, and SAP BW/4HANA licensing to build a comprehensive picture of your options and their commercial implications.

If you are simultaneously managing an ECC to S/4HANA migration, review our S/4HANA licensing guide alongside this one to ensure your data warehouse strategy is coordinated with your ERP roadmap. Many enterprises that handle these as separate workstreams end up negotiating against themselves by creating urgency in one area that SAP exploits in the other.