Shell conversion creates a new BW/4HANA system with only structural metadata — fastest (3–5 months for clean landscapes), but historical data must be reloaded or is not migrated. Best when historical data is either not needed or can be sourced from the original system post-migration. In-place conversion transforms the existing BW system directly to BW/4HANA — all data, objects and processes migrate in-place but requires thorough preparation and has the highest complexity (6–12 months). Best when data continuity is critical and downtime windows allow. Remote conversion sets up a new BW/4HANA system and migrates objects via remote connection — enables parallel operation during transition (6–10 months). Best when risk tolerance is lower and a fallback to the old system is needed during migration. Our readiness assessment inventories your landscape and recommends the approach based on actual object counts, data volumes, custom code dependencies and your available downtime — not on a default preference.

Greenfield implementation: 3–6 months depending on scope (number of source systems, data model complexity, number of SAC reports). Shell conversion migration: 3–5 months for landscapes under 500 active objects with minimal custom code. In-place or remote conversion: 6–12 months for larger landscapes (1,000+ objects, significant custom code, multiple source connections). All timelines include assessment (3–4 weeks), which we always recommend as the starting point — it produces a much more accurate estimate than blind scoping because it inventories the actual migration work involved. The most common cause of BW/4HANA project overruns is underestimating custom code remediation — our assessment specifically counts and classifies custom ABAP objects to prevent this.

Yes — and having one partner deliver both is a significant advantage. S/4HANA is the primary data source for BW/4HANA; the extraction design, delta configuration, master data alignment and key figure definitions must be coordinated between the two systems. When the S/4HANA functional team and the BW/4HANA BI team are from the same partner, this coordination is native — data structures are agreed upfront, extractors are configured once correctly and integration testing discovers fewer surprises. When two separate partners manage S/4HANA and BW/4HANA, the most common failure point is misalignment between how S/4HANA was configured and what BW/4HANA expects to extract.

BEx queries still work on BW/4HANA and can be consumed by Analysis for Office and other BEx-compatible tools. However, SAP's strategic direction is SAP Analytics Cloud — BEx Query Designer receives no new features. The pragmatic approach: migrate critical and high-use queries to SAC during or shortly after the BW/4HANA migration; leave lower-priority queries in BEx temporarily and retire or migrate them over 12–18 months post go-live. A full BEx-to-SAC migration is a separate workstream often phased after the BW/4HANA migration itself. Our readiness assessment includes a BEx query inventory and usage analysis — classifying each query as migrate, retire or retain — so the effort is known before the project starts.

SAP BW 7.x (including BW on HANA) receives mainstream maintenance until 2027, with extended maintenance available until 2030 under additional fees. BW/4HANA is SAP's strategic data warehousing platform with planned long-term support. The practical implication: organisations on legacy BW should plan migration within the 2025–2028 window. Starting the readiness assessment now gives adequate time to complete a well-planned migration without the deadline pressure that causes projects to cut corners. Maintenance dates also provide negotiating leverage with SAP on licensing during the transition period — something our Gold Partner status gives us visibility into. We recommend treating 2027 as the planning deadline, not the migration deadline — your readiness assessment should be complete well before mainstream maintenance ends.