What Should an ECC to S/4HANA Discovery Assessment Disqualify Before a Migration Path Is Chosen?

This distinction prevents an attractive feature from compensating for a fundamental delivery problem.

A lower cost is a preference. A statutory requirement to retain auditable historical records is a constraint. An inability to access those records under the proposed design can become a disqualifier.

The difference must be established during discovery.

What Must Brownfield Prove Before It Remains Viable?

Brownfield is often treated as the continuity option. It starts from the existing SAP ERP system and converts it to S/4HANA, retaining much of the configuration, data, and process history.

Continuity has value when the current system reflects the organisation the enterprise wants to keep.

The first brownfield gate should therefore ask:

Does the existing ECC design provide a suitable foundation for the future operating model?

A technical conversion may be feasible even when the answer is no.

The discovery team should test whether the existing organisational structure, chart of accounts, process variants, master data model, and custom developments remain relevant. It should also identify whether planned mergers, divestitures, shared-service changes, or regional consolidations conflict with the retained ECC design.

Brownfield should be challenged when:

• Broad process redesign is already an approved programme objective.
• Multiple ECC instances must be consolidated.
• The current organisational structure conflicts with the future business.
• A large share of custom development supports processes marked for retirement.
• Local process variants must be replaced by enforceable global standards.
• The current data footprint creates unacceptable conversion or operating complexity.
• The enterprise expects the conversion itself to resolve long-standing process debt.

An SAP ECC readiness check provides important technical evidence. SAP Readiness Check can identify relevant simplification items, high-level custom code impact, add-on compatibility, sizing considerations, and other conversion factors. SAP recommends the tool as part of conversion preparation.

Those findings establish the technical work required for conversion. They do not determine whether retaining the current system design is the right business choice.

Technical convertibility is an entry condition for brownfield, but choosing the right SAP service provider also depends on how well discovery connects system evidence with business decisions.. It is insufficient as a recommendation.

When Should Greenfield Be Removed from Consideration?

Greenfield is frequently associated with process redesign, standardisation, and a cleaner target environment. Those outcomes depend on decisions that sit outside the software.

A new implementation requires the enterprise to define what the future system should contain. This includes process variants, organisational structures, reporting models, roles, controls, master data rules, integrations, and the historical data that must remain accessible.

Greenfield becomes difficult when the organisation wants change but cannot govern it.

The discovery assessment should examine whether:

• End-to-end process owners have decision authority.
• Global standards can override local preferences where required.
• Business teams have enough capacity to participate in design and validation.
• Data owners can decide what should be migrated, archived, corrected, or retained elsewhere.
• Historical reporting can operate across the target and legacy environments.
• The organisation can absorb the expected change across roles, controls, and daily work.
• The programme timeline allows enough time for design, testing, training, and adoption.

Greenfield should be disqualified when the programme requires enterprise-wide redesign but has no mechanism for settling cross-functional decisions.

This is rarely visible in a system scan. It appears in governance interviews, process workshops, decision logs, and the speed at which business owners resolve disagreements.

A discovery team should pay attention when every workshop ends with “the business will decide later.” That phrase signals a dependency, not progress.

SAP currently positions New Implementation as one of the supported transition paths and uses the SAP S/4HANA migration cockpit to move selected master data and open items into a new environment. The tooling supports migration execution. It cannot supply missing process ownership.

The greenfield question is therefore larger than whether a clean implementation is technically possible.

The path must prove that the enterprise can design and adopt the business it intends to configure.

When Does Selective Transition Become an Unsafe Middle Ground?

Selective transition is often described as a balance between system conversion and new implementation. That description can make it sound easier than it is.

The path becomes valuable when an enterprise needs precision. It may want to retain selected history, move specific company codes, reduce data volume, preserve chosen configurations, or combine conversion with structural change.

Precision creates its own conditions.

SAP describes Lean Selective Data Transition as an approach between complete system conversion and new implementation. It supports the migration of selected data and is intended to reduce data volume while retaining valuable historical information. SAP Business Transformation Center can also support selection through company codes and time slices for Lean Selective Data Transition scenarios.

The discovery team must determine whether the enterprise can define those selections without damaging business continuity or data integrity.

Selective transition should be challenged when:

• Data-selection rules remain broad or disputed.
• Organisational entities cannot be separated cleanly.
• Historical and current transactions have complex dependencies.
• Phased entities must operate across source and target systems without a workable reconciliation model.
• Temporary integrations would create unacceptable operational risk.
• The programme cannot define how balances, open items, documents, and reporting history will be validated.
• The cost of selective migration logic exceeds the value of retaining selected structures.

Selective transition is not a safe compromise. It is a controlled separation of business data, configuration, and organisational scope.

Weak selection rules create weak migration controls.

SAP’s Digital Blueprint supports analysis of source-system data and can provide a basis for defining migration scope in Lean Selective Data Transition scenarios. That analysis still requires business owners to decide which data remains relevant and which structural relationships must be preserved.

Which Findings Should Act as Migration Path Decision Gates?

A S/4HANA migration path evaluation needs decision gates that expose path-breaking conditions early.

The gates should be agreed before detailed estimates are presented. Otherwise, cost and schedule preferences can influence how findings are interpreted.

Decision gate	Question discovery must answer	Path most likely to be challenged
Operating-model gate	Can the current ECC design support the approved future business model?	Brownfield
Process-governance gate	Can business owners define and enforce target processes?	Greenfield
Structural-change gate	Are consolidation, separation, or major organisational changes required?	Brownfield
Historical-data gate	Which history must remain operational, reportable, and auditable?	Greenfield or selective transition
Data-selection gate	Can selected data be isolated without breaking required relationships?	Selective transition
Coexistence gate	Can source and target environments operate safely during a phased move?	Selective transition
Custom-code gate	Which developments still support valid future requirements?	All paths
Integration gate	Can connected systems support the target design and transition period?	All paths
Downtime gate	Can the path meet the maximum acceptable business outage?	Brownfield or greenfield
Change-capacity gate	Can the organisation make and adopt the decisions the path requires?	Greenfield
Validation gate	Can financial and operational results be reconciled before go-live?	All paths

A gate should have a defined threshold.

“Data quality needs improvement” is too vague. “Customer master duplicates must fall below the agreed tolerance before migration rehearsal” is testable.

“Custom code is complex” is equally weak. “The order-pricing enhancement has no confirmed S/4HANA design owner and affects 38 active interfaces” identifies a decision that can be assigned and resolved.

Discovery becomes useful when findings produce decisions.

How Should ECC Landscape Findings Be Interpreted?

A conventional SAP discovery assessment often divides work into technical streams. One team reviews infrastructure. Another examines processes, data, code, and integrations. Each stream produces its own report.

The reports become lengthy because every finding is recorded. Their decision value remains unclear because the findings are not connected to migration-path viability.

A stronger assessment asks what each evidence set can disqualify.

What Does the Current ECC Landscape Prevent?

The landscape review should identify active systems, enhancement packages, databases, clients, company codes, add-ons, background jobs, interfaces, and dependent applications.

Inventory alone has limited value.

The assessment must show which landscape conditions restrict consolidation, cutover, cloud deployment, system separation, or decommissioning. It should also compare architecture documentation with runtime evidence. An interface listed in an old diagram may no longer run. An undocumented batch dependency may still control month-end close.

The relevant question is:

Which part of the current landscape can force a change in migration path, sequencing, or scope?

Which Processes Deserve to Survive the Move?

Process discovery should avoid assuming that current usage proves future value.

A heavily used process may still be inefficient. A low-volume process may carry legal, safety, or revenue significance. Usage data needs business interpretation.

Each process variant should be assigned a disposition:

• Retain
• Standardise
• Redesign
• Retire

This classification has direct path implications. A high percentage of retained processes can strengthen the brownfield case. Extensive redesign increases the demands placed on greenfield governance. A mixed disposition across entities may support selective transition, provided the separation rules are workable.

The assessment should record who approved each disposition. Unowned decisions become migration risk later.

Which Simplification Items Change Business Design?

An SAP simplification item analysis should do more than produce a technical remediation list.

SAP’s Simplification Item Catalog contains changes across functions, data models, tables, and other S/4HANA elements. SAP Readiness Check helps identify items relevant to the source environment, while the wider catalog contains items that may not apply to a specific conversion.

Each relevant simplification item should be classified by its consequence:

• Technical remediation
• Process decision
• Data correction
• Integration change
• Reporting impact
• Test requirement
• Business-owner validation

A simplification item that changes an underlying object may affect custom code. Another may change how users execute a process or how a connected system consumes data.

The assessment should identify these chains. A list of findings without ownership hides the real effort.

Which Custom Code Has Earned a Place in S/4HANA?

A custom code impact assessment should begin with usage and business purpose.

Code volume alone does not establish migration effort. The critical questions concern active use, process dependency, ownership, S/4HANA impact, maintainability, and overlap with standard functionality.

SAP’s current custom code guidance supports usage analysis through tools such as ABAP Call Monitor and SUSG. The Custom Code Migration app and ABAP Test Cockpit can identify code affected by S/4HANA simplifications and estimate adaptation effort.

Every custom object should receive a disposition:

• Retire because it is unused.
• Replace with standard functionality.
• Adapt because it supports a valid requirement.
• Redesign because the underlying process is changing.
• Isolate because it belongs outside the digital core.

The migration-path decision should reflect the code required by the future business. Carrying code forward because remediation appears easier can preserve the problem the programme was expected to remove.

Which Integrations Could Control the Programme?

Interface counts create false comfort.

One hundred low-risk batch interfaces may require less governance than one real-time integration controlling pricing, tax, warehouse automation, banking, or production execution.

The assessment should classify integrations by business criticality, data flow, frequency, technology, reconciliation method, ownership, downtime tolerance, and target compatibility.

It should also examine the transition architecture.

A phased selective move may require temporary routing, replicated master data, dual maintenance, or cross-system reporting, making SAP integration services critical to migration path evaluation. A greenfield implementation may leave legacy systems active for historical access. A brownfield conversion may require connected applications to adapt during the same cutover window.

These conditions can influence the path more than the number of interfaces.

Which Data Must Continue to Operate?

Database size does not answer the migration question.

Discovery should identify which data must remain active, which history must be accessible, which records need correction, and which information can be archived or retained outside S/4HANA.

The assessment should separate:

• Open operational data
• Historical transactional data
• Master data
• Audit and compliance records
• Data supporting warranties or long-running contracts
• Reporting history
• Obsolete or redundant records

Validation requirements should be defined at the same time as migration scope. SAP’s Data Transition Validation tool supports before-and-after comparisons for system conversion and Lean Selective Data Transition, including standard and custom reports and transparent tables.

The tool can support validation execution. The enterprise must first define which financial and operational results need to match.

What Should the Discovery Assessment Produce?

Discovery should finish with a decision package.

A slide showing that brownfield scored 78 and greenfield scored 74 is insufficient. Leadership needs to understand which paths survived, which paths failed, and what evidence drove the result.

The central deliverable should be a Migration Path Disqualification Register.

Register field	What it records
Enterprise requirement	The condition the future ERP environment must satisfy
Evidence	The system, process, data, code, integration, or organisational finding
Path challenged	Brownfield, greenfield, or selective transition
Decision gate	The threshold used to test the path
Disqualification reason	The requirement the path currently fails
Business consequence	The risk created if the path proceeds
Decision owner	The person accountable for accepting or resolving the issue
Re-entry condition	The change required for the path to become viable
Resolution deadline	The date by which the condition must be settled

The re-entry condition prevents premature finality.

A path may be unsuitable under current assumptions and become viable after scope changes. Greenfield may return to consideration when process owners receive authority. Brownfield may become feasible if consolidation is removed from the programme. Selective transition may survive once data-selection and coexistence rules are approved.

This turns discovery into an active decision process rather than a static report.

When Should Cost and Timeline Be Compared?

Cost and timeline should enter after migration-path viability has been established.

Early estimates often reward the path that preserves the most assumptions. Brownfield appears economical when future process remediation is excluded. Greenfield appears cleaner when legacy retention and historical reporting are ignored. Selective transition appears balanced when coexistence, reconciliation, and specialist migration effort are understated.

Each viable path should be estimated across the same cost boundaries:

• Preparation and remediation
• Process design
• Custom code disposition
• Integration redesign
• Infrastructure and environments
• Testing and reconciliation
• Change management
• Cutover
• Legacy retention
• Decommissioning
• Post-go-live support

The timeline should expose dependencies rather than present one go-live date.

Data correction, add-on decisions, process ownership, archiving, code retirement, infrastructure provisioning, and interface redesign may need to begin before the formal implementation programme.

A credible ERP transformation roadmap should show which activities reduce uncertainty, which activities depend on the selected path, and which decisions can still change scope.

What Should Leadership Know Before Approving the Migration Path?

Discovery is complete when leadership can answer five questions:

1. Which migration paths remain viable?
2. Which paths were disqualified, and by what evidence?
3. Which assumptions could change the recommendation?
4. Which risks must be resolved before implementation begins?
5. Which business owners are accountable for the remaining decisions?

This is the standard an ECC to S/4HANA discovery assessment should meet.

A migration path should not win because it received the highest score. It should remain after the weaker options have failed clearly defined enterprise tests.

That difference changes the purpose of discovery. The assessment stops being a catalogue of ECC complexity. It becomes a controlled method for preventing the wrong programme from being approved.

TechPoint, A Cygnet.One company, helps enterprises connect SAP system evidence with process, data, integration, governance, and operating-model decisions. The result is a migration recommendation that can be explained, challenged, and defended before implementation spend begins.