Migrate Amazon Linux 2 to RLC Pro: Free toolkit and 60-day plan

Amazon Linux 2 reaches end of life on June 30, 2026. A significant portion of AWS Linux customers are still running AL2. If your organization is among them, you have enough time to migrate properly. You do not have enough time to plan slowly.

CIQ has published a free, open-source migration toolkit at portal.ciq.dev/migrate2rlc. Run al2-inventory.sh on each AL2 instance to capture system state as JSON, then feed it to al2-rocky9-compat.py to classify every finding and output the exact commands to run on Rocky Linux 9. This post gives you the 60-day migration plan that follows that assessment.

What has already stopped, and what stops June 30

The AL2 support timeline has been reducing AL2 support coverage since 2025. June 30 is the planned end.

Organizations that still run kernel 4.14 on any AL2 instance accumulate unpatched CVEs with no fix path short of upgrading to kernel 5.10. Live patching and standard security patching for kernel 4.14 both ended October 31, 2025. AWS continues live patching kernel 5.10 until the EOL date, so upgrading to 5.10 extends your covered window to June 30. There is no AL2 AMI for 1.33+.

For the rest of your EC2 fleet (application servers, batch workloads, build systems, and database hosts), RLC Pro, CIQ's commercial Rocky Linux subscription, is the migration target for workloads that need Enterprise Linux binary compatibility, commercial support, FIPS 140-3 validation, and a defined long-term lifecycle.

Why RLC Pro fits many workloads AL2 was running

RLC Pro is available on the AWS Marketplace with the AWS toolchain pre-installed. Rocky Linux 9 is freely available as a community project. RLC Pro adds the production layer: long-term support, committed CVE timelines, FIPS 140-3 validation, security SLAs, and indemnification.

RLC Pro carries a 10-year support lifecycle on RLC Pro 9 with security maintenance through May 2032.

For most EC2 fleet migrations, going directly to RLC Pro 9 avoids the added technical debt and complexity of a two-hop upgrade path through Rocky Linux 8. For workloads with the deepest AL2 compatibility dependencies, those with heavy extras gaps, custom kernel modules, or substantial Python 2.7 automation, Rocky Linux 8 is a viable intermediate target, with standard support through May 2029.

For workloads with hardening or compliance requirements, RLC Pro Hardened adds LKRG-based intrusion detection, SBOM-validated packages, and expedited CVE patching.

---

Ready to start your migration assessment? Talk to CIQ about migrating your AL2 fleet

---

Four phases that get you to complete migration before the deadline

The plan below assumes EC2 application workloads managed with Ansible. Preserve the sequence: audit before build, build before test, test before cutover.

Phase 1 (days 1–15): dependency audit

Start with a complete inventory of every AL2 instance before touching a single AMI. The following two commands run the CIQ migration toolkit.

