Now accepting guest editorial from SAP, Oracle, Workday and ServiceNow practitioners.Pitch a guide
The Sign-Off Table

Lesson 6 of 6

Coexistence and decommissioning

9 min

Listen to this lesson

0:00 / 6:21

No BW modernization happens in one weekend. For a period, often years, BW and its successors run side by side: BW in the private cloud edition, BW data products in Datasphere, new models built on SAP-managed data products, and SAC stories reading from all of them. Coexistence must be managed so users always know which number is official, and decommissioning must be planned so BW is switched off safely before 2030.

Rules for coexistence

  • One official source per KPI at any time. The use case register says whether "margin by customer" is official in BW or in Datasphere, and since when.
  • Parallel run before switch. The new model runs alongside BW for at least one full period close, reconciled every period.
  • Label everything. Stories and workbooks show which source they use and whether it is official.
  • Freeze changes on the old side. Once a use case is rebuilt, changes go into the new model only; BW changes need an exception.
  • Keep loads healthy. BW extractions from CMP continue until the last dependent use case switches.
Each use case moves through these states independently; BW is switched off only when every use case has reached Archived.
The Sign-Off Table · thesignofftable.com/academy/sap-dap-302

History and decommissioning

The hardest decommissioning question is history. Finance may need seven years of margin history; auditors may need specific periods; BW may hold the only copy of data from the ECC years before the conversion. Options include moving history into Datasphere (for example as BW data products or into the object store, which SAP describes as a store for large volumes rather than a cold-storage replacement), keeping a read-only BW until a cut-off date, or archiving with your retention tooling. Each needs a reconciliation of the moved history and a legal check of retention rules.

StepOwnerEvidence
All use cases switched or retiredNoorUse case register with sign-offs
History moved and reconciledNoor, PriyaCounts and totals per year and company code
Retention and legal holds checkedDan, legalRetention decision per data class
Extractions from CMP stoppedTheo, SamDelta queues and jobs removed; source clean
Users, roles and connections removedNadia, SamRole and connection removal log
BW switched off and contract endedGrace, SamDecommission record and contract notice

Contoso's BW decommissioning checklist.

  1. 2026 to 2027Shrink and liftRetire unused content; lift BWP to BW private cloud edition
  2. 2027 to 2028Expose and rebuild critical use casesBW data products; margin and sales rebuilt with parallel runs
  3. 2028 to 2029Rebuild the restRemaining use cases switched; BW read-only for history
  4. 2029 to 2030DecommissionHistory moved and reconciled; extractions stopped; BW off before support ends
An illustrative Contoso timeline that ends before BW 7.5 private cloud support ends in 2030.
The Sign-Off Table · thesignofftable.com/academy/sap-dap-302
During coexistence the register, not the tool, decides which number is official.
The Sign-Off Table · thesignofftable.com/academy/sap-dap-302

Coexistence is also a communication problem. Users need to know, for each report they use, where it lives now, when it moves, what changes in how they open it, and who to ask. Contoso publishes the use case register as a simple list in its intranet, sends a note to users two weeks before each switch, keeps the old BW workbook available read-only for one period after the switch, and adds a banner to it pointing to the new story. Training focuses on the differences users will notice, such as navigation and filter behavior, not on the tool in general.

What would you do?

The new Datasphere margin model has run in parallel with BW for one period close and reconciled exactly. The CFO wants to switch off BW next month. What should Noor answer?

Finally, decide what to keep from BW after it is gone. Contoso exports query and InfoProvider definitions, transformation code and the last regression baselines as documentation, because questions about historical figures (“how was 2025 margin calculated?”) continue for years. That archive is small, cheap and often the only answer an auditor or a new controller can get once the system is switched off.

Key points
  • Keep one official source per KPI; label sources; freeze changes on the old side.
  • Switch use cases one by one after a reconciled parallel run of at least one period close.
  • Plan history explicitly: move and reconcile, keep read-only, or archive under retention rules.
  • Decommission with a checklist: consumers, history, retention, extractions, roles, contract.

Check your understanding · not graded

Lesson check

  1. 1. What should happen before a rebuilt use case becomes official?

  2. 2. Why must delta queues in SAP S/4HANA be cleaned up after BW stops loading?

  3. 3. Which statement about the Datasphere object store does SAP make?

  4. 4. When can BW be switched off?