When you migrate to RLC Pro, your lifecycle workflow moves onto CIQ Enterprise Linux Manager (ELM). ELM gives migrated hosts a local mirror, curated content views, rollback to earlier versions, and network provisioning for the machines you build next.
With ELM, the tooling side of your migration is predictable: your admins keep the content-view model they already use, one control plane covers every step from mirror to new machine, and the same setup serves every source distribution.
Moving the operating system and moving the lifecycle workflow are separate workstreams, and ELM gives the second one a destination before the first one starts.
Plan the tooling as its own workstream, next to the OS conversion
For RHEL, Oracle Linux, and CentOS-family sources, CIQ's migrate2rlc script converts each host to RLC Pro within the same major version. That conversion changes what runs on the host. Three questions sit outside it: where your hosts pull packages from afterward, which content each group of hosts may install, and how your team builds a replacement machine.
Those three questions belong to the lifecycle layer, and ELM answers each of them for an RLC Pro fleet. Put that layer in your migration plan from the first week.
Rebuild the lifecycle layer on your infrastructure in three steps
ELM runs in containers in your environment. Standing it up follows the same order the content travels: mirror it, curate it, then deliver it to hosts.
Step 1: Mirror your content into one local store. ELM pulls RLC Pro content from CIQ Depot with your Portal credentials, and adds EPEL, your custom repositories, an rsync mirror, or an uploaded ISO alongside it. Each sync verifies packages against the repository metadata and stores every file once.
Step 2: Curate content views and decide what reaches production. A content view pins or excludes packages and versions, accepts your custom RPMs, and records an immutable version every time it composes. Because ELM hard-links packages instead of copying them, a view composes in seconds. ELM checks dependencies when a view composes and flags conflicts as warnings before rollout, and rollback re-points a view to a version it already published. To promote, you compose a production view from a development view your team has already approved.
A pinned content view keeps production exactly where you left it until your team promotes the next version.
Step 3: Deliver content to hosts and build new machines. Hosts register through a lightweight agent and join nested host groups. Each group receives the content views assigned to it, and every host consumes its view as a standard dnf repository. New machines install over the network through iPXE, DHCP, and TFTP, with templated kickstarts, an encrypted credentials vault, and Secure Boot support.
Keep the workflow your admins already run
If your admins work in content views today, they keep that vocabulary on ELM: content views, immutable versions, pins, promotion, and rollback. The migration goes into rebuilding definitions on a model your team already knows.
Four things to know about how ELM runs:
- Access control connects to your directory. Role-based access control works with local accounts, LDAP, or SAML, and ELM keeps an audit log.
- Lifecycle operations are scriptable. ELM exposes a REST API for your scripts, and it launches Ascender automation against the hosts you select.
- Entitlement resolves at the mirror. Your RLC Pro subscription authenticates against CIQ Depot when ELM syncs, and hosts install from the local mirror. ELM runs no subscription-enforcement service, sends no telemetry, and makes no license callback.
- Disconnected sites get the same workflow. ELM runs air-gapped when your environment requires it, with content brought in from a local ISO image.
Your team recreates repositories, content views, and host groups in ELM, content doesn't migrate on its own, and both platforms can run side by side until the last host group moves. The four-phase plan for moving a content-view workflow to ELM shows how to sequence that overlap.
| Migration with CIQ Enterprise Linux Manager | |
|---|---|
| Where do migrated hosts get packages? | A local mirror of CIQ Depot, EPEL, custom repositories, rsync mirrors, or ISO images |
| How do we control what reaches production? | Content views with pin and exclude rules, promoted from an approved development view |
| What if an update breaks something? | Roll back to an earlier immutable content-view version |
| How do we build new hosts? | Network installs through iPXE, DHCP, and TFTP with templated kickstarts |
| Who can change what? | Role-based access control with LDAP or SAML, plus an audit log |
| How do we automate it? | A REST API, plus Ascender automation launched against selected hosts |
Get the same tooling answer from any starting distribution
Whichever distribution you start from, your fleet lands on RLC Pro, and ELM manages content and provisioning for the hosts that arrive.
RHEL, Oracle Linux, and CentOS-family environments share Enterprise Linux binary compatibility with RLC Pro, so many applications carry over with little to no change and migrate2rlc handles the host conversion. SUSE and Amazon Linux 2 come from a different lineage, so the move involves more than a host conversion, and CIQ's migration engineers scope that work with you. Find your starting point for a move to RLC Pro walks through each path.
Start your Enterprise Linux Manager migration with one host group
ELM is available with all RLC Pro subscriptions at no additional cost.
Start small. Stand ELM up next to your current tooling, mirror your content, and build the content views for a single non-production stage. Then move one host group, run a full cycle of compose, promote, and rollback, and expand group by group on your calendar.
Ready to scope your migration? Plan it with CIQ's migration team.
