BW to BW/4HANA Migration: The Complete Guide

BW Migration Is Not Optional — And It Is Not Simple

SAP BW 7.5 hits the end of mainstream maintenance on the same timeline as ECC — 2027. If you are running a classic BW system today, the clock is ticking just as loudly as it is for your ERP. And in many organizations, the BW migration is actually the harder project.

That statement surprises people. S/4HANA migration gets all the executive attention, all the conference keynotes, all the analyst reports. BW migration is treated as a footnote — something the BI team will handle on the side. This is a mistake.

Here is why BW migration is often more complex than S/4HANA migration:

• Data volume complexity. A typical BW system holds years — sometimes decades — of historical data. We regularly see BW systems with 50-100 TB of data. The S/4HANA system feeding that BW might be 5-10 TB. Migrating 10x the data takes more than 10x the effort because of transformation, validation, and cutover window constraints.
• Reporting dependencies are invisible. Every BW query has consumers. Some are obvious — SAP Analytics Cloud dashboards, BEx reports in the portal. Others are hidden — Excel workbooks with live BW connections, third-party BI tools pulling from InfoProviders, ABAP programs reading from BW cubes. You cannot see these dependencies from inside the BW system. They only surface when something breaks.
• The modeling paradigm shifted fundamentally. BW/4HANA does not just upgrade your existing data warehouse. It replaces the modeling paradigm. InfoCubes are gone. MultiProviders are gone. The entire RSA1 transaction — the tool every BW developer has used for two decades — is gone. This is not an upgrade. It is a redesign of how you think about data modeling in SAP.

Organizations that treat BW migration as a simple technical upgrade end up in trouble. The ones that treat it as a data warehouse modernization project — with proper planning, object rationalization, and stakeholder involvement — come out with a system that is genuinely better than what they had before.

This guide covers everything you need to know to get it right.

BW vs. BW/4HANA: What Actually Changed

BW/4HANA is not BW 8.0. SAP did not increment the version number and add features. They rebuilt the data warehouse platform on HANA-native principles and removed everything that was redundant, legacy, or incompatible with in-memory computing. The changes are deep.

The Modeling Tools

RSA1 is gone. The transaction that every BW developer has used since BW 3.x no longer exists for modeling purposes in BW/4HANA. All data modeling, transformation design, and process chain management happens in Eclipse with the BW Modeling Tools plugin. This is not a cosmetic change. Eclipse is a fundamentally different development environment — project-based, with version control integration, a different navigation model, and a different mental model for how you build and deploy objects.

The BW/4HANA Cockpit replaces the traditional BW administration tools. It is a Fiori-based web interface for monitoring data loads, managing process chains, and handling administrative tasks. For administrators who lived in RSA1, this is a significant adjustment.

Simplified Object Types

This is the most consequential change. BW/4HANA reduces the object zoo to four core types:

• Advanced DSO (ADSO) — The universal data storage object. Replaces InfoCubes, classic DSOs, and write-optimized DSOs. One object type with configurable semantics (staging, reporting, or both).
• Composite Provider — The universal virtual federation layer. Replaces MultiProviders and InfoSets. Combines data from multiple ADSOs, Open ODS Views, or external sources without physical data movement.
• Open ODS View — Virtual access to external data sources. Replaces VirtualProviders. Points to HANA tables, CDS views, or remote sources without importing data into BW.
• HANA Calculation Views — Native HANA analytical views that can be integrated into the BW metadata layer.

Everything else is gone:

HANA-Native Performance

BW/4HANA pushes computation down to the HANA database layer wherever possible. In classic BW, the ABAP application server did a significant amount of data processing — aggregations, joins, filtering. In BW/4HANA, these operations execute in the HANA engine directly. The result is dramatic performance improvement for queries and data loads, especially on large datasets.

Data Tiering

BW/4HANA introduces hot, warm, and cold storage tiers using HANA Native Storage Extensions (NSE):

• Hot storage — Data in HANA in-memory columnstore. Fastest access. Highest cost per GB.
• Warm storage — Data managed by HANA but loaded into memory on demand using NSE. Slower first access, but significantly lower memory footprint. Ideal for infrequently accessed historical data.
• Cold storage — Data in near-line storage (NLS) or data lake. Cheapest. Slowest access. For archive and compliance.

This tiering is a game-changer for organizations struggling with HANA memory costs. You can keep ten years of history accessible without paying for ten years of in-memory storage.

The Three Migration Paths

Every BW-to-BW/4HANA migration follows one of three approaches. The right choice depends on your data volume, system complexity, desired end state, and timeline. There is no universally correct answer — only the answer that fits your situation.

In-Place Conversion

An in-place conversion transforms your existing BW system into BW/4HANA. You keep the same system ID, the same database, and the same data. SAP provides conversion tooling that automatically converts compatible objects and flags incompatible ones for manual remediation.

