S/4HANA Migration for Banks: Why the choice between brownfield, greenfield, and selective data transition comes down to cost

S/4HANA migration for banks: why the choice between brownfield, greenfield, and selective data transition comes down to cost

Mainstream maintenance for ECC 6.0 systems ends on December 31, 2027. An extension until 2030 is possible, but it comes with a 2 percentage point surcharge on the maintenance base—in practice, this means 9 to 12% higher total costs. Starting in 2031, Customer-Specific Maintenance will take effect: no more Legal Changes updates, no security guarantee, and no SLAs. Banks that do not plan their migration now will end up paying more either way.

The real question, therefore, is not whether to migrate, but how. And this decision has a direct impact on project costs, duration, and the quality of the resulting process landscape.

Starting Point: More than just a technical upgrade

Institutions facing an S/4HANA migration usually have several areas requiring attention at the same time. The IT architecture has evolved over the years and has become correspondingly complex. Data volumes have increased, authorization models have at least room for optimization, and the resulting license costs are often higher than necessary. Ignoring these issues during migration and simply changing the system version does not solve any problems. It merely carries them over into the new system generation.

Proper migration preparation therefore covers more than just a technical upgrade:

• Evaluation of the business case,
• Selection of the appropriate deployment model,
• Optimization of licensing,
• Validation of infrastructure parameters and
• Definition of the target architecture.

Three migration paths

SAP migration strategies fall between two extremes.

In a system conversion (brownfield), existing customizations are fully carried over, and process redesign is minimal. The conversion effort is low, but inefficient or outdated processes are carried over unchanged.

In a new implementation (greenfield), the system is set up completely from scratch, based on SAP best practices, with minimal process reuse. This results in maximum adherence to the standard (keyword: “Clean Core”), but also entails the highest effort and the greatest migration risk.

In between lies selective data transition (also known as bluefield), which comes in two variants: Shell Conversion (primarily brownfield, over 50% reuse, automated) and Mix & Match (primarily greenfield, under 50% reuse, partly manual).

Brownfield saves effort in the short term but cements existing inefficiencies. Greenfield offers the closest alignment with the standard but requires the most effort for the transition. Based on project experience, the economic sweet spot therefore often lies in the bluefield range, a cost-effective solution close to the current state, with targeted process streamlining where it pays off.

Transformation path in SAP banking: not every module is simply migrated

For banks, the migration from ECC to S/4HANA is often more than just a technical conversion: Existing modules are migrated to new SAP products or replaced by enhanced successors. The interdependencies between modules, with neighboring projects, and with the many custom interfaces are correspondingly high, compounded by specific configurations and extensive modifications. The downside: The technical transformation can be leveraged to improve processes, increase efficiency and quality, and—above all—further digitize credit processes.

