The short answer. No, you almost certainly should not migrate all your ECC data. Migrating everything inflates cost, effort, and risk while dragging years of duplicates and dead records into your clean new system. The better approach is selective: migrate the master and open transactional data the business genuinely needs, archive history that must be retained but not live, and leave behind what serves no purpose. Deciding what not to move is one of the most valuable decisions in a migration.

There is a strong instinct, when facing a migration, to bring everything across just in case. It feels safe. It is actually one of the most expensive choices you can make, and it undermines the very reason you are moving to a clean new system. Here is why less is usually more, and how to decide.

Why migrating everything is a mistake

Every record you migrate has to be extracted, profiled, cleaned, transformed, validated, and reconciled. That effort applies whether the record is valuable or worthless. So migrating everything means spending your migration budget cleaning and moving data that no longer serves any purpose, old customers you will never trade with again, duplicate materials, transactions closed a decade ago. Worse, it defeats the point of the move. You are transitioning to a clean, modern system, and filling it with the accumulated clutter of the old one carries the problems forward. Migrating everything is not the safe option; it is the expensive one.

The three buckets

Not all data deserves the same fate. The skill is sorting it before you move.

A cleaner way to think about it is to sort your data into three buckets:

Migrate. The master data and open transactional data the business genuinely needs to operate in the new system. This is what moves.
Archive. History you are required to keep, for legal or reference reasons, but that does not need to be live in S/4HANA. This can be retained in an archive rather than migrated.
Leave behind. Duplicates, dead records, and data that serves no ongoing purpose. This is simply dropped.

Sorting data this way, rather than treating it all identically, is what keeps the migration focused and the new system clean.

Archiving is not the same as migrating

A common confusion is treating "we must keep this data" as "we must migrate this data." They are different. Data you are legally required to retain, but that you will rarely if ever need to touch, does not belong in your live production system. It can be archived, kept accessible for compliance and reference, without the cost of cleaning and transforming it into the new model. Separating retention from migration frees you to migrate lean while still meeting your obligations. The question is not just "do we need to keep this?" but "does this need to be live in S/4HANA?"

How to decide what moves

The decisions become much easier once you have profiled your data, because profiling shows you what you actually have. It reveals which records are active versus dormant, which are duplicates, and where the dead weight sits. Armed with that, you can make evidence-based decisions: these active customers and open orders migrate, this closed history archives, these duplicates and dead records are left behind. Without profiling, the "migrate everything" instinct wins by default, because no one can confidently say what is safe to leave. Profiling is what gives you the confidence to migrate lean.

Addressing the fear of leaving data behind

The instinct to migrate everything usually comes from a specific fear: what if we need it later and it is gone? It is a reasonable worry, and the answer is not to migrate everything but to distinguish between leaving data behind and losing it. Data that is genuinely required can be archived, kept accessible for compliance and occasional reference, without being migrated into the live system. Data that is truly redundant, duplicates and dead records, is not lost by being left behind, because it had no ongoing value. Once teams see that "not migrated" does not mean "gone," the fear that drives the migrate-everything instinct largely dissolves. The real question becomes which bucket each piece of data belongs in, which is a manageable decision rather than a frightening one.

The compounding benefit of a lean migration

Migrating lean pays off well beyond the migration itself. A new system that starts clean, without the accumulated duplicates and clutter of decades in ECC, is easier to operate, report on, and trust from day one. Users are not confused by dead records and duplicates. Reports are not distorted by data that should have been left behind. Performance is not weighed down by volumes that serve no purpose. And future initiatives, analytics, automation, further change, start from a cleaner foundation. The effort of deciding what not to migrate is repaid continuously in a system that is leaner and more trustworthy for years. Migrating everything, by contrast, imposes an ongoing tax of clutter that someone has to work around indefinitely.

Where to start with the decision

If deciding what to migrate feels overwhelming, the practical starting point is to profile and let the data guide you, working object by object rather than trying to decide everything at once. Begin with the objects that carry the most volume and the most obvious dead weight, master data with known duplicate problems, or transactional history stretching back years. For each, profiling shows you what is active, what is dormant, and what is duplicate, which turns an abstract worry into a concrete set of decisions. Tackling the decision in manageable pieces, informed by what profiling reveals about each object, makes it far less daunting than staring at the whole landscape at once and trying to draw the line everywhere simultaneously.

How deKorvai helps

deKorvai gives you the visibility to migrate selectively rather than wholesale. It profiles your ECC data to reveal what is active, what is duplicate, and what is dormant, so scope decisions rest on evidence. It de-duplicates using fuzzy matching, so the duplicates you would otherwise carry across are identified and resolved. And it transforms and loads only the data you decide to migrate, cleanly into the S/4HANA target with reconciliation. Because deKorvai supports selective data transition approaches, it is built for exactly this kind of deliberate, lean migration rather than dragging everything across.

Key takeaways

Do not migrate everything: it inflates cost and risk and clutters the new system.
Sort data into three buckets: migrate, archive, or leave behind.
Archiving is not migrating: retained data need not be live in S/4HANA.
Profile first to decide what genuinely deserves to move.

Frequently asked questions

Do I need to migrate all my ECC data to S/4HANA?

Almost certainly not. Migrating everything inflates cost, effort, and risk, and drags duplicates and dead records into your clean new system. The better approach is selective: migrate what the business needs, archive what must be retained, and leave the rest behind.

What is the difference between archiving and migrating data?

Migrating brings data into your live S/4HANA system, which means cleaning and transforming it. Archiving retains data for compliance or reference without making it live. Data you must keep but rarely need does not have to be migrated; it can be archived instead.

How do I decide what data to migrate?

Profile your data first. Profiling reveals what is active, what is duplicate, and what is dormant, so you can make evidence-based decisions: active records migrate, required history is archived, duplicates and dead records are left behind. Without profiling, the migrate-everything instinct wins by default.

Is it risky to leave data behind?

Less risky than migrating everything. Leaving behind duplicates and dead records removes clutter and cost, while genuinely required history can be archived to remain accessible. Profiling gives you the confidence to know what is safe to leave, so the decision is evidence-based rather than a guess.

Do You Really Need to Migrate All Your ECC Data?