A team running Red Hat Satellite today already works in content views, promotion, and rollback. That workflow moves to CIQ Enterprise Linux Manager (ELM) unchanged. Content views are still content views. Publish produces an immutable version, promotion moves that version through staged environments, and rollback returns a host group to a version that shipped earlier.
The work of a migration is in rebuilding your definitions. The content-view workflow your admins already run transfers to ELM.
Every RLC Pro subscription includes ELM at no additional charge, and it runs entirely on the infrastructure you already control.
Give your admins a console they recognize on sight
Six parts of the lifecycle workflow carry over into the ELM console.
| Concept | What it does in ELM |
|---|---|
| Mirror | A local copy of CIQ Depot, your own repositories, and open repositories like Extra Packages for Enterprise Linux (EPEL), synced onto your storage. |
| Content view | A named fork of product, version, and repository combinations, with packages added, removed, or held back. |
| Content view version | The immutable snapshot that a publish produces. ELM signs each view at curation. |
| Promotion stage | The versioned environment a view runs in: development, test, and production |
| Rollback | Previous versions stay intact, so a rollback re-points rather than rebuilds. |
| Host group | The set of hosts pointed at a content view version, which installs through standard package management. |
These objects connect in the same sequence as your current platform: a mirror feeds a content view, promotion moves a published version into a stage, and the host groups pointed at that version perform the install. A view advances one stage at a time.
Rebuild the definitions once, then run your normal week
Migration work is rebuilding the definitions. Your team recreates repositories, content views, and host groups in ELM against the same definitions you already run. Content does not move automatically.
You need to plan the work around the rebuild: re-pointing hosts, porting automation written against your current platform's interfaces, and running both platforms through the overlap.
Once a host group's definitions are rebuilt, its week looks like the week before. Sync the mirror, fork a view from the one production runs, curate, publish, and promote.
Four changes
Package data is deduplicated across every view. A new version points at package files already stored on disk instead of duplicating them. Composing one takes seconds, no matter how large the repository.
Conflicts surface during curation. Dependency resolution flags them while the view is still a draft, before it reaches a host.
Entitlement resolves once, at the mirror. Depot, the CIQ service your subscription authenticates against, governs which repositories you can mirror. Hosts then pull from your own infrastructure, with no separate entitlement service to install, register hosts against, or keep in sync.
The control plane answers to your team. ELM runs inside your environment, sends no telemetry, and makes no license callback. Curation and deployment run fully air-gapped when required, with content brought in from a local ISO image.
Running the control plane and owning the mirror storage isn't new. Your platform team already carries both for Satellite today, and nothing about that changes on ELM.
See what ELM does: mirror, curate, stage, promote, and roll back.
Move to ELM in four phases while production stays steady
Phase one: inventory what the fleet consumes. Export your current content view definitions, the repository sets behind them, and the host group bindings, then check install history per view. Inventory exports often surface views that no host has installed from in months. Those come off the rebuild list.
Scope one boundary into that same inventory: mirroring covers any RPM-based distribution, but curation, dependency resolution, and errata target Enterprise Linux content only. Teams running a mixed estate map their non-EL segments against that line during this phase.
Phase two: stand ELM up alongside and rebuild one stage. Sync the mirror, recreate the repository set, and fork the content views for a single non-production stage. Every host keeps installing from its current source through this phase. The API drives mirror, curate, and promote operations from a script or a CI pipeline, so a platform team rebuilds from the definitions exported in phase one rather than by hand.
Phase three: move one host group and prove the round trip. Pick a host group you can afford to move twice. Point it at a production stage in ELM and run a full cycle: sync, curate, publish, promote, then deliberately roll back once so the team sees the rollback path work before a real incident forces it. Those hosts pick up their content view through an optional lightweight ELM agent, or through a repository config your existing Ansible playbooks hand out.
Phase four: migrate group by group on your own calendar. Each group moves when its owners are ready, and a group that slips holds only its own schedule.
Phases two and three leave both platforms running, so carry the parallel-run cost in the plan for as long as the overlap lasts.
Because host groups move independently, each cutover window covers one group rather than the fleet. Shared setup (the initial mirror sync and the iPXE network-boot configuration for new hosts) happens once, ahead of the first move.
After the last group moves, set your own upgrade calendar
A team on ELM decides which content enters the fleet and when each stage moves. Fleet control comes bundled with the RLC Pro subscription you already pay for, on the storage your team already provides.
Planning your move? Contact Us
