SAP S/4HANA

• New and changed features across the functional and technical areas.
• Simplification items, changes/removals versus ECC to plan for.
• New Fiori apps and analytical capabilities.
• Compatibility (HANA revision, Fiori, Java) requirements.

SAP publishes several kinds of release material and they answer different questions. Knowing which to read saves a great deal of time.

Release notes and what's new describe new and changed functionality for a given release. This is the document to read when you want to know what you could now do that you could not before.

Simplification items are the S/4HANA-specific ones, and they are the important ones for a conversion. Each says that something from ECC has changed, been replaced or been removed, and what has to happen as a result. They are the reason a conversion is a project rather than an upgrade.

Notes on individual corrections are the numbered notes for specific problems and fixes, found through the support portal, and they are what you search when something is behaving wrongly rather than differently.

The distinction worth holding: release notes tell you about opportunity, simplification items tell you about obligation. Reading only the first is how a conversion discovers a mandatory change late.

Simplification items cluster into a few recurring shapes, and recognising them makes the list far less daunting.

Data model changes. Finance consolidated into the Universal Journal, inventory documents into a single table, customers and vendors into Business Partner. These affect every custom report that read the old tables.

Removed or replaced transactions. Something you used has gone or now points somewhere else, and any documentation or training material referencing it is stale.

Functionality moved to a separate product. Capability that was in the core is now licensed or deployed separately, which is a commercial question as much as a technical one.

Mandatory pre-conversion steps. Things that must be cleared before the conversion runs at all, such as open items in a component being replaced.

The readiness check tooling produces this list for a specific system, which is far more useful than reading the generic set, because it tells you which items your system actually triggers. See S/4HANA vs ECC for the wider comparison and the installation page for the deployment side.

An hour, and it is the habit that separates people who keep current from people who find out later.

1. Identify the exact release and support package your system is on, from System then Status and the component list.
2. Open the what's new material for the next release and filter to the areas you work in. Ignore the rest; nobody reads all of it.
3. For each item that touches your area, write one line on whether it is opportunity or obligation. That list is worth more than the document it came from.
4. For a conversion, run or obtain the readiness check output and read the simplification items it flags for your system specifically.
5. Check whether anything you rely on appears in a deprecation. That is the item that becomes urgent two releases later.

For S/4HANA, track feature releases to adopt new capability, and, crucially, review simplification items when converting from ECC (they tell you what changes or is removed). Cloud editions update frequently, so staying aware of release notes is an ongoing discipline, not a one-off.

The cadence matters too. Cloud editions release on a fixed schedule whether or not you are ready, so reading the notes each cycle is routine work rather than project work. On-premise moves when you decide, which means the notes accumulate and a skipped release is a larger read later. See HANA release notes and ECC release notes for the neighbouring streams.

For a conversion, the functional simplification items get the attention and the custom code usually takes the time.

The problem is specific. Custom programs were written against tables that no longer exist in the same form. Anything reading the old finance line item tables, the old inventory document tables, or the customer and vendor masters directly has to be reviewed. Reads through standard interfaces mostly survive; direct table access mostly does not.

SAP provides tooling for this. A custom code analysis compares your objects against the simplification database and produces a findings list. It is a starting point rather than an answer, because it reports where the code touches something changed, not whether the result is wrong.

The step people skip is deciding what to keep. Most landscapes carry custom programs nobody has run in years, and every one carried across is one to remediate, test and then maintain. Usage data, from the workload statistics, tells you which objects were actually executed in the last year, and that list is usually a fraction of the total. Deleting the rest is the cheapest remediation available.

Then clean core shapes what replaces it. New extensions built on the platform or through released APIs rather than inside the core survive the next upgrade, which is the whole argument. Rebuilding an old modification as a new modification solves this conversion and buys the same problem again.

Budget for this properly. On landscapes with a long history it is routinely the largest single workstream in the conversion.

Knowing which source answers which question saves a great deal of searching.

The help portal carries the product documentation and the what's new material for each release, organised by product and version. This is where you go to learn what a release added.

The support portal carries the numbered notes: specific corrections, known problems and their fixes. You search here when something is behaving wrongly, usually with the error message itself.

The readiness check is run against a specific system and produces the simplification items, custom code findings and sizing information that apply to it. This is the one that matters for a conversion, because it filters the generic list down to your reality.

The roadmap shows what is planned rather than what has shipped, and it is directional rather than a commitment.

Access differs. Documentation is public; much of the support portal and the readiness tooling requires a customer or partner login, which is worth knowing before promising somebody a report you cannot produce.

• Upgrading without reading the notes.
• Ignoring deprecations.
• Missing compatibility requirements.

• Reading the marketing summary instead of the simplification list. One tells you what is exciting, the other tells you what will break.
• Assuming custom code is unaffected because the transaction still exists. The table underneath it may not.
• Treating deprecation as a distant problem. It is the notice period, and it is the cheapest time to act.

• Reading the notes only at conversion time. Three years of accumulated change read in one sitting is how a project discovers a mandatory item late, and the notes were available all along.

Reading the notes is the habit, and planning a conversion around the simplification items that apply to a specific system is the part you do in the course.

The habit is small and it compounds: each release, read the notes for your area only, and write one line per item saying whether it is opportunity or obligation. Ten minutes a cycle keeps you ahead of a conversion instead of catching up during one.