# Step 1: Capture system state on the AL2 instance
INSTANCE_ID=$(curl -s http://instance-data/latest/meta-data/instance-id)
bash al2-inventory.sh > inventory-${INSTANCE_ID}.json

# Step 2: Classify every finding and get exact remediation commands
python3 al2-rocky9-compat.py inventory-${INSTANCE_ID}.json

The classifier assigns every finding to one of four tiers: direct install, module swap, alternative source, or manual rewrite. If you have CIQ support, REWRITE-tier findings can automatically escalate to CIQ.

If the toolkit isn't feasible, run the rpm inventory manually and capture extras separately; rpm doesn't track which packages originated from extras topics:

INSTANCE_ID=$(curl -s http://instance-data/latest/meta-data/instance-id)
rpm -qa --qf "%{NAME}|%{VERSION}|%{RELEASE}|%{ARCH}\n" > package-inventory-${INSTANCE_ID}.txt
amazon-linux-extras list | grep enabled

Flag four categories across every instance: packages from amazon-linux-extras, any python or python2 references in cron jobs or init scripts, custom kernel modules, and hardcoded AMI IDs in Terraform or CloudFormation.

Phase 2 (days 16–30): image selection and base AMI preparation

Subscribe to RLC Pro on the AWS Marketplace. The RLC Pro 9.6 LTS listing from CIQ is available in 17 regions, with repositories frozen at RLC Pro 9.6 LTS and security backports through December 2029:

• x86_64: prodview-qhgh2skycofoo
• arm64 (Graviton): prodview-2detaaoenjcsc

Build a base AMI from the Marketplace image with your organization's standard configuration baked in: your VPC DNS resolver settings and any IAM instance profile prerequisites. Application-specific packages go in phase 3. Confirm your existing instance profiles grant ssmmessages, ec2messages, and ssm:*; no policy changes are required for most standard configurations.

Phase 3 (days 31–45): playbook adaptation and testing

AL2 workloads managed with Ansible almost always use the yum module. Rocky Linux uses dnf. In Ansible 2.9+, explicit ansible.builtin.yum calls in older playbooks need updating:

# Before (AL2)
- name: Install application dependencies
  ansible.builtin.yum:
    name: "{{ item }}"
    state: present
  loop: "{{ al2_packages }}"

# After (Rocky Linux 9)
- name: Install application dependencies
  ansible.builtin.dnf:
    name: "{{ item }}"
    state: present
  loop: "{{ rocky_packages }}"

For extras packages with AppStream counterparts, the installation method changes. The example below shows PHP; AppStream module streams are standard Rocky Linux package management, not a CIQ-specific feature. For workloads with complex module dependency requirements, CIQ support can assist with mapping:

# AL2
amazon-linux-extras enable php8.1 && yum install php

# Rocky Linux 9
dnf module enable php:8.1 && dnf install php

After adapting playbooks, run them against a non-production EC2 instance launched from your phase 2 base AMI. Treat any role failure as a blocking issue before phase 4 begins.

Phase 4 (days 46–60): staged cutover

Run a blue/green cutover per workload tier: launch RLC Pro instances from your validated AMI, run Ansible to full application state, route a percentage of traffic via ALB target group weighting or Route 53 weighted records, and monitor CloudWatch metrics for 24–48 hours before completing the shift. Tag AL2 AMI snapshots with a 30-day retention date.

Aim to reach zero AL2 instances by June 15, 2026. Two weeks before the EOL date is the right buffer: post-cutover issues should surface and get resolved before the deadline.

Five compatibility issues to catch before they catch you

1. Python 2.7 references in automation. RLC Pro 9 defaults to Python 3.9; Python 2.7 is not in the standard repositories. Any script or cron job calling python (not python3) will fail. Audit every /etc/cron.* directory, startup scripts, and Ansible roles that invoke Python directly.

2. amazon-linux-extras package gaps. PHP (versions 8.1 and 8.2 available via AppStream module streams) and nginx have Rocky Linux 9 counterparts; postgresql and redis have counterparts at differing versions. Everything else, including MariaDB and most LAMP stack components, requires EPEL, a vendor repository, or manual compilation. Missing this mapping is the most common reason playbooks fail in testing.

3. Custom kernel modules. Modules compiled against AL2's kernel will not load on Rocky Linux 9 without recompilation. Teams running custom eBPF programs, network filter modules, or third-party storage drivers need to source new builds. This is the highest-risk item in the dependency audit.

4. yum group install syntax differences. dnf handles package group installs differently. Playbooks using yum groupinstall "Development Tools" need rewriting as dnf group install "Development Tools". Module stream enablement (dnf module enable) has no yum equivalent and must be added explicitly.

5. AWS agent installation paths. The RLC Pro 9.6 LTS Marketplace AMI ships with SSM Agent and CloudWatch Agent pre-staged. This item applies if your Ansible playbooks install agents explicitly — those roles need updating to use the native RPM endpoint rather than AL2-specific sources:

sudo dnf install -y \
  https://s3.amazonaws.com/ec2-downloads-windows/SSMAgent/latest/linux_amd64/amazon-ssm-agent.rpm
sudo systemctl enable amazon-ssm-agent --now

How to cut over without burning your rollback option

Your rollback artifact is the AL2 AMI snapshot taken at the start of phase 4. If an RLC Pro instance fails validation under production traffic, shift ALB or Route 53 weights back to the AL2 target group (traffic recovery in under two minutes) and leave the failed instances up until you've extracted logs.

Do not terminate failed instances before diagnosing. The logs are your diagnostic data.

The rollback window is for failed migrations. Every day an AL2 instance runs in production past June 30 is a day your organization accepts unpatched CVE exposure with no vendor fix path.

Start the assessment this week

In CIQ's experience with enterprise migrations, schedule risk accumulates in the dependency audit: either teams spend too long there, or they skip it and surface blocking issues during testing. Start with the free toolkit at portal.ciq.dev/migrate2rlc. If you want CIQ's team to assess your fleet directly, reach out before you start.

Use the free AL2 migration toolkit | Contact Us

AL2 EOL date (June 30, 2026) confirmed per AWS Amazon Linux 2 FAQs. EKS AL2 AMI end of support (November 26, 2025) confirmed per Amazon EKS documentation. Kernel 4.14 live patching end date confirmed per AL2 kernel live patching documentation. RLC Pro 9.6 LTS performance benchmarks from CIQ internal testing on EC2 m6i.xlarge hardware, March 2026; full methodology and results will be published at github.com/ctrliq/al2-migration. RLC Pro Hardened availability on AWS Marketplace confirmed at aws.amazon.com/marketplace. Rocky Linux 9 support lifecycle (through May 2032) confirmed per Rocky Linux release documentation.