I've been involved with two upgrades so far. They were challenging.There were a lot of teams involved. There needed to be a lot of migration planning.

RHEL requires some housekeeping. We have to restart and patch servers weekly or biweekly and check the CPU, memory size, file size, the database used, and whether the IP network protocols are defined. All this happens monthly, weekly, or fortnightly.

We have to apply patches weekly, monthly, or quarterly, depending on their purpose.

Patching Red Hat Enterprise Linux in our environment is a straightforward process that utilizes Red Hat Satellite.

Upgrading Red Hat Enterprise Linux is a straightforward process that involves running a single command to update and patch all packages. However, syncing the repository to the new one is a manual step. Despite this, I haven't encountered any issues.

The cloud migration from Red Hat Enterprise Linux Seven to Eight was straightforward due to the absence of underlying infrastructure complexities.

Upgrades or migrations are pretty straightforward and not complex, according to our experience.

We will be involved with some Red Hat Enterprise Linux upgrades or migrations to other cloud platforms. It's not straightforward in my opinion; we have to create an image from Red Hat Virtualization Manager and convert the image to a format that can be recognized by other platforms, such as Microsoft Azure. We have to convert the image and then import it to the Azure cloud. It's not easy, as it requires manual work. There's no tool available for this process.

I have been involved in Red Hat Enterprise Linux (RHEL) upgrades and migrations. We upgraded from version seven to nine recently, first from seven to eight, then to nine. Security requirements were a consideration when we were choosing Red Hat Enterprise Linux (RHEL) in the cloud.

I have been involved in Red Hat Enterprise Linux (RHEL) upgrades and migrations. We upgraded from version seven to nine recently, first from seven to eight, then to nine.

I have been involved in Red Hat Enterprise Linux (RHEL) upgrades and migrations in my company, and it depends on what your approach is, however, we don't do in-place upgrades, as they're just dangerous, no matter what anybody says. I always say a fresh install is always the best thing, so for us, it's a matter of leveraging Kickstart and Packer to generate the VM images or Kickstart to generate ISOs and install them on physicals. It's just a matter of taking and being able to easily set it up for repeatability, although it takes probably more time than I would prefer to get that consistency.

I have been involved in updates for Red Hat Enterprise Linux (RHEL), going from version eight to nine. I typically just deploy the next version and migrate whatever application or system may be to that instead of jumping to another version.

I have been involved in upgrades or migrations for Red Hat Enterprise Linux (RHEL), specifically for RHEL 7.

When upgrading from RHEL 8 to RHEL 9, we encountered some issues and had to use a leap utility for jumping between releases. Once we found the documentation, the process was straightforward.

We are deploying Red Hat Enterprise Linux (RHEL) on-premises. I have been involved in many Red Hat Enterprise Linux (RHEL) upgrades or migrations to on-premises, and it is straightforward. The documentation and how-to guides make it very simple.

We are in the process of migrating to Red Hat from various other operating systems such as AIX, IBM workloads, to Red Hat. The transition is straightforward. The documentation is great. It's accurate. If you have a Red Hat account, you have access to knowledge articles. We're on the cloud and on-prem.

I have been involved in upgrades or migrations of Red Hat Enterprise Linux (RHEL) for 20 years. The process of migration just works.

I am involved in Red Hat Enterprise Linux (RHEL) upgrades all the time; we are currently in the process of upgrading from Red Hat 8 to 9 for all of our environments. Upgrading Red Hat Enterprise Linux (RHEL) has its challenges; we had a couple of hiccups in a couple of cases. Overall, about 95% of the use cases have been issue-free, with just 5% of cases occasionally encountering problems.

In terms of deployment, it's been good standing it up and then maintaining it with patching through Satellite. Upgrades have been not time-impacted. They're pretty quick to get patching done. Everything is pretty easy. Migrations aren't too complicated.

I have been involved in RHEL upgrades and migrations in general. The process typically involves rebuilding and migrating; we rebuild the OS and migrate. We have tried the upgrade-in-place method, but it can be very lengthy and has more room for errors. Generally, we build new and migrate over first, and if we can't do that, we'll do the upgrade-in-place for applications that people understand, really just needing the same setup as before.

I have been involved in migrations or upgrades of RHEL, and I just completed a leap upgrade from RHEL 7 to RHEL 8.