How it works:

1. Run the BW/4HANA Conversion Pre-Check to identify objects that cannot convert automatically
2. Remediate flagged objects — convert them to BW/4HANA-compatible types or remove them
3. Execute the technical conversion (system upgrade, database migration if not already on HANA)
4. Validate converted objects and run regression testing on all critical reports

Best for: Organizations that want the fastest path with minimal disruption, have a relatively clean BW system, and want to preserve all historical data.

Watch out for: Unconverted objects block the conversion. If you have hundreds of legacy objects that cannot convert automatically, the remediation phase alone can take months. We have seen organizations where the pre-check revealed 2,000+ objects requiring manual intervention. That is not a conversion — that is a rewrite hiding inside a conversion timeline.

Remote Conversion (Shell Conversion)

A remote conversion stands up a new BW/4HANA system and transfers object definitions — the "shell" — from the old BW system. Structure without data. You then selectively reload data from the source systems or from the old BW.

How it works:

1. Install a fresh BW/4HANA system
2. Use the Transfer Cockpit to copy object definitions from the source BW
3. Objects are automatically converted to BW/4HANA types during transfer
4. Selectively reload data — only the objects and history you actually need
5. Rebuild or redirect reporting on top of the new system

Best for: Organizations that want to clean up their BW landscape. If your current BW has accumulated years of unused objects, duplicate data flows, and orphaned queries, a shell conversion lets you bring only what matters. It is also a good choice when you want to reduce data volume significantly.

Watch out for: This approach requires reloading data, which means longer cutover windows and dependency on source system availability. If your ECC system is also being migrated, coordinating the data reload becomes complex.

New Implementation (Greenfield)

A greenfield implementation builds BW/4HANA from scratch. No object transfer. No conversion tooling. You redesign the entire data warehouse based on current business requirements.

Best for: Organizations that want to fundamentally rethink their data warehouse architecture. If your current BW was built fifteen years ago and has been patched, extended, and worked around ever since, a greenfield gives you the cleanest result. It is also the right choice if you are shifting a significant portion of your analytics to SAP Datasphere and only need BW/4HANA for a subset of SAP-centric reporting.

Watch out for: This is the highest-effort, longest-timeline approach. Every data flow, every transformation, every query must be designed, built, tested, and validated from scratch. Budget 12-18 months minimum for a mid-size landscape. Organizations often underestimate the institutional knowledge embedded in the existing BW — the business rules encoded in transformations, the quirks of specific extractors, the workarounds for source system data quality issues.

Choosing Your Path

Object Conversion: The Heavy Lift

Regardless of which migration path you choose, object conversion is where the real work happens. SAP's conversion tooling handles the straightforward cases automatically. The rest requires manual intervention, redesign, and testing.

Here is what the conversion landscape looks like:

The 60/40 rule. In our experience, automatic conversion handles 60-70% of objects cleanly. The remaining 30-40% require manual intervention — ranging from minor adjustments (fixing a field mapping after InfoCube-to-ADSO conversion) to complete redesigns (rewriting an APD process as a HANA stored procedure or BW transformation).

That 30-40% is where projects go off the rails. Each object that needs manual work must be analyzed, redesigned, built, and tested. Multiply that by hundreds of objects and you have a work effort that rivals the core conversion itself.

The practical approach:

1. Inventory everything. Run the BW/4HANA Conversion Pre-Check and export the full object list with conversion status.
2. Classify by business criticality. Not every object needs to survive the migration. Many BW systems have 40-60% unused or rarely used objects. Kill them.
3. Convert automatically first. Let the tooling handle the easy 60-70%. Validate the results.
4. Prioritize manual conversions by reporting impact. The objects feeding your most critical reports get converted first. The object feeding a report that three people ran twice last year gets deprioritized or dropped.

Data Volume and History Decisions

How much historical data to bring to BW/4HANA is one of the highest-impact decisions in the entire migration. It affects your timeline, your HANA sizing (and therefore your infrastructure cost), your cutover window, and your go-live risk.

You have three options:

Full migration — Bring everything. Every row of every fact table, every year of history. This preserves complete analytical continuity but is expensive. A 60 TB BW system requires a 60 TB HANA instance (or a well-designed tiering strategy). Data migration alone can take days or weeks depending on network bandwidth and system performance.

Selective migration — Bring the last N years. Keep 3-5 years of detailed data in BW/4HANA. Older data is either archived or left in the legacy system (kept running in read-only mode for historical queries). This dramatically reduces HANA sizing and migration time.

Archive and migrate — Before migration, aggressively archive historical data to near-line storage (NLS) or a data lake. Then migrate only the recent, actively-queried data to BW/4HANA. Post-migration, connect the archived data via BW/4HANA's cold storage tier for on-demand access.

