Every company that has been running SAP for more than a decade carries an estate nobody can describe in full: reports, interfaces, loads, enhancements, forms and workflows built up over years, largely by people who have since left. This is the WRICEF — and it is, almost always, the single biggest source of uncertainty in a conversion project.

The question the project has to answer at the outset is easy to state and hard to answer: how many of these objects exist, which ones are still used and which ones have to be rewritten? Without those three numbers, any estimate of the timeline is a guess dressed up as a schedule.

Why WRICEF is frightening

It is not the volume in itself. It is the combination of three unknowns.

Nobody knows what each object does. The documentation, where it exists, describes the original intention — not what the object became after seven changes. The real knowledge is in the code.

Nobody knows what is used. A report created for one specific closing in 2016 is still transported, maintained and migrated as if it were essential.

Nobody knows what breaks. The change to the data model in S/4 — tables that became views, fields that changed size, the customer and the supplier that became the business partner — hits exactly the code that reads tables directly. And that is precisely the old code.

The result is the familiar pattern: the project estimates on averages, discovers reality halfway through execution and renegotiates the deadline.

Data first, judgement afterwards

Building the inventory is work for a tool. The environment itself knows which custom objects exist, who created them, when they were last changed and which package they belong to. And the compatibility check tools point out, object by object, what conflicts with the new data model. This is not AI territory — it is a query, and a query has to be exact.

Cutting by usage is the most profitable step and the most forgotten. The environment records execution. Cross-referencing the inventory with usage data from the past two years usually reveals that a large slice of the estate simply does not run. An object nobody runs does not need to be analysed, rewritten or tested: it needs a retirement decision, which is cheap.

Only after those two cuts is the remaining effort worth judgement — and that is where AI changes the economics.

Where AI genuinely comes in

Explaining what the object does. Reading a few thousand lines of ABAP and returning, in business language, which process it serves, which tables it touches and what happens if it ceases to exist. This is the input that lets a key user say “I use that” or “we stopped using that in 2019” — a conversation that stalls today because nobody can explain the object to the person who decides.

Grouping by purpose. There are usually five reports that answer the same question with small variations, created by different areas over the years. Grouping by similarity of purpose — not of name — shows where five objects could become one. It is the same similarity capability we use in master data cleansing, applied to code.

Proposing the destination. With the result of the compatibility check, the usage data and the purpose on the table, the assistant suggests the classification: retire, replace with a standard feature, rewrite within the released extensibility model, or keep with a minimal adjustment. It comes with a rationale and with the evidence that supports it.

Estimating on a comparable basis. Similar objects that have already been dealt with give the effort reference. A traceable estimate by analogy is a great deal better than an estimate by feel.

Supporting the rewrite. When an object has to change, the assistant proposes the version that uses a released interface instead of reading tables directly — and explains what changed. The review still belongs to whoever answers for the code.

What to do with what is left

After the cuts, the remaining estate falls into four destinations, and naming them avoids the endless debate.

Retire. No use and no owner. Block it, observe one closing cycle, remove it.

Replace with the standard. A great many old reports exist because the standard of the day did not meet the need. Much of that is already covered by a native feature — checking before rewriting is the item that cuts the most effort.

Rewrite in the released model. The object is necessary, but it was built in a way that does not survive. This is where an assisted rewrite gains real time.

Keep with an adjustment. It works, it is used, and the adjustment is a narrow one.

That classification is the bridge to the next conversation, the most important one in the project: how to get to clean core — because rewriting while keeping the same bad habit merely defers the problem to the next update.

What changes in the project

The estimate stops being a guess. With the inventory, the usage data and the classification, the number of objects to deal with is known before you start — and it is almost always a great deal smaller than the total, which tends to be the best news of the preparation phase.

The conversation with the business changes. Instead of “you need to tell us what you use”, the team arrives with the list of what has not run for two years and asks for confirmation. Far easier to answer.

The knowledge stays. The description of each object, once validated, becomes documentation that outlives the project — and that today simply does not exist.

The honest limit: none of this decides for you. Cutting development scope is a political decision inside the company, because every object has someone who asked for it. Automation supplies the argument with data; the conversation remains human.

To prepare for this phase, the guide to brownfield, greenfield and bluefield at Inove Academy helps you understand what each approach demands of your development estate — the choice completely changes the size of this work.