Shell conversion creates a brand-new BW/4HANA system and migrates only the structural metadata — InfoObjects, ADSO definitions (converted from DSOs/InfoCubes), query definitions and process chains — without historical data. Data must be reloaded from source systems or is not required in the new landscape. Fastest approach (3–5 months for clean landscapes) and provides the cleanest result because you start with a fresh system. In-place conversion transforms the existing BW system directly to BW/4HANA — the same system ID, same data, same everything — by converting objects in-place. All historical data is preserved but the preparation phase is extensive: every object must be assessed, remediated and converted. Higher complexity (6–12 months), higher risk, but full data continuity. The choice depends on: do you need historical data in BW/4HANA, or can it be sourced from the original system or archived?

It depends heavily on the approach. Shell conversion: minimal downtime because you build a new system alongside the old one and cut over when ready — the old BW remains operational until cutover weekend. Remote conversion: similar to shell — the new BW/4HANA system is built in parallel and the old system remains available during migration. Downtime is only for the final cutover (typically a weekend). In-place conversion: this is where downtime matters most — the existing system is being transformed. The actual conversion execution may require 24–72 hours of system downtime depending on data volume and object count, preceded by a preparation phase that can run while the system is operational. The downtime requirement is one of the key factors in approach selection — if your business cannot accept a multi-day BW outage, in-place conversion may not be viable regardless of its data continuity advantages.

For organisations with complex, customised BW landscapes — heavy custom ABAP, complex process chains, extensive BEx query libraries — BW/4HANA is typically the pragmatic first step. The migration path is well-understood, SAP tooling is mature and the BW skill set within your organisation transfers directly. BDC is strategically correct but requires a different skill set (Datasphere, data products, Databricks) and a different architectural approach (virtualisation vs ETL). Both paths extend BW maintenance to 2030. Our readiness assessment evaluates your landscape against both options and recommends the path that balances risk, timeline and strategic positioning. For many organisations, the answer is: BW/4HANA now with BDC-forward architecture — migrate to a stable, supported platform today, and transition to BDC when the organisation and the product are ready.

Yes — BEx queries migrate to BW/4HANA and continue to work with Analysis for Office and other BEx-compatible tools. They are not broken by the migration itself. However, SAP's strategic direction is SAP Analytics Cloud; BEx Query Designer receives no new features. The pragmatic approach: migrate all BEx queries as part of the BW/4HANA conversion (they come across automatically), then phase the SAC migration separately — starting with the most-used queries and working down the priority list over 12–18 months post go-live. Our readiness assessment includes a BEx usage analysis that identifies which queries are actively used, which are dormant and which are duplicates — so the SAC migration scope is realistic from the start.

Yes — and we strongly recommend it. For in-place and remote conversion, SAP's migration tools support a simulation mode that identifies conversion issues without actually modifying your system. Our standard approach runs at least one full dry run on a copy of your BW system before the production conversion. This dry run surfaces object conversion failures, custom code issues and data consistency problems in a controlled environment where they can be remediated without time pressure. For shell conversion, the entire approach is inherently low-risk because the original system remains untouched — the new BW/4HANA system is built alongside and validated before cutover. We treat the dry run as a mandatory phase, not an optional add-on — it is where 80% of migration issues are found and fixed.