We have around 40 AWS servers running SAP across three environments on SLES 15 SP4. They have not received updates for roughly three years, and the repository access we were using was closed about 18 months ago. I recommended building new supported servers and migrating the workloads, but a developer instead used an AI tool with root access to add openSUSE 15.7 repositories and update one server as a proof of concept. The plan was to eventually replace the openSUSE packages with official SLES packages.
The test server now has mixed SLES and openSUSE packages, and GRUB is selecting the wrong kernels. Although I may be able to repair the boot configuration and reinstall packages from SLES repositories, I am concerned about less obvious long-term problems, SAP compatibility, and whether this has invalidated our SUSE or AWS support agreements. SUSE has already said this is not an officially supported upgrade path.
Am I right to consider this approach unsafe, and what should we do to return to a stable, supportable configuration?
5 Answers
The upgrade diagrams and supported service-pack paths exist for a reason. Depending on your subscription, an offline upgrade using the proper SLES media may be required before continuing with online upgrades. Do not treat a repository swap as an operating-system upgrade. Make a tested recovery plan, involve SUSE and SAP, and restore the test machine from a known-good image if possible.
Before assuming SP4 has no supported options, verify exactly what license and repository source you have. SLES for SAP customers may still have extended support or a supported path through later service packs, while an AWS pay-as-you-go image can have different entitlement and portability rules. Open a support case and ask for an explicit upgrade and licensing path rather than relying on the repository currently being reachable.
If a full migration cannot happen immediately, compare the cost of SUSE extended support or another properly contracted security-maintenance option with the migration project. First inventory the actual versions, exposed services, SAP dependencies, and critical vulnerabilities. That may provide a short-term bridge, but it should not be used to justify keeping a mixed openSUSE/SLES installation as the long-term platform.
Even if the server can be made to boot and all packages can be replaced, it may still be outside support because its package history and configuration have already diverged. SAP certification and vendor troubleshooting can depend on the exact kernel, glibc, libraries, and package set. Treat the modified host as disposable: capture what you need for investigation, then rebuild or migrate to a clean, supported installation.
For production SAP systems, I would not accept this risk. Mixing openSUSE and SLES packages can create subtle dependency, kernel, library, and service issues that may not appear until a failure or later update. If the vendor will not support the resulting system, your team owns every failure mode. Since these are in AWS, building clean replacement instances and migrating the workloads is usually safer than trying to repair a modified operating system.
That is my concern as well. A server that happens to work today is not the same as one that a vendor can support during a production incident, so I am pushing for a supported rebuild or an explicit vendor-approved recovery plan.