SAP Kernel Upgrade Checklist (Free, PDF/Excel)

0%

0 of 31 items complete

9 critical items still open - these are the highest-risk gaps.

Download checklist:

Planning and compatibility

Record the current kernel release and patch level with disp+work -v or sapcontrol GetVersionInfo, and in SM51 or System Status.CRITICALDefine the reason for the update: security fix, bug fix, or a required minimum for an add-on or support package.Check the SAP Notes and release restrictions for the target kernel with your SAP release, database and operating system.CRITICALConfirm the target kernel is supported on your operating system version and database client library.Schedule downtime or a rolling restart window and get change approval.CRITICALRun the update in sandbox and QA first, with the same kernel archives you will use in production.

Download and staging

Download the kernel archives for the correct operating system and the 64-bit platform from the SAP software download center.Download SAPEXE.SAR, SAPEXEDB.SAR for your database, and the matching DBATOOLS or database library archive.Download the current SAPCAR tool for the platform.Check archive sizes and checksums against the download center before extracting.Extract in a new, empty staging directory using SAPCAR with the manifest, never over the live kernel directory.CRITICAL

Preparation

Back up the existing kernel directory (for example the exe directory under /usr/sap/<SID>/SYS) so you can restore it unchanged.CRITICALTake a database and file system backup, or confirm a valid recent one.Notify users and stop scheduled batch activity that would run in the window.Record instance profile parameters and the list of instances and hosts sharing the kernel.Check free disk space in the kernel directory.

Kernel replacement

Stop the SAP instances in the correct order, application servers first, then central services if required.CRITICALStop the sapstartsrv processes and the host agent if the kernel files are in use.Copy or extract the new kernel files into the kernel directory, keeping owner and group correct.Run the saproot script on Unix and Linux to set the required file permissions and root-owned binaries.CRITICALCheck that sapcpe copies the new files to each instance's executable directory at startup, or copy them manually.Start the SAP system and watch the developer traces and system log during startup.

Verification and handover

Confirm the new kernel release and patch level in disp+work -v and in System, Status.CRITICALCheck that all work processes start and the message server and gateway are available (SM50, SM51).Test dialog logon, a batch job and an RFC call between systems.Run key business transactions and print or output tests.Check the system log (SM21) and short dumps (ST22) for new errors after the update.Document the old and new kernel versions in the change record.

Rollback readiness

Keep the backed-up old kernel directory until the new kernel has run through a full business cycle.CRITICALDocument the exact rollback steps: stop, restore old directory, run saproot, start.Set the decision point and owner for when to roll back instead of troubleshooting.

Do not start the replacement until all critical items in planning, staging and preparation are ticked.

Runbook checks run for you

Optional: see how Basis runbook steps can be verified automatically in your own environment, with human approval on changes.

Optional. The tool and every export work without this. No spam.

How to use the checklist

Use it first in your sandbox or QA system and keep the ticked copy as the runbook for production. The planning and staging groups can be done days ahead. The preparation and replacement groups belong to the change window. Mark the items that do not apply to your platform, for example saproot is for Unix and Linux, and Windows kernels use different handling for services and file locks. Export the final version to PDF or Excel and attach it to the change record, along with the output of the version command before and after the update.

Rehearse in QA with identical archives
Skip platform items that do not apply
Attach before and after version output

How a kernel update works

The SAP kernel is a set of executables and libraries that run the dispatcher, work processes and related services. It is delivered as SAR archives, which are extracted with SAPCAR. Kernel releases are downward compatible within a defined range of SAP releases, which is why you pick the kernel by your SAP release and then the highest patch level your policy allows. Core archives include the main executable set and a database-specific set. After extraction, files are placed in the central kernel directory and, at instance startup, copied to each instance directory by sapcpe. On Unix and Linux, saproot sets up the permissions for programs that need elevated rights.

SAPCAR extracts SAR archives
Database-specific archive must match your database
saproot fixes permissions on Unix and Linux

Verifying the result

Run disp+work -v on the host and compare the kernel release, patch number and compile time against the archive you intended to deploy. Then check the system status screen to confirm the running instance reports the same version. If an instance still shows the old patch, the usual cause is that sapcpe did not refresh its local executable copy or that an application server was missed. Then test a logon, a batch job, a remote function call and a print job. Look at the system log and short dumps over the next days, as some problems appear only under load.

Compare version on every instance
Test logon, batch, RFC and output
Watch SM21 and ST22 for several days

Common mistakes

The common failures are extracting into the live directory and mixing old and new files, forgetting the database-specific archive, skipping saproot so programs lack permissions, and updating one application server but not the others. Another is deleting the old kernel directory straight away, which removes the quickest rollback. Pay attention to the database client library as well: on some databases a newer kernel needs a newer client version. Finally, ignore blanket advice to always use the newest patch; test it, and read the notes for your release first.

Extract to staging, not over the live kernel
Update every instance and host
Keep the old kernel until proven

Frequently Asked Questions

How do I check the current SAP kernel version?

On the host, run disp+work -v or use sapcontrol with the GetVersionInfo function. Inside SAP, open System, then Status, and look at the kernel release and patch level in the SAP system data. SM51 also shows details per instance.

What is SAPCAR and why is it needed?

SAPCAR is SAP's archive tool for SAR files, the format in which kernel and many other SAP components are delivered. You use it to list and extract the archives. Download the current version for your platform and use the manifest option so the signature file is extracted as well.

Do I need to stop SAP to update the kernel?

In most cases yes, because the executables are in use and need replacing. Some landscapes use rolling kernel switches or a kernel switch via the shared directory with brief restarts per instance. Plan according to your high availability design and test the approach first.

How do I roll back a kernel update?

Stop the system, restore the backed-up kernel directory, run saproot again on Unix and Linux, and start the system. This only works if you kept an unchanged copy of the old directory, which is why the backup is a critical item in this checklist.

If you want Basis runbooks like this checked step by step against your own systems, Netray can build agents that run on-prem and ask a human to approve any change.

Talk to an Expert Explore More Free Tools

Related Tools

SAP

More SAP tools

See all

SAP Kernel Upgrade Checklist: Patch and Replace the SAP Kernel Safely