Our recommendation: archive aggressively before migration. In almost every engagement, we find that 70-80% of BW data volume is historical data that is queried rarely or never. Migrating it burns time and money for no analytical value. Archive it, validate that archived data is accessible, and then migrate the lean dataset.

The decision factors:

• Regulatory retention requirements. Some industries require 7-10 years of detailed transactional data. This does not mean it must be in hot storage — it means it must be queryable. Warm or cold tiers satisfy most regulatory requirements.
• Reporting needs. Talk to your business users. How far back do they actually query? In most organizations, 90% of queries touch data from the last 24 months.
• Cutover window constraints. If your business can only tolerate a 48-hour cutover, you cannot migrate 50 TB of data in that window. Reducing data volume directly reduces cutover risk.

BW/4HANA vs. SAP Datasphere: Do You Need Both?

This is the question every BW team is asking right now, and SAP's messaging has not made it easier. BW/4HANA and Datasphere are both SAP data warehouse products. They overlap in capabilities. But they serve different purposes, and for most organizations, the answer is not either/or.

When BW/4HANA Is the Right Choice

• Complex ETL and transformation logic. BW/4HANA has two decades of transformation capabilities — start routines, end routines, expert routines, field-level mappings, error handling. Datasphere's data flow capabilities are improving but do not match this depth yet.
• SAP-centric reporting with deep SAP semantics. BW/4HANA understands SAP metadata natively — currencies, units, hierarchies, authorization objects. If your reporting is primarily SAP-on-SAP, BW/4HANA preserves these semantics end-to-end.
• Mature BW teams. If your organization has a team of experienced BW developers, BW/4HANA lets them leverage their existing skills (with the Eclipse transition). A greenfield Datasphere implementation requires different skills.

When Datasphere Is the Right Choice

• Cross-platform analytics. Datasphere connects SAP and non-SAP sources natively. If your analytics strategy requires combining SAP ERP data with Salesforce, Snowflake, or cloud data lakes, Datasphere is purpose-built for this.
• Data sharing and collaboration. Datasphere's data marketplace and space-based access control make it easier to share curated datasets across business units without building dedicated data flows.
• AI and ML data foundation. If your organization is building an AI and ML strategy on SAP data, Datasphere provides better integration with SAP AI Core and third-party ML platforms.
• New to SAP data warehousing. Organizations without existing BW investment should start with Datasphere rather than adopting BW/4HANA's more complex paradigm.

The Emerging Pattern: Run Both

The architecture we see gaining traction in the market:

• BW/4HANA as the SAP data hub — handling complex SAP-to-SAP ETL, deep SAP semantic reporting, and process-integrated analytics (embedded BW queries in S/4HANA Fiori apps)
• Datasphere as the enterprise data fabric — federating SAP and non-SAP data, providing self-service analytics, and serving as the data foundation for AI/ML workloads

This is exactly the architecture SAP describes with the SAP Business Data Cloud. BW/4HANA feeds curated SAP data into Datasphere, which combines it with non-SAP data and exposes it to analytics and AI consumers.

If you are migrating BW today, plan for this hybrid architecture. Even if you start with BW/4HANA only, design your data models with future Datasphere integration in mind.

Common BW Migration Mistakes

We have been involved in enough BW migrations to see the same failure patterns repeat. Here are the mistakes that cause the most damage.

1. Not inventorying all query consumers. BW queries are consumed by more tools than most teams realize — BEx Analyzer workbooks, SAP Analytics Cloud stories, Analysis for Office templates, Crystal Reports, third-party BI tools (Tableau, Power BI), ABAP programs using the BICS interface, and even custom applications using MDX or REST APIs. If you do not inventory every consumer before migration, you will discover them in production when they break.

2. Ignoring custom ABAP in BW. Classic BW systems accumulate significant custom ABAP code — transformation routines, start/end routines, customer exits, APD processes, custom function modules called from process chains. This code must be reviewed, and potentially rewritten, for BW/4HANA compatibility. Some ABAP patterns that worked in classic BW are deprecated or removed. The conversion pre-check flags some of these, but not all.

3. Underestimating the Eclipse learning curve. BW developers who have spent 10-15 years in RSA1 do not become productive in Eclipse overnight. Budget 4-6 weeks of hands-on training and practice before expecting full productivity. We have seen projects where the migration timeline slipped by months simply because the team could not work fast enough in the new tools.

4. Not involving reporting users in UAT. Technical conversion validation is not enough. A query that converts successfully and returns data is not necessarily correct. Subtle differences in aggregation behavior, filter handling, or authorization processing can produce different numbers. Your business users must validate that the reports they rely on produce the same results they expect. Plan for at least 2-3 UAT cycles.