I have been involved in upgrades or migrations of Red Hat Enterprise Linux (RHEL), especially during the significant shift from RHEL 7 to 8, which included many upgrades and migrations.

Our upgrade or migration plans to stay current with Red Hat Enterprise Linux (RHEL) involve adhering to a rule: once a version reaches end-of-life, we do not enter the extended life cycle. We plan that out ahead, ensuring that all of our systems get migrated and updated about a year before the end of life of any version. Some systems get migrated to the latest version while others remain and just get updated to whatever is current.

I have been involved in the upgrade of Red Hat Enterprise Linux (RHEL) as we upgraded from 8 to 9 a couple years ago.

I have been involved in Red Hat Enterprise Linux (RHEL) migrations and upgrades. I would describe the experience of RHEL migrations as challenging since it's not an easy task to migrate thousands of machines in one major release window.

I have been involved with upgrading from Red Hat Enterprise Linux (RHEL) 8 to RHEL 9, and from RHEL 7 to RHEL 8 because RHEL 7 has been sunsetted. In these cases, we build net new rather than doing in-place upgrades. For upgrades, we use satellite to deploy, and AAP for our host provisioning and whatever we need to layer on top of the infrastructure.

Our recent hurdle was getting off of CentOS, but the scalability hasn't been an issue for us. It's been smooth sailing, just requiring the bulk work of migrating thousands of servers.

I'm not entirely sure at the moment about Red Hat Enterprise Linux (RHEL) upgrade or migration plans for what's ahead of us. We're just looking into the short term right now.

Deployments or migrations are quite easy for us since we have been working with Red Hat Enterprise Linux (RHEL) for the last five or six years. It feels like a piece of cake. Whether it's a minor or major version update or a migration, we don’t face any significant challenges. The process is smooth. Initially, it took us two days to spin up a VM with all the requirements when on-prem. Now, the code is in GitLab. We have set up a code to build the servers, so after submitting a request in ServiceNow, it can be ready the next day. It is all automated. It was on-prem, but last year, all of the servers were migrated to GCP. There isn't much difference whether it's on-prem or on cloud, because the patching mechanism we follow through the Satellite system remains the same.

I have been working with Red Hat Enterprise Linux (RHEL) for 16 to 17 years. The upgrades and materials have been consistently good.

I have not been involved in any upgrade or migration recently. What we have done typically is spawn a new instance. Instead of upgrading an existing instance, we literally throw that one away, spin a new instance as needed, then throw the old one away. It is similar to the container model now, but it is the same for the operating systems, the way we look at it, as everything is automated. It is very easy just to throw it away and create new instances.

We are involved in upgrading RHEL 7 because it has reached end of life; sometimes we upgrade to eight or nine.

I have been involved in Red Hat Enterprise Linux (RHEL) upgrades and migrations from on-premises to the cloud. The migration process was straightforward without any difficulties. We performed both hot migration and cold migration successfully.

We'll be migrating more to RHEL 10. Some in our environment are still in RHEL 7.

Currently, we are doing upgrades from RHEL 7 to 9 and 7 to 8, but not directly.

For upgrade or migration plans to stay current, we're using the automated LEAP process for migrating from a lower version to the latest version.

I've participated in upgrades from version 6 to 7, 7 to 8, and 8 to 9. The only issues we encountered were related to the Samba file-sharing system, where we had to uninstall and reinstall it instead of migrating directly. This was frustrating because we expected everything to be backwards compatible. Additionally, we faced challenges when upgrading from version 6; we couldn't jump directly to version 9 and had to go through intermediate versions, which was a pain point for us. We wish we could upgrade from version 6 to 9 directly instead of having to go from 6 to 7, then 7 to 8, and finally 8 to 9.

The upgrade and migration process in AWS is straightforward - I can easily increase the number of processors through hot migration, which can be done while the system is running without requiring shutdown.

I have been involved in RHEL upgrades or migrations from many years ago, approximately 14 to 18 years back. Currently, everything is easier as upgrades and patches come as a package. Regarding built-in security features, maintaining compliance is handled at the architect's level during configuration setups. While the service provider handles access level security, configuration compliances need to be managed by the architect. The upgrade and migration process in AWS is straightforward - I can easily increase the number of processors through hot migration, which can be done while the system is running without requiring shutdown.

I have been involved in Red Hat Enterprise Linux (RHEL) upgrades or migrations, and due to our many internal dependencies, it takes time, however, we successfully completed it.