SAP ECC to S/4HANA Migration, Step 1: What Is Actually in the System?

16/9/2026

Before anyone can scope an ECC to S/4HANA migration, somebody has to understand what is actually in the system. One read of TADIR, five questions, and a list you can act on.

Custom transactions no one uses anymore. Local objects that cannot be transported. Programs no job has run in years. These are the things that quietly consume budget and delay an SAP migration when they are found late.

An ECC to S/4HANA move is a twelve-phase program. Six of those phases are where the data work lives, and this is the first of a series of videos that walks through each one with the DVW Flow Tool. Step 1 is discovery and profiling.

This post covers what the flow reads, the five questions it answers, and why one of the outputs is a decommissioning list rather than a migration list.

Step 1 of 6: one read of TADIR, five questions, and a decommissioning list built in about 40 seconds. Also available on YouTube.

Twelve phases, six of them data

A full ECC to S/4HANA program runs from the strategy decision to the day the legacy system goes dark, typically twelve to twenty-four months, and it touches data, custom code, integrations and process. Strategy and scope, target design, building the load, cutover rehearsal, go-live and decommissioning belong to the program around the data.

Six phases are the data workstream, and they are the ones this series covers with the DVW Flow Tool: discovery and profiling, cleanse, map, mock load, reconcile, and parallel run. Each gets its own video. This is the first.

Before anyone can scope the migration, somebody has to understand what is actually in the source system. SAP's own Readiness Check covers much of this, and the ABAP Call Monitor gives you a detailed history of usage. What follows is something you can run straight away on your own system, with the checks and balances you choose, and repeat as often as the scope moves.

One read of TADIR, five questions

The scope question has an answer, but it is spread across several tables: the repository, the role menus, the transaction texts, the job logs. The discovery and profiling flow brings them together. It starts with one read of TADIR, the master inventory of every repository object, its package and who wrote it.

Two filters on that read do most of the noise reduction. R3TR limits the result to the main objects rather than every include and method underneath them. Dropping deleted and generated objects removes entries nobody has to decide about. What is left is still tens of thousands of rows, but every one of them is a real object somebody owns.

Then five questions come off the back of it. One extract, five answers.

1. What is in here?

A lookup turns the object type code into something readable, and the result rolls up by package, so the first output is an inventory a program manager can read: how many programs, function groups, tables, transactions and so on, and which packages hold them.

Then the split that matters. Objects sitting in a local package cannot be transported anywhere. They exist in this system and nowhere else. If any of them are needed in S/4HANA, somebody will have to assign them to a transportable package first, and that is work the plan needs to know about now, not during the build.

2. Which transactions can anyone actually run?

This is the one that changes scope. The flow takes the custom transactions out of TADIR and looks each one up in AGR_TCODES, the table behind the role menus. If a transaction comes out of the matched side, somebody somewhere has it in a role. If it comes out the other side, no one does.

That unmatched list is not a migration list. It is a decommissioning list, and in the video it takes about 40 seconds to build.

3. What are they called?

A list of codes like ZZ105 is not much use to the person who has to decide whether a transaction is migrated. So the flow reads TSTC for the codes and joins TSTCT for the English short text. Now it is a list the project team can read and make a call on, rather than something that has to go back to the ABAP team first. That single join is the difference between a technical extract and a business decision.

4. How much code is actually behind it?

Filter down to the custom function groups, then filter further to list the function modules inside them. In the demo system that is two and a quarter thousand function modules, and every one of them is something a developer has to look at if the group it belongs to is in scope. The count is the estimate the program has been missing.

5. Which programs are still being used?

The flow pulls the custom programs, reads their attributes, then matches them against the background job steps. A program that no job has run is a strong candidate for retirement. Paired with the role-menu check on transactions, this gives the program two independent usage signals before anyone opens a line of code.

The same flow for master and transactional data

Nothing about this is specific to code. The same pattern profiles customers, vendors, materials, pricing conditions, sales orders and any other domain in scope: read the object, count it, split it by the attribute that decides whether it moves. At every point you can run the counts and export the results, so the business and data teams hold a fast, repeatable analysis rather than a one-off report from the basis team.

One workflow, one run, multiple spreadsheets, every one of them something a real person on the program can act on.

Keep the picture current

Scope moves during a migration. Put the flow on Flow Tool Server and it runs on a schedule, so the inventory, the decommissioning list and the usage counts stay current without anyone re-running them by hand. When the steering committee asks what changed since the last cut, the answer is already in the output folder.

That is discovery and profiling. You now know what is in the system, what can move, and what should not. For the wider picture, including the teams staying on ECC past 2027, see the SAP ECC end of support primer and the SAP data migration solution page.