5. Migrating everything. The single most common mistake. Teams attempt to convert every object in the BW system — including objects that have not been used in years, queries that no one remembers building, and data flows that feed reports no one reads. Every unnecessary object adds to the conversion effort, the testing scope, and the go-live risk. Run a usage analysis first. Identify objects with zero query executions in the last 12 months and challenge their existence.

6. Skipping the authorization model review. BW authorizations in BW/4HANA work differently than in classic BW. Analysis authorizations have changed, and the interaction between BW authorizations and HANA analytic privileges requires careful design. Organizations that skip this review end up with users who either cannot access data they need or can access data they should not see.

7. Not planning for CDS-based extraction. If you are migrating to S/4HANA (or have already migrated), classic BW extractors are replaced by CDS-based extraction. This is not a BW/4HANA change — it is an S/4HANA change that directly impacts BW. Your BW migration plan must account for rebuilding extraction logic on CDS views. Ignoring this creates a second migration project after the first one finishes.

Coordinating BW and S/4HANA Migrations

Most organizations migrating BW are also migrating to S/4HANA. These two projects are deeply interconnected, and the sequencing decision has significant implications for both.

Option A: S/4HANA First, Then BW (Most Common)

This is the sequence most organizations follow. Migrate the ERP to S/4HANA, stabilize it, then tackle BW.

Advantages: S/4HANA migration gets full organizational attention. BW continues to operate on the existing ECC extractors during the ERP transition. The BW team can observe the new S/4HANA system and plan their migration with full knowledge of the new data model.

Disadvantages: After S/4HANA goes live, BW extractors need to be updated to CDS-based extraction. This is a significant effort that effectively becomes a mini-project between the two migrations. During this interim period, you are running a BW/4HANA-incompatible BW system on top of a new S/4HANA system with rebuilt extractors — a fragile combination.

Option B: BW First, Then S/4HANA (Less Common)

Migrate BW to BW/4HANA first while the source system is still ECC.

Advantages: The BW migration is isolated from ERP changes. Classic extractors remain stable during the BW conversion. The BW team can focus entirely on the data warehouse modernization without worrying about simultaneous source system changes.

Disadvantages: After S/4HANA migration, you will need to rebuild extractors on CDS views anyway. You are doing the extractor work regardless of sequence — the question is just when. This approach also delays the S/4HANA project, which usually has more executive urgency.

Option C: Parallel Migration (Ambitious)

Run both migrations simultaneously with coordinated program management.

Advantages: Shortest total calendar time. One coordinated effort instead of two sequential ones. Extractor migration happens once, during the combined project.

Disadvantages: Extremely high program management complexity. Both teams compete for the same resources — the same functional consultants, the same test users, the same infrastructure. If either project slips, it impacts the other. We only recommend this approach for organizations with strong program management and experience running large parallel SAP programs.

The Key Technical Dependency: CDS-Based Extraction

Regardless of sequencing, there is one technical fact that drives all planning: S/4HANA replaces classic BW extractors with CDS-based extraction.

In ECC, BW extractors are ABAP programs (RSA7, LIS, FI-CA extractors) that push data to BW using the Service API. In S/4HANA, these are replaced by CDS views with extraction annotations that BW reads using operational data provisioning (ODP).

This means:

• Every extractor in your current BW must be mapped to an equivalent CDS view in S/4HANA
• Some classic extractors have direct CDS equivalents. Others do not — requiring custom CDS views or redesigned data flows
• The data model differences between ECC and S/4HANA (e.g., the universal journal in finance) mean some extractors are not just replaced but fundamentally redesigned

Plan for this. Whether you migrate BW first, S/4HANA first, or both together, the extractor rebuild is unavoidable and is often the most underestimated work package in the entire program.

Where to Start

BW migration is a significant undertaking, but it follows a predictable path when planned correctly. The organizations that succeed share three traits: they plan early, they rationalize aggressively (killing unused objects before migrating them), and they treat the migration as a data warehouse modernization — not just a technical upgrade.

If you are beginning to plan your BW/4HANA migration, start with these steps:

1. Run the BW/4HANA Conversion Pre-Check to understand the scope of object conversion
2. Analyze query usage to identify objects that can be retired instead of migrated
3. Decide your migration path (in-place, remote, or greenfield) based on your system state and business goals
4. Map the S/4HANA dependency — understand your extractor landscape and CDS migration requirements
5. Evaluate the BW/4HANA + Datasphere architecture to determine if you need both

We run BW/4HANA migration assessments that cover all five of these areas. If your BW system is complex, or if you are coordinating BW and S/4HANA migrations simultaneously, an independent assessment before you commit to a path can save months of rework.

For organizations already running on HANA but struggling with performance, our SAP HANA optimization services can help you get the foundation right before you migrate.

The 2027 deadline is not moving. The BW migration is not going to get simpler by waiting. Start planning now.