Subscribe to GEN
Login to GEN
Red Hat Enterprise Linux carries a great deal of the software businesses cannot afford to stop, and we provide independent engineering support for RHEL estates, from a single certified application server to a fleet managed through Satellite. We do not sell Red Hat subscriptions and have no partnership with Red Hat: your subscription is what entitles your systems to RHEL updates, you keep it, and our support works alongside it.
Service levels run from a next business day response to 30 minutes, 24 hours a day, every day of the year, delivered by our own engineers in the UK. There is no contract, no minimum term and no notice period: you buy hours at our published rates and draw against them.
Most RHEL estates exist for a specific reason. The software they run, an ERP system, a database, an engineering or clinical application, is certified by its vendor on RHEL, and the vendor's own support depends on it. Around that sits a long, published lifecycle, a single accountable supplier, and mature tooling for managing systems at scale: subscription-manager and Satellite for content, Insights for advice, Kickstart and Image Builder for consistent builds, and SELinux enforcing from the first boot. Those are good reasons, and they are why RHEL is still the default choice for a great deal of commercial software.
What a subscription does not provide is an engineer who knows your servers. That is the part we supply. We are not a Red Hat partner and we do not resell subscriptions, so there is nothing for us to upsell and no Red Hat product we are obliged to recommend. The subscription stays yours, with the updates and whatever Red Hat support it includes; we do the work of diagnosing faults, planning upgrades, hardening systems and keeping them patched.
Our own servers run AlmaLinux, from the same enterprise Linux family, so dnf, SELinux, firewalld, systemd and Kickstart are tools our engineers use every day rather than look up.
RHEL faults tend to be precise. The system, the Leapp report or the audit log usually says exactly what is wrong, in a form nobody on site has the time or the background to act on. These are the cases that arrive most often.
A system that has lost its registration after a clone or a rebuild, repositories disabled or pointing at the wrong release, and servers that quietly stopped receiving updates months ago. We sort out subscription-manager and the repositories so every system takes the updates it is entitled to.
A pre-upgrade report full of inhibitors: third party packages, kernel drivers the next release no longer carries, unanswered questions in the answer file, not enough free space. Also the upgrade that stopped partway and left a server in between two releases.
Denials that stop a certified application, contexts lost after data was moved, and install guides that simply say to disable it. We read the denials, then fix the policy with booleans, file contexts or a reviewed local module, and leave SELinux enforcing.
Content views that were never published or promoted, so hosts never see the errata; Capsules out of step with the main server; activation keys nobody understands; and Insights recommendations collected faithfully and never acted on.
A dracut emergency shell after a kernel update, the wrong default kernel in the boot entries, an initramfs without the storage driver, and kdump configured but never tested, so the one crash that mattered left no evidence behind.
NetworkManager and nmcli configuration, bonds, VLANs and bridges, old network-scripts configuration that no longer applies after a major upgrade, and firewalld zones that let through far more, or far less, than anyone intended.
The applications on top, from Apache, nginx and PHP-FPM to MariaDB, PostgreSQL and containers, are covered on our Linux support page. If a system is down now, raise it on the HelpDesk; if you believe it has been compromised, say so, and leave it running.
Upgrades. Leapp moves a server between major releases in place: RHEL 7 to 8, 8 to 9 and 9 to 10, one major version at a time. Done well, it is routine. Done on a Friday afternoon without reading the pre-upgrade report, it is how a server ends up in between two releases. We inventory the server and its third party software, work through every inhibitor and warning, take an image or snapshot, and carry out the upgrade in an agreed window with services, SELinux contexts and networking verified afterwards.
Managed estates. Larger estates usually run through Satellite, and often through Insights too. Both are only as good as the upkeep behind them. We keep content views published and promoted on a schedule the business has agreed, keep Capsules in step, and treat Insights findings as a work list rather than a report.
Hardening. CIS benchmark alignment, SELinux kept in enforcing mode, SSH and sudo policy, firewalld configured to what the server needs, and unused services removed, with the deviations your certified applications genuinely require written down rather than quietly skipped.
Patching and ongoing checks are delivered as a maintenance plan driven by our asset register, with servers watched by Oversight.
Many organisations are reviewing their use of RHEL following changes to how its source is published and to pricing. In 2023 Red Hat changed how RHEL source code is published, making CentOS Stream the public source and restricting RHEL sources to customers. For some organisations that changes nothing at all; for others it has prompted a fair question about whether every server in the estate needs to be RHEL.
We have no subscription to sell you on either side of that decision. We choose our partnerships carefully, and work only with vendors who leave us completely free in what we advise and recommend. For many estates the right answer is to stay on RHEL and support it properly; for others it is AlmaLinux or Rocky Linux; for quite a few it is a mixture. A fair review looks at four things.
We check every application vendor's support statement before anything else. Software certified only on RHEL may well run on AlmaLinux or Rocky Linux, but the vendor may not support it there. Those servers usually stay on RHEL, and the question becomes what else in the estate needs to.
Which parts of the subscription does the organisation rely on: Red Hat's own support cases, Satellite, Insights, or a compliance requirement that names RHEL? An estate that depends on those has more to replace than one that only takes the updates.
Subscription cost set against the real cost of moving: engineering time, testing, change control, and replacing the services the subscription provided. On a large estate the saving can be substantial; on a small one it can take a while to arrive. We put both sides on paper.
dnf, systemd, SELinux, firewalld, most configuration and, generally, application binaries stay as they are. What changes is where updates come from, the Red Hat services attached to the subscription, and the vendor certification status of the software on top.
Staying on RHEL. Maintenance support runs to 2029 for RHEL 8, 2032 for RHEL 9 and 2035 for RHEL 10, released in 2025. We plan Leapp upgrades against those dates and against the software you run, so a major upgrade is a scheduled piece of work rather than an emergency.
Moving to AlmaLinux or Rocky Linux. Where it is the right commercial decision, almalinux-deploy and migrate2rocky convert RHEL to AlmaLinux or Rocky Linux of the same major version in place, without rebuilding the server or reinstalling its applications. Certification is checked before the conversion, not after it.
Converting CentOS to RHEL. The reverse happens too. Where a customer needs RHEL, usually for software certified only on RHEL, Convert2RHEL converts CentOS and some other RHEL-compatible systems to RHEL in place. You buy the subscription from Red Hat or one of its resellers; we carry out the conversion and support the result.
Older unsupported systems are covered on our legacy system support page.
Yes. GEN provide independent 24/7 engineering support for RHEL 8, 9 and 10 across the UK, with service levels from a next business day response to 30 minutes, 24 hours a day, every day of the year. Support is delivered by in-house UK engineers, with no outsourced first line and no contract.
No to both. GEN have no partnership with Red Hat or IBM and do not sell Red Hat subscriptions. GEN are independent engineers who support RHEL systems alongside the subscription the customer already holds.
Yes. The Red Hat subscription is what entitles a system to RHEL updates, and GEN's support does not replace it. Customers keep their subscription, and whatever Red Hat support it includes, and GEN provide the engineering: fault finding, upgrades, hardening and ongoing maintenance.
Yes. Leapp performs in-place major upgrades from RHEL 7 to 8, 8 to 9 and 9 to 10, one major version at a time, so a RHEL 7 server going to RHEL 9 is two upgrades. GEN work through the Leapp pre-upgrade report and resolve every inhibitor before the upgrade window, and the system is imaged or snapshotted first so there is always a way back.
Red Hat's maintenance support for RHEL 8 ends in 2029, for RHEL 9 in 2032, and for RHEL 10, released in 2025, in 2035.
It depends on the estate. The deciding questions are whether the software you run is certified by its vendor only on RHEL, which Red Hat services you actually use, and what a migration would cost against the subscriptions it would save. For many organisations staying on RHEL is the right answer; for others a move, or a mixed estate, is. GEN sell no subscriptions on either side, and will give a straight recommendation.
Yes. The almalinux-deploy and migrate2rocky tools convert RHEL to AlmaLinux or Rocky Linux of the same major version in place, without rebuilding the server or reinstalling its applications. GEN check application vendor certification before the conversion rather than after it.
Yes. Where a customer needs RHEL, for example for software certified only on RHEL, Convert2RHEL converts CentOS and some other RHEL-compatible systems to RHEL in place. The customer buys the RHEL subscription from Red Hat or one of its resellers; GEN carry out and support the conversion.
Our engineers are UK based and in-house, with no offshore outsourcing: the specialist who takes your case is the specialist who works it, and they hold the production experience to match the equipment in front of them. Risk is assessed before anything is changed, the SAPR method is applied to every fault, and five shifts a day mean an overnight handover is a conversation between two engineers rather than a note left in a ticket. Our AI runs on our own hardware in our own data centres, and it never writes a word you read.
There is no support contract, no minimum term and no notice period. You buy hours at our published rates, use them when you need them, and what you do not use carries over. How GEN support works sets all of it out in full.
