End of Support for SAP BW 7.5: Migrate to SAP Business Data Cloud, BW/4HANA, or Stay?

SAP BW 7.5 end of support is staged, not a cliff. It arrives as a sequence: mainstream maintenance for SAP NetWeaver 7.5, and with it SAP BW 7.5, ends on 31 December 2027, optional extended maintenance runs to 31 December 2030, and SAP BW/4HANA is maintained until at least 2040. For BW architects and CTOs, the SAP BW 7.5 end of support question is therefore not whether to act, but which target architecture to commit to and in what order. 

Three paths exist inside the SAP portfolio:

• SAP Business Data Cloud (SAP BDC): Lift BW to the private cloud edition (PCE), shift InfoProviders into SAP Datasphere as data products, and extend into AI/ML with SAP Databricks. In practice, an SAP BW to SAP Business Data Cloud migration is incremental rather than a big-bang cutover. 
• SAP BW/4HANA: A conversion that keeps the warehouse pattern, retires the classic object model, and secures maintenance to 2040. 
• Stay on SAP BW 7.5 under paid extended maintenance. This buys time, not a strategy.

This guide assumes you already run BW 7.5. It skips the primers and concentrates on sequencing, object-level triage, licensing gates and the trade-offs that decide each path. 

SAP BW 7.5 support end date: what actually ends on 31 December 2027 

The SAP BW 7.5 support end date for mainstream maintenance is 31 December 2027, followed by optional, fee-based extended maintenance to 31 December 2030.

Sources: SAP Community maintenance strategy blog and SAP Learning: Data Product Generator. 

Three details change the planning picture: 

• Extended maintenance is a premium, not a pause. SAP prices it at the same conditions as SAP Business Suite 7, a two-percentage-point premium on the existing maintenance basis. 
• The tier after extended maintenance is customer-specific. It is limited support without guaranteed SLAs or legal updates. For regulated landscapes, that is the real SAP BW 7.5 end of support exposure. 
• BW 7.5 has been in maintenance mode since 2016. SAP states that all feature investment goes exclusively into SAP BW/4HANA, so staying on 7.5 means a frozen feature set, not just a dated one.

Why the decision is harder than the date 

The deadline is a single date; the BW estate behind it is not. Four factors decide how expensive each path becomes, and none of them show up in a maintenance calendar. 

• Database platform. SAP requires an SAP HANA database for BW in SAP Business Data Cloud, and SAP BW/4HANA runs on HANA only. Teams already on SAP BW 7.5 on HANA start ahead. Estates still on anyDB add a database migration (typically SUM with DMO) before any target-state work. 
• Object model debt. In SAP’s transfer toolbox (RSB4HTRF), InfoCubes and MultiProviders convert to ADSOs and CompositeProviders. VirtualProviders and HybridProviders do not convert automatically, and BEx Analyzer and BEx web templates are not carried into BW/4HANA. Every unconverted object is a redesign line item. 
• Logic buried in code. Start, end and expert routines, ABAP in transformations, hardcoded exit variables and CMOD enhancements hold years of business rules that nobody documented. Queries often hold an equally large share. Confirm current Data Product Generator and query-template coverage for your release before scoping any move to SAP BDC. 
• Source system coupling. The SAP BW 7.5 end of support timeline mirrors SAP Business Suite 7, which shares the 2027 and 2030 dates. If ECC feeds your BW through SAPI extractors or ODP, an S/4HANA conversion forces you to re-validate the extraction layer at the same time. 

The practical consequence is that the first deliverable is an inventory, not an architecture diagram. 

Option 1: SAP Business Data Cloud for SAP BW 7.5 customers 

SAP Business Data Cloud (SAP BDC) is where SAP concentrates its data and analytics investment, and where SAP frames the route for BW customers as Lift, Shift, Innovate. An SAP BW to SAP Business Data Cloud migration is therefore not a conversion project. It is staged coexistence: BW keeps running while its data, and later its logic, moves outward into Datasphere and SAP Databricks. 

Lift: move BW 7.5 into the private cloud edition 

Lifting to the private cloud edition (PCE) is a prerequisite for running SAP BW inside SAP BDC. SAP BW 7.5 in PCE is maintained until the end of 2030, and SAP BW/4HANA in PCE until 2040. The technical conditions are an SAP HANA database and SAP NetWeaver 7.5 at SP24 or higher. 

Sequencing is flexible. You can lift first and convert to BW/4HANA later through a shell or remote conversion while NetWeaver BW is still supported. If you want an in-place conversion, convert on-premise first and lift afterwards. Be clear-eyed about the limit: PCE moves the maintenance cliff from 2027 to 2030, it does not remove it. McCoy’s April 2026 analysis calls it a bridge, not a destination. 

Shift: publish BW data as products through SAP Datasphere 

