I manage roughly 40 AWS servers across three environments running SAP on SLES 15 SP4. They have not received updates in about three years, and the repository access we were using stopped working around a year and a half ago. SUSE, AWS, and I recommended migrating the workloads to newly provisioned, supported servers, but a developer instead used an AI tool with root access to add openSUSE 15.7 repositories and upgrade packages on one server as a proof of concept. The plan was supposedly to synchronize it back to the official SLES repositories afterward.
That system now has a mixture of openSUSE and SLES packages, and GRUB is not selecting the expected kernels. I may be able to repair the boot configuration and reinstall packages from the proper SLES repositories, but I am more concerned about long-term inconsistencies, hidden dependency problems, and whether this has invalidated support from SUSE, AWS, or SAP. SUSE has already said this is not an officially supported upgrade path.
Is recovering this installation worth attempting, or should it be treated as compromised and replaced? Also, is there a supported way to move from SLES 15 SP4 to a newer service pack that we should have used instead?
5 Answers
Before assuming the repositories are permanently unavailable, verify exactly what subscription and image type you have. SLES for SAP customers may have extended service-pack support and a supported path through later service packs, while a cloud marketplace or pay-as-you-go image can have different licensing and repository rules. Contact SUSE and open a support case, provide the exact subscription and package state, and ask for an approved path. Do not rely on the modified server as evidence that the path works.
For production SAP systems, I would not take this risk. If the vendor will not recognize the upgrade path, you are effectively responsible for diagnosing every future failure yourself. Since these are in the cloud, provisioning clean supported instances and migrating the workloads is usually much safer than spending an unknown amount of time repairing a mixed installation. The extra compute and storage cost is small compared with an outage or an emergency recovery effort.
The package mixing is precisely the kind of situation that makes the system unsupported. The problems may be repairable, but there is no reliable way to know what was changed across libraries, kernels, dependencies, boot files, and package metadata. Every random failure later becomes your problem, and SAP support may require you to reproduce it on a certified software stack before helping.
SLES has documented upgrade paths for a reason. Depending on the starting point and subscription, the correct procedure may involve an offline upgrade using installation media, followed by supported online upgrades between service packs. That is very different from replacing SLES repositories with openSUSE repositories. I would stop experimenting on the proof-of-concept server and obtain a supported recovery or migration plan before touching the production machines.
There are also paid extended-support or third-party patching options that may buy time for a migration, but they should be evaluated against the SAP certification requirements and the actual vulnerabilities exposed by these hosts. Those options are safer than using unrelated distribution repositories, but they do not make the current mixed installation supported. For mission-critical systems, the sensible sequence is to preserve evidence, build clean target servers, test the SAP migration, and keep the damaged server only as a disposable recovery reference.
Older environments can make this especially painful when installation media, subscriptions, or virtualization-specific images are no longer available. Reconstructing a clean system is often easier than trying to recover an undocumented upgrade.