Retiring SAP satellite applications post-S/4HANA: BW, CRM, SRM, GTS

The post-cutover landscape diagram is on the wall. The team has been celebrating S/4HANA for two quarters. Someone draws a circle around the boxes that nobody has talked about: BW. CRM. SRM. GTS. PI. Solution Manager.

Six SAP satellite systems, all still running, all still licensed, all still carrying their own basis and infrastructure footprint. None of them was scoped into the migration. Most of them were the responsibility of a different team. All of them still have to be paid for, every quarter.

Someone adds up the run-rate. It is comparable to ECC.

This is the second cost shock of the S/4HANA program — the one that hits after the primary cutover. The satellites are 40–60% of the SAP run-rate for most enterprises, and most are not strategic to a modernized estate. Retiring them is the structural follow-on to retiring ECC.

Step One — The Wrong Assumption

We'll deal with the satellites later.

"ECC was the focus. We'll get to BW and CRM in a future phase."

— Standard mid-migration position

The assumption assumes that satellite systems are operationally separable from ECC and can be modernized on an independent schedule. They cannot, in two ways. First, most of them depend on ECC data flows that will not exist in the new architecture; their continued operation requires custom integration that nobody is staffed to build. Second, the satellites usually carry the same retention obligations as ECC, which means they have the same retirement question to answer. "Later" turns into a multi-year parallel-run of systems that nobody is using strategically.

Step Two — The Partial Signal

The PI bus stops carrying ECC traffic, and the satellites start failing quietly.

The partial signal is integration failure. SAP Process Integration (PI/PO) was the bus that fed most of the satellites their ECC data. After cutover, the bus is reconfigured for S/4 or replaced entirely. The satellites that depended on the old flow start failing — sometimes loudly (BW reporting cubes that no longer refresh), sometimes quietly (CRM customer hierarchies that drift out of sync over weeks).

The pattern of failure makes the retirement question obvious in retrospect. The satellites were not load-bearing in the new architecture; they were load-bearing in the old one. Continuing to operate them after the old architecture is gone is paying production cost for a degrading workload.

Step Three — The Failed Fix

Custom integration to keep the satellites fed.

The failed fix is the integration patch: write S/4-to-BW connectors, S/4-to-CRM connectors, S/4-to-SRM connectors, each of them maintained against an S/4 release calendar nobody on the satellite team controls. The fix is failed because the satellites become permanently dependent on integration that costs more to maintain than the satellites deliver. The program ends up funding the integration not to enable new business outcomes but to keep retired-by-strategy systems alive operationally.

The opportunity cost compounds: the engineering budget allocated to satellite integration is the budget that should be funding the S/4 analytics and process work the business actually wants.

Fig. 1 — The satellites are not a separate problem. They share retention obligations, source data, and integration cost with ECC, and they retire most efficiently in the same motion.

Step Four — The Real Failure

The actual failure is treating satellite retirement as a separate program.

The real failure is sequencing. Satellite systems share three things with ECC: source data, retention obligations, and the integration bus that fed them. Programs that retire ECC and the relevant satellites in a single application-retirement motion do all three at once: one governed retention store, one retention policy, one retirement of the integration that depended on the old bus.[1] Programs that separate the satellites into "later" do the work three times — once for ECC, once for the satellites, and a third time for the integration that was built to keep the satellites alive in the interim.

The retirement target matters as much as the timing. For an SAP shop, the right target is one that natively understands SAP archive object semantics across ECC and the satellites, so that the BW historical reporting cubes, the CRM activity history, and the SRM contract record can all be retired into the same store with their context intact.

Step Five — The Definition

Now the definition lands.

Satellite retirement is the application-retirement discipline applied to the systems that surround the SAP core — BW, CRM, SRM, GTS, PI/PO, Solution Manager — moving their data and business context into the same governed retention store as the core system, with retention rules and audit response unified across the estate.

The discipline relies on the retention store understanding the satellites natively, so that the integration cost of getting their data out of the source application is paid once, not engineered against each system's idiosyncratic export model.

What Solix Enforces

ECC and satellite retirement run as a single application-retirement motion.

What Solix runs here is the multi-system retirement model: ECC and the satellites scoped together, retired into the same governed store with native understanding of SAP archive object semantics across the estate. The retention rule is authored once. The integration bus is decommissioned once. The retirement budget is paid against one program, not three.

Three things to do this week

• Inventory the satellites and price them. Pull the active SAP system list. List BW, CRM, SRM, GTS, PI/PO, Solution Manager, and any custom Java/ABAP add-ons. Price each at full annual run-rate. The total often surprises the steering committee.
• Identify which satellites are strategically retained in the S/4 architecture. Embedded BW for S/4 absorbs much of the classical BW use case; S/4 Customer Management absorbs much of CRM. Map each satellite against the S/4-native capability that replaces it. The ones with no replacement are candidates for retirement, not modernization.
• Scope ECC and satellite retirement as one program. Build the retirement plan as a single program with one retention store, one ILM policy, and one integration decommissioning track. The unit economics — and the audit response — improve substantially relative to retiring them sequentially.

References

• SAP Help Portal — SAP Information Lifecycle Management (ILM) — Overview. Cross-system retention governance is what makes a unified retirement target work.
• SAP press release — SAP Extends Mainstream Maintenance for SAP S/4HANA and Updates Its Maintenance Strategy. SAP's maintenance timeline applies to the satellites as well as ECC, creating shared calendar pressure.
• SAP Help Portal — Data Archiving with the Archive Development Kit (ADK). The ADK and archive object model extends across ECC and several satellites, enabling shared retirement infrastructure.
• Gartner press — Gartner Forecasts Worldwide Data Management Software Spending. Gartner's data-management research frames the cost of unmanaged SAP estate sprawl.
• IDC press — IDC Worldwide Global DataSphere Forecast. IDC's analysis of enterprise application portfolios establishes the cost share carried by satellites in large SAP estates.