• SEM Banking: A business challenge. SEM Banking is typically deeply embedded in overall bank management, contribution margin accounting, and regulatory reporting. The challenge is therefore less technical and more business-oriented, and strategic architecture decisions are required for the individual SEM components: a third-party solution or a modular replacement with native S/4HANA modules. In the second option, SAP PaPM (Profitability and Performance Management) takes over the tasks of the Profit Analyzer. Large parts of the Risk Analyzer are integrated into SAP TRM (Treasury and Risk Management), such as Value-at-Risk and sensitivities in the Market Risk Analyzer or limit monitoring in the Credit Risk Analyzer. Functions of the Strategy Analyzer can be replaced by SAP Analytics Cloud for planning and strategy. Good to know: Historically, TRM and SEM Banking have used the same financial mathematics engine via the Market Risk Analyzer (present value calculations, volatilities, Value-at-Risk). It is therefore crucial to determine which existing functionalities can be transferred to the TRM Analyzers.
• CFM: manageable effort. No major changes are expected for proprietary trading activities mapped in SAP CFM. The functions will remain available in the SAP TRM Transaction Manager; CFM will be migrated via system conversion, and existing customizations will be analyzed and adjusted as needed. A transition to Fiori apps is possible.
• BCA: Consider switching to transactional banking. Although SAP BCA has been migrated to S/4HANA, SAP Fioneer has discontinued further development of the module. A switch to SAP Transactional Banking (TRBK) should therefore be urgently considered. TRBK offers additional functions in item management (rule set), complex scheduling rules, master contract management for framework agreements (including cash pooling, netting, facilities, and group-wide settlement), as well as well over 1,000 Business Add-Ins. This makes it highly likely that numerous in-house developments and modifications can be replaced. At the start of the project, it is recommended to conduct an inventory of in-house developments and interfaces in BCA, including a comparison of requirements with the standard TRBK functions.
• CML and CMS: Collateral management as the sticking point. For the CML loan functions, the switch to S/4HANA does not result in any direct customization requirements. However, adjustments are necessary in Product Customizing and for authorization roles because SAP CMS will be used in the future: The previous collateral management in CML is no longer available in S/4HANA. CMS must be set up and the data must be migrated. In addition, all functions that access collateral management—whether for reading or writing—must be adapted, such as the collateral register, correspondence, add-ons, reporting, and in-house developments. In return, CMS provides a more comprehensive representation of collateral and allocates it more flexibly, which requires close integration with credit risk management and reporting. Regardless of this, the smooth operation of fundamental applications such as loan loss allowances, ratings, and the refinancing register should be validated.
• Complex Loans (CL): new data structure. The CML extension for Complex Loans can improve the processing and management of investment, foreign, and syndicated financing. It introduces new data entities: the financing as a parent object that aggregates all tranches and drawdowns; the tranche as a credit line with its own volume and term; the drawdown as a specific utilization of a tranche; and the covenant with validation logic and an escalation process for contractual conditions.

Across all modules—particularly in TRBK and CML/CMS—there is potential to reintegrate in-house developments into the standard system. This is precisely why it is worth thoroughly reviewing your current system and processes before selecting a migration path.

How the decision is objectified

The SAP Readiness Check shows what changes in the system as a result of the transformation. However, it does not address what should be optimized beforehand to make the migration itself more cost-effective and the target architecture more streamlined. This is where msg.FIT comes in.

The usage analysis runs without a system restart, based on the evaluation of SCMON and SUSG log data. This reveals which transactions, customizations, and reports are actually used—and which are merely dead weight that would otherwise be migrated unnecessarily.

The authorization and license analysis uncovers SoD conflicts as well as inactive or incorrectly assigned licenses. Because SAP is transitioning to a new, authorization-based licensing model with S/4HANA, this is not just a compliance issue but a direct cost lever.

When analyzing in-house developments, the process checks which developments were never used in production or whether their functionality is now covered by the standard system. Here, too, there is usually potential for cost savings.

Ultimately, these three levels do not result in a mere inventory but rather in a recommendation for a migration strategy and roadmap. The goal is to reduce the effort required for the “Explore” and “Realize” phases before it arises, rather than correcting it retroactively during an ongoing project.

Project approach: from kick-off analysis to recommendations

The underlying methodology consists of several steps. It begins with project initiation and the alignment of governance, roles, and scope. This is followed by an analysis based on stakeholder interviews and the identification of project-relevant factors such as company growth, new business areas, or parallel projects. This forms the basis for strategic IT planning: system assessment using a Readiness Check and msg.FIT, and documentation of the current state. Scoping and an action plan—including workstreams for processes, IT architecture, licenses, project planning, effort, and costs—ultimately result in a consolidated final report featuring a roadmap, critical path, risks, and concrete recommendations for action.

This structured process ensures that the migration decision is based on a documented assessment of the current state, not on a blanket preference for greenfield or brownfield.

Conclusion

The choice of S/4HANA migration strategy is not a purely technical decision. It depends on the specific state of the existing system landscape: the extent of customization, the authorization structure, and the licensing situation determine how much reuse makes economic sense. Financial institutions that systematically assess these factors before making a decision lay the groundwork for objectively choosing between the three paths, rather than committing to a blanket “brownfield” or “greenfield” approach before their current state is even known.