Technical guide
Which technical uncertainties should be made visible before a transformation?
The uncertainties that need to be visible fall into these areas: product and release scope, custom code, integrations, data and archiving, authorisations, operations and support, dependencies, testability, fallback, and decision ownership. The aim is not to resolve them all at once. The aim is to tie each one to a level of impact and a decision owner, so it is clear which assumptions the plan rests on.
- Prepared by Castintech
- Last verified 23 September 2026
- 12 min read
- Sources
In this guide
Sections
Scope. This guide is a general framework for handling technical uncertainties ahead of a transformation of SAP® software. Maintenance timeline information is given together with the product scope it applies to and linked to official sources; it should be confirmed separately against your own release and contract position. The other sections are Castintech’s assessment framework.
What is the difference between uncertainty and risk?
A risk is an event whose likelihood and impact can be estimated, at least roughly. An uncertainty is the lack of the information needed to make that estimate. “We don’t know whether this interface will work in the new release” is an uncertainty; once evidence is gathered, it either disappears or becomes a measurable risk.
A large part of transformation readiness is making that conversion deliberately.
An uncertainty nobody can see enters the plan as a hidden assumption. Timeline, budget and scope are prepared as if that assumption were true, and when it turns out to be wrong, nobody knows which part of the plan is affected.
How are uncertainties classified?
Each uncertainty is assessed on two axes: its impact on the plan or decision, and how easily it can be resolved. Two more items are added: who will decide, and the latest date by which an answer is needed. Those four determine which uncertainty gets resources first, so effort goes where it is most likely to change a decision.
| Easy to resolve | Hard to resolve | |
|---|---|---|
| High impact | Resolve now; do not let it hold up the decision | Start early, take it to the decision owner, write down the working assumption |
| Low impact | Resolve in a planned step | Record it as an assumption and monitor it |
Text description of the diagram
Start: the ten areas where uncertainty comes from; product and release scope, custom code, integrations, data and archiving, authorisations, operations and support, dependencies, testability, fallback and business continuity, decision ownership. The ten areas join one collector; each uncertainty becomes an entry. The uncertainty log entry states what is not known in one sentence and holds seven fields: impact, ease of resolution, decision owner, needed-by date, working assumption (marked as an assumption), closure evidence (marked as evidence) and status: open, being resolved, logged as a risk, closed. Impact and ease of resolution feed the prioritisation field: high impact and easy means resolve now; high impact and hard means start early, take it to the decision owner and write down the working assumption; low impact and easy means resolve in a planned step; low impact and hard means record it as an assumption and monitor it. Closure evidence feeds closure: an uncertainty closes when the criterion written in advance is met, and without a closure record it counts as open. There are three ways to close: resolved, turned into a measurable risk and moved to the risk log, or knowingly accepted as an assumption by the decision owner and still monitored. End: four equally weighted planning inputs meet at the transformation decision: business goals, the state of the uncertainties, technical readiness and the maintenance timeline. The maintenance timeline is a planning input; it does not settle the decision on its own and is not a reason for urgency. Boundary: each maintenance date is checked against the product scope it applies to and the organisation's own release and contract position. The diagram shows no dates and has no loop. On mobile the diagram reads as four panels in order: 1/4 ten areas, 2/4 the uncertainty log entry, 3/4 prioritisation and closure, 4/4 the transformation decision. Colophon: Castintech, D5, September 2026; technical explanatory diagram, not an SAP® product interface.
Which questions should be asked in each area?
Product and release scope
- Are the currently installed products, releases and enhancement package levels on record?
- Is the target product and release clear, for example which release of SAP S/4HANA® software and which operating model?
- Has an equivalent been confirmed in the target product for each capability in use?
- Does the licence scope include the planned tools and services?
Custom code
- Is there an inventory of custom code written in the ABAP® programming language, covering use, ownership and dependencies?
- Are the checks provided for a move to SAP S/4HANA, which run through the ABAP Test Cockpit (ATC) [3], available on the installed release?
- Which custom code units can be retired and which need adapting?
Method: Assessing a custom code inventory.
Integrations
- Is the full list of interfaces known, with direction, counterpart and owner?
- Which interfaces can be used unchanged in the target product, and which will change?
- Have the counterpart systems been asked whether they are ready for the change?
Design principles: Error handling and safe reprocessing in integrations.
Data and archiving
- Are the volume, quality and retention requirements of the data to be moved known?
- How will archived data be accessed after the transformation?
- Will data cleansing happen before or during the transformation, and who approves it?
Authorisations
- Is the current role and authorisation structure documented?
- How will roles be structured in the target product, and how will segregation of duties rules be kept?
- Have the permissions of technical and integration users been reviewed?
Operations and support
- Who will run the system after the transformation, and how will monitoring and incident management be set up?
- Has the support team’s readiness for the new product and processes been planned?
- Are changes to the operating model, such as hosting or the split of responsibilities, written down?
Dependencies
- Have compatibility with the target release and support status been confirmed for third-party add-ons?
- Are dependencies in infrastructure, network and security components known?
- Do other projects running in the same period affect the transformation?
Testability
- Are there test scenarios and acceptance criteria for critical processes?
- Does the test data represent real volumes and variety?
- Which processes have automated test coverage, and which do not?
Fallback and business continuity
- At what point during cutover can a decision to fall back be made, and by whom?
- Are the fallback criteria written down in advance?
- How will critical processes continue during the downtime window?
Decision ownership
- Is a decision owner named for each area?
- Who decides when decision owners disagree?
- Where are decisions and their reasons recorded?
How are the installed product, contract scope and technical scope kept apart?
These three are often discussed as if they were the same, but they answer different questions and are confirmed with different evidence. The installed product record shows what is actually in the system, the contract scope shows which products and services the organisation is entitled to use, and the technical scope shows what the transformation will actually cover.
Every mismatch between them is logged as an uncertainty.
| Concept | Question it answers | Typical evidence | Typical owner |
|---|---|---|---|
| Installed product record | Which products, releases and enhancement package levels are in the system? | Release information taken from the system and the landscape list | Technical team |
| Contract scope | Which products and services can the organisation use, and on what terms? | Contracts and licence documents | Procurement and legal |
| Technical scope | Which systems, processes and objects will the transformation cover? | Approved scope document, inventory and interface list | Transformation team and process owners |
For example, a component that is installed but unused can be deliberately left out of the technical scope, while a service outside the contract scope is assessed separately before it is used in the target architecture. That assessment is a decision for the contract owner, not the technical team.
How is maintenance timeline information used with the correct scope?
The maintenance timeline is a planning input for the timing of a transformation; on its own it is neither a reason to transform nor a cause for urgency. Each date should be used together with the product scope it applies to, and confirmed separately against the organisation’s own release and contract position.
This guide includes only information confirmed in two separate official SAP sources [1][2].
| Information | Product scope | Source |
|---|---|---|
| Mainstream maintenance ends on 31 December 2027. | The latest three enhancement packages of SAP Business Suite 7 core applications; the SAP source lists core applications including SAP ERP 6.0 in this scope. | [1] [2] |
| The optional extended maintenance period runs from 1 January 2028 to 31 December 2030. | Same scope. | [1] [2] |
| Extended maintenance comes at an additional fee. | Same scope. | [1] [2] |
| The maintenance commitment extends to 2040. | SAP S/4HANA | [1] [2] |
Points to keep in mind when using this information:
- Whether the scope in the timeline applies to your own system should be confirmed against the installed product and enhancement package level.
- What the SAP S/4HANA commitment means for the release you use should be confirmed separately with release-specific maintenance information.
- The terms of extended maintenance depend on the organisation’s contract with SAP and are outside the scope of this guide.
- The timeline should not decide the transformation on its own. The decision is made together with business goals, technical readiness and the status of the uncertainties in this guide.
How is an uncertainty log kept?
| Field | Description |
|---|---|
| ID | A short, unique record number |
| Area | Product scope, custom code, integration, data, authorisation, operations, dependency, testing, fallback, decision ownership |
| Uncertainty | What is not known, in one sentence |
| Impact | Effect on the plan or decision: high or low, with the reason |
| Resolution route | Which evidence will resolve it, and how easy that is |
| Decision owner | A named role |
| Needed by | The latest date the answer is needed |
| Working assumption | Which assumption the plan follows until the answer arrives |
| Status | Open, being resolved, logged as a risk, closed |
When does an uncertainty count as closed?
An uncertainty closes when the closure criterion set when it was opened is met. Without a criterion written in advance, uncertainties seem to close with time or a meeting decision rather than evidence. The closure record holds the evidence used, its date, who closed it and the effect on the plan; without it, the uncertainty stays open.
The type of evidence depends on the area: a record taken from the system, official product documentation, a test result, written confirmation from the contract owner or add-on provider, or a written decision by the decision owner. An uncertainty can close in three ways: it can be genuinely resolved, it can become a measurable risk and move to the risk log, or the decision owner can knowingly accept it as an assumption. In the third case, the assumption continues to be monitored.
How are uncertainties presented to management?
What goes to management is not the whole log but the part that needs a decision. Instead of a count of open uncertainties per area, the high-impact ones are shown one by one: what is not known, who owns the decision, the latest date an answer is needed, and which assumption the plan follows until then.
For each one, it is also written which part of the plan would be affected if the assumption proves wrong.
Summarising everything in a single risk score can look attractive, but it flattens uncertainties of different kinds onto one scale and hides which decision is being asked for. So the presentation ends with the decisions expected from management: which uncertainty should get resources, which assumption should be accepted, and which decision can wait. Technical detail stays in the log and is opened when needed.
Common wrong assumptions
- “You cannot plan until the uncertainties are resolved.” You can, as long as the assumptions behind the plan are written down and monitored.
- “Technical uncertainties are the technical team’s job.” Many have a decision owner on the business side: data retention, role structure, the downtime window and so on.
- “The maintenance timeline sets the transformation date.” The timeline is an input; it is weighed together with readiness and business goals.
- “Third-party add-ons are compatible.” Compatibility and support status have to be confirmed separately for each add-on.
- “A fallback plan assumes things will go badly.” Fallback criteria define how the decision will be made before anything goes badly.
Checklist
- Questions for each of the ten areas are answered or logged as uncertainties
- Each uncertainty is classified by impact and ease of resolution
- Each uncertainty has a decision owner and a needed-by date
- A closure criterion is written for each uncertainty
- A working assumption is written for high-impact uncertainties
- Installed products, releases and enhancement package levels are on record
- The installed product record, contract scope and technical scope are recorded separately
- Maintenance timeline information is used with its product scope and confirmed at the source
- A custom code inventory and an interface list exist
- Third-party add-on compatibility has been checked
- Test scenarios and acceptance criteria are defined for critical processes
- The fallback decision point and its criteria are written down
Limits of this guide
This guide is a general technical explanation. The maintenance timeline information rests on two separate official SAP sources and applies only to the product scope stated; the sources may be updated over time. The classification method, area questions and uncertainty log are Castintech’s assessment framework and should not be read as SAP’s view. We do not claim any particular transformation duration, cost or outcome.
Frequently asked questions
Can a transformation decision be made before the uncertainties are resolved?
Yes. Decisions are usually made with some uncertainty. What matters is that the assumptions behind the decision are written down, and that it is clear who will confirm each one and by when.
Should the maintenance timeline set the transformation date?
The timeline is an important input but not the only deciding factor. The date is set by weighing business goals, technical readiness, resources and the time needed to resolve high-impact uncertainties together.
Which uncertainty should be handled first?
High-impact uncertainties that are holding up a decision come first. Easy ones are closed straight away; for hard ones, work starts early and they are taken to the decision owner.
Why are third-party add-ons handled separately?
An add-on’s compatibility with the target release and its support status depend on whoever provides it. The transformation team cannot establish this through its own analysis; it has to be confirmed with the add-on provider.
Is a fallback plan needed for every transformation?
In some form, yes. At the very least, the point at which a fallback decision can be made, who makes it and which criteria are used should be written down before cutover.
Related pages and guides
- Assessing a custom code inventory: resolving uncertainties in custom code
- Error handling and safe reprocessing in integrations: uncertainties in interface design
- Extension decisions under a clean core approach: reassessing extensions during a transformation
- Integration approach
- Custom code inventory and technical debt
- All technical guides
Sources
Bracketed numbers in the text refer to the sources below.
- 1
Maintenance 2040 — Innovation Commitment for SAP S/4HANA until 2040 — support.sap.com.
Source date: publication date not stated on the page; announcement date given on the page 4 February 2020 Last verified: 23 September 2026
- 2
Maintenance Timelines for SAP ERP 6.0 (“ECC”) — community.sap.com, blog written by SAP.
Source date: first published 20 September 2022; update date not stated on the page Last verified: 23 September 2026
- 3
Static Code Checks in the Context of an SAP S/4HANA Migration — help.sap.com, ABAP platform documentation.
Source date: document version 2025 FPS01 (February 2026) Last verified: 23 September 2026
Last verified: 23 September 2026
SAP, ABAP, and SAP S/4HANA are the trademarks or registered trademarks of SAP SE or its affiliates in Germany and in other countries.
This content has been independently prepared by Castintech.
Independence note
- Castintech does not claim any partnership, authorization, endorsement or sponsorship relationship with SAP SE.
- SAP and the SAP product names mentioned on this page are trademarks of SAP SE or its affiliates.
- The work Castintech offers is independent technical consulting and support.