The Data Product Generator (DPG) publishes selected InfoProviders, namely InfoObjects, (a)DSOs and CompositeProviders, into the SAP Datasphere object store as BW-based data products. Those objects are read-only, and creating a data product requires a data provider profile from the Data Sharing Cockpit. DPG is available only for systems already lifted to PCE. 

On the target side, SAP Datasphere carries semantics, access control and governance. SAP’s reference architecture replaces queries and CompositeProviders with analytic models and views there, so expect remodeling effort for the query layer. McCoy estimates that Datasphere already covers 80 to 90 percent of BW functionality. Treat that as a vendor estimate and test it against your own object inventory. SAP BW Bridge can transfer data models but does not migrate queries.

SAP Databricks: AI and ML on shared BW data 

SAP Databricks is the SAP-tailored Databricks service inside SAP BDC for AI, machine learning and pro-code engineering. Data products from the BDC catalog can be shared to it, extended, and pushed back, using Delta Sharing without replicating the data. Unity Catalog provides governance on the Databricks side. 

An SAP BW to SAP Databricks migration therefore rarely means rehosting BW logic in notebooks. It means publishing governed BW data products to the Databricks side and writing model outputs back to Datasphere or SAP Analytics Cloud. Scope any SAP BW to SAP Databricks migration by workload, not by object. The open engineering questions are feature-engineering ownership, lineage across the share, and which workloads justify consumption cost in two engines. 

Shrink and replace, or go greenfield 

Two alternatives avoid carrying legacy BW forward. Shrink and Replace reduces BW to its business-critical core, rebuilds it domain by domain in Datasphere, moves reporting to SAP Analytics Cloud, and decommissions BW once validated (PIKON). A greenfield build on SAP-managed data products avoids a later second move from PCE to Datasphere, but it demands high upfront investment because business logic must be rebuilt in full (McCoy). 

What to confirm before committing to SAP Business Data Cloud 

BDC pricing is consumption-based, with memory usage, HANA size and landscape tiers all contributing (McCoy). Protiviti notes that extracting S/4HANA data into lakehouse storage requires a BDC license. Get entitlement and sizing in writing before the SAP BW to SAP BDC migration plan is signed off.

Option 2: SAP BW migration to SAP BW/4HANA 

SAP BW migration to SAP BW/4HANA suits teams with deep BW investment, stable ETL and no near-term cloud mandate, and it secures maintenance until at least 2040. It keeps the warehouse pattern but removes the classic object model, so the work is conversion and clean-up rather than re-architecture. 

Three conversion routes 

• In-place conversion keeps the SID, requires the BW/4HANA Starter Add-on and runs through the transfer cockpit (RSB4HCONV). 
• Remote conversion builds a new BW/4HANA system under a new SID and transfers metadata and data from the source. 
• Shell conversion is a remote conversion without the data transfer, effectively an accelerated greenfield. 

The transfer toolbox (RSB4HTRF) converts InfoCubes and MultiProviders into ADSOs and CompositeProviders. Run the BW/4HANA pre-check and the simplification-item relevance check (SAP Note 2399707, as referenced in SAP’s migration analysis) before fixing scope. Open hub destinations, CMOD enhancements and unsupported DataSource types surface at this stage, not later. 

Migration duration and benefits 

SAP BW to SAP BW/4HANA migration duration is the variable that most often breaks business cases. Modak as a certified partner for both SAP and Databricks, enables you to see the results in months instead of years. With about 14 months left until the SAP BW 7.5 end of support date, a program started today can overrun mainstream maintenance, so many teams plan extended maintenance as a deliberate bridge rather than a failure. 

The SAP BW to SAP BW/4HANA migration benefits are concrete: two core object types (ADSO and CompositeProvider) across all LSA++ layers, HANA-native performance, SAP’s future BW innovation, and a runway to 2040. 

Where it falls short 

BW/4HANA remains warehouse-centric. Even in private cloud edition it only adds the ability to mirror data to a Datasphere object store, and BEx front-end content still needs redesign. Choose it for continuity and a long runway, not for modernization.

Option 3: staying on SAP BW 7.5 through extended maintenance 

Staying is defensible only as a dated decision. Extended maintenance runs to 31 December 2030 at a two-percentage-point premium, and SAP BW 7.5 in PCE offers the same 2030 horizon with SAP operating the infrastructure. For a “stay” decision, the real SAP BW 7.5 end of support exposure is 2030, not 2027. 

It is rational in three situations: 

• Your source ERP is converting to S/4HANA in the same window, and you would rather re-point extraction once than twice. 
• Triage shows a dormant estate. If a large share of InfoProviders and queries has no consumers, the first year is better spent deleting than migrating. 
• Program capacity is the binding constraint, and a funded start in 2028 is credible. 

Rising operating and maintenance cost and growing dependence on a shrinking pool of BW 7.5 specialists, and the fact that after the final deadlines there are no further security updates increases the risks of staying. 

If you stay, attach conditions. Freeze new development on classic object types, build all new content as ADSOs and CompositeProviders so it stays compatible with the Data Product Generator (zpartner makes the same point for BPC-based planning), and set a written exit date. Without those three, “stay” drifts into default.

Decision framework: match the path to your binding constraint 

Choose the path that answers the constraint you cannot negotiate, whether that is time, budget, cloud policy or AI ambition. 

Three readings of the table matter most: 

• A cloud-first or clean-core mandate points to BDC. Start with the lift if the clock is the problem, and with shrink-and-replace if object debt is the problem. 
• SAP BW to SAP Databricks migration is not a fifth path. It is an extension inside SAP Business Data Cloud, so it requires the PCE lift or a greenfield BDC landing first. 
• Heavy customization plus no cloud strategy favors BW/4HANA. Choose the SAP BW migration to SAP BW/4HANA route when the long runway is worth more than architectural change. 

The first 90 days: triage before target architecture 

A credible SAP BW 7.5 end of support plan starts with evidence from your own system, and the sequence below produces it in roughly one quarter. 

• Measure usage. Use BW runtime and usage statistics to flag InfoProviders, queries and process chains with no consumers. Retire them before they are migrated. 
• Classify what remains. Sort objects into automatic conversion (InfoCubes and MultiProviders via RSB4HTRF), redesign (VirtualProviders, HybridProviders, BEx content) and retire. 
• Establish technical baseline. Record the database (HANA or anyDB), the NetWeaver 7.5 support package level against the SP24 minimum for PCE, and results of the BW/4HANA pre-check. 
• Map code-resident logic. List routines, exit variables and CMOD enhancements, ranked by business criticality and by owner. 
• Pilot one domain end to end. For an SAP BW to SAP BDC migration pilot, lift a sandbox, publish one ADSO-based domain through the Data Product Generator and rebuild one query as an analytic model. For the BW/4HANA route, convert a sandbox copy. Measure effort instead of estimating it. 
• Qualify the Databricks case. Add an SAP BW to SAP Databricks migration workstream only when a named ML or advanced-analytics workload needs it. 
• Price both clocks. Compare an SAP BW to SAP Business Data Cloud migration against the extended-maintenance premium and a BW/4HANA conversion, then lock the target with dated gates.

Conclusion: treat 2027 as a constraint, then decide on evidence 

Whichever target you choose, the first moves are the same: inventory, classify, pilot. An SAP BW to SAP Business Data Cloud migration rewards teams that arrive with a clean, documented object estate, and so does a conversion to BW/4HANA. The test for any SAP BW to SAP BDC migration is whether a pilot domain, published through the Data Product Generator and rebuilt as analytic models, behaves like production. 

With about 14 months of mainstream maintenance left, teams that finish triage in early 2027 can choose among all three paths on evidence. Teams that start later tend to choose by default, and default usually means paying the extended-maintenance premium without a plan. 

Frequently asked questions 

What happens at SAP BW 7.5 end of support if we do nothing? 

Mainstream maintenance for SAP NetWeaver 7.5, including BW 7.5, ends on 31 December 2027. Optional extended maintenance runs to 31 December 2030 at a two-percentage-point premium. Without it, customers fall back to customer-specific maintenance and no security update to follow. 

Can we move to SAP Business Data Cloud without converting to BW/4HANA first? 

Yes. Lift BW 7.5 to the private cloud edition, which requires an SAP HANA database and NetWeaver 7.5 at SP24 or higher, and convert later through a shell or remote conversion while NetWeaver BW is supported. If you prefer an in-place conversion, convert on-premise first and lift afterwards. Either way, an SAP BW to SAP BDC migration starts with the lift. 

What does an SAP BW to SAP Databricks migration actually involve? 

It is mainly a data-sharing and governance exercise, not a replatforming. BW data products published through the Data Product Generator are shared onward using Delta Sharing, extended with ML under Unity Catalog governance, and written back to Datasphere or SAP Analytics Cloud. BW logic stays in BW or is rebuilt in Datasphere. 

How long does an SAP BW migration to SAP BW/4HANA take? 

Modak as a certified partner for both SAP and Databricks migrations scope at 12 to 24 months or longer based on the scale. The spread is driven by object debt: VirtualProviders and HybridProviders that cannot convert automatically, BEx content, and code-resident logic. 

Should we choose SAP Datasphere or SAP BDC? 

It is not either-or. BDC builds on Datasphere, which remains its modeling and governance core, and SAP states that Datasphere will continue to be developed. Datasphere also remains available on its own, which suits a narrow data-layer need. BDC adds SAP Databricks, SAP Analytics Cloud, BW in private cloud edition and managed data products.