Assessing Transformation Readiness: Scope, NFRs, and Landscape Complexity
Covers how to conduct a structured readiness assessment for an S/4HANA transformation, including scoping, non-functional requirements, integration landscape mapping, and data quality evaluation before committing to a migration path.
Explanation
Once the general transformation approach direction is understood, an architect must run a structured readiness assessment before finalizing scope and timeline. This assessment has several concurrent workstreams: business scope, technical landscape, non-functional requirements (NFRs), integration inventory, and data quality/governance posture. Skipping or rushing this phase is one of the most common causes of scope creep and budget overrun in real transformation programs. Business scope definition means agreeing which legal entities, business units, and processes are in wave one versus later waves. Large enterprises rarely convert everything simultaneously; phased rollouts by region or business unit are common, especially for brownfield conversions where downtime windows must be managed per instance, or for bluefield transitions where carve-outs happen incrementally. The architect must document dependencies between processes (e.g., intercompany billing depending on multiple entities being on the same release) so that phasing does not create inconsistent states. Non-functional requirements deserve explicit engineering attention rather than assumption. Key NFR categories include: performance (batch job windows, period-end close duration, expected user concurrency), availability (uptime SLAs, especially for 24x7 global operations that constrain conversion downtime windows), scalability (growth in data volume and transaction throughput over the next several years), security (authorization model changes introduced by S/4HANA's Fiori-based UX and role redesign), and recoverability (backup/restore times for the target HANA database sizing). For brownfield conversions specifically, downtime NFRs directly influence whether a standard conversion, a near-zero-downtime technique, or a phased technical approach is required; these techniques have different tooling, cost, and risk profiles and should be evaluated against the business's actual tolerance, not an assumed 'zero downtime' target that may not be necessary or affordable. Integration landscape mapping is essential because S/4HANA often changes interface behavior: some ECC BAPIs and IDocs remain valid, but simplification items may deprecate certain tables or transaction codes that custom interfaces depend on. Every inbound and outbound interface (EDI, middleware, direct RFC, file-based, third-party bolt-ons such as tax engines or warehouse systems) must be catalogued and tested against the target release. In hybrid landscapes involving BTP, new integration patterns (event-driven, API-based) may be introduced alongside or replacing legacy point-to-point interfaces, and the assessment should flag which interfaces are candidates for modernization versus which can be carried forward unchanged. Data quality and governance assessment examines master data cleanliness (duplicate vendors/customers, incomplete material master fields), the volume of historical data to be migrated versus archived, and who owns data quality remediation. Poor data quality discovered late in a project (during test loads) is a frequent cause of timeline slippage, so early sampling and profiling of key master data objects should occur during readiness assessment, not during execution. The output of this readiness assessment is a scoped, risk-rated transformation blueprint that feeds into subsequent detailed planning: technical conversion or build planning, cutover strategy, and clean core extensibility decisions (which are covered in later lessons of this topic). An architect who skips this assessment and moves straight to execution planning typically discovers critical blockers mid-project, when remediation is far more expensive.
Real project scenario
A retail group planning an S/4HANA private cloud conversion runs a six-week readiness assessment. The team catalogues 140 interfaces, discovers that 12 rely on tables affected by simplification items, and identifies that customer master data has a 9% duplicate rate across three legacy CRM feeds. Based on NFR interviews with finance, the team learns the true constraint is a 14-hour weekend downtime window, not zero-downtime, which allows a standard conversion approach instead of a costlier near-zero-downtime technique. This assessment materially changes the technical execution plan and budget before any conversion work begins.
Common mistakes
ā¢ Starting technical conversion activities before business scope and phasing are agreed ā¢ Assuming an availability requirement (e.g., zero downtime) without validating actual business tolerance, leading to unnecessary cost ā¢ Failing to catalogue custom and third-party interfaces before assessing simplification item impact ā¢ Treating data quality as an execution-phase concern rather than assessing it during readiness ā¢ Skipping authorization/role impact assessment despite significant UX and role model changes introduced by S/4HANA ā¢ Assuming NFRs gathered for the current ECC system automatically apply unchanged to the target S/4HANA architecture
Best practices
ā¢ Run parallel workstreams for business scope, NFRs, integration inventory, and data quality rather than sequencing them ā¢ Validate downtime and availability NFRs with actual business stakeholders instead of assuming worst-case requirements ā¢ Catalogue every interface and cross-reference against known simplification impacts before finalizing timeline ā¢ Sample and profile master data early to surface quality issues while remediation is still cheap ā¢ Produce a risk-rated blueprint output that explicitly links assessment findings to technical execution decisions
Interview angle
Architects are frequently asked how they would begin a transformation program before any technical work starts. Strong candidates describe a structured readiness assessment covering scope, NFRs, integration inventory, and data quality, and explain how findings from this phase directly change technical decisions such as downtime strategy or interface remediation scope, rather than jumping straight to migration tooling discussions.