You want a Clean Core. You can’t leave your business behind.

In an emptied, freshly cleaned office, a woman stands with her hands on her hips before the one old filing cabinet left behind, its drawer still full.

The board has heard the phrase “Clean Core” and turned it into a slogan.

You’ve seen the code analysis. Several hundred custom objects in ECC. Some obsolete. Some could go back to standard. And some of them are how the company actually does business.

Throw those away and the business breaks. Lift and shift them into S/4HANA and the new system inherits the old one’s habits. And it breaks the “Clean Core” mantra.

Not all custom code is bad code

Custom code isn’t one thing. It’s a mix of:

  1. obsolete developments nobody uses

  2. functionality SAP standard now covers

  3. logic that belongs outside the core

  4. procedural custom development

  5. genuine business rules the organisation still needs

Most remediation plans deal with the first three well. The last two tend to travel together into the new system. Not because anyone decided they should. Because it’s the path of least resistance.

A woman in a dark suit jacket stands facing the viewer, hands on hips, with a proud smile, in a cleared office in golden light.

Keep the rules. Question the implementation.

Clean.

BRF+ exists in both ECC and S/4HANA. So you don’t have to wait for the transformation project. You can move rules out of custom code and into BRF+ in ECC, today. Your move to S/4HANA can start long before the project does.

Design the input with S/4HANA in mind. Moving BRF+ from ECC to S/4HANA can be a simple export and import. The hard part is what you feed it. Don’t build on ECC tables that no longer exist in S/4HANA, such as KONV, VBUK or VBUP. Where your ECC release supports CDS views, feed BRF+ from CDS views designed to work in both systems, so the rules arrive in S/4HANA with nothing to rewrite.

Questions worth asking of every custom object in ECC, starting now:

  • What does it actually do?

  • Which part is processing, and which part is a rule?

  • Does the rule still matter?

  • Where should it live in the new architecture?

Clean Core isn’t a magic trick

Moving logic into BRF+ doesn’t make the whole implementation Clean Core. You still have to decide what belongs in BRF+ and what has to stay in custom code. BRF+ can give your rules a better home.

The objective isn’t less code running in SAP. It’s less bespoke code you have to own.