Migrating From CentOS to Rocky Linux: Lessons Learned

For many infrastructure teams, the move from CentOS to Rocky Linux began as a response to a change in direction rather than a planned platform refresh. CentOS Linux 8 reached end of life in December 2021, while CentOS 7 followed on 30 June 2024. That left administrators balancing security exposure, application compatibility, and the practical cost of changing systems that had been stable for years.

Rocky Linux offers a familiar Enterprise Linux foundation with long-term support, predictable package management, SELinux, systemd, and broad compatibility with existing automation. The operating system is usually the straightforward part. The difficult work is discovering undocumented assumptions in deployment scripts, monitoring, storage, authentication, and vendor applications.

Australian organisations also need to account for local hosting regions, variable network quality between capital cities and regional sites, privacy obligations, and procurement cycles. A migration that works in a Sydney data centre may need different testing for a Perth office, a Brisbane warehouse, or a remote site dependent on a business-grade NBN connection.

Planning The Migration

The first lesson was to treat the change as a platform migration, not a simple in-place package replacement. A server inventory should record the CentOS release, kernel, enabled repositories, installed packages, running services, storage layout, boot mode, encryption, backup agent, monitoring integrations, and authentication sources.

It is equally important to identify ownership. A forgotten PHP application, an old file transfer service, or a locally modified systemd unit can become the reason a supposedly routine upgrade runs late. Consulting records, architecture diagrams, and market research resources can help place technical decisions within the size and operating realities of smaller Australian businesses.

A clear classification makes sequencing easier. Development systems can validate the migration approach, test systems can expose application problems, and less critical production workloads can confirm operational readiness. Internet-facing services, identity infrastructure, databases, and systems with strict availability requirements should be scheduled only after those earlier stages have produced reliable evidence.

Choosing Rocky Linux

Rocky Linux was attractive because its userland and administration model are close to the Enterprise Linux ecosystem many CentOS teams already understand. Existing knowledge of dnf, RPM packages, SELinux policies, firewalld, systemd units, and common configuration paths remains useful. That reduces retraining and allows existing Ansible or shell automation to be adapted rather than discarded.

Compatibility should still be tested instead of assumed. A package built for an earlier distribution release may depend on an older library, repository, or kernel behaviour. Third-party agents for backup, endpoint security, observability, and hardware management can have their own support matrices. Confirming vendor support before the maintenance window is particularly important when the system supports payment, logistics, or regulated records.

Cloud images and managed hosting options should be reviewed as part of the decision. Rocky Linux images are available through major public cloud marketplaces, but image defaults differ between providers. In Australia, selecting a nearby region such as Sydney or Melbourne can reduce latency and help with data-residency expectations, though it does not by itself satisfy privacy or contractual requirements.

Inventory And Compatibility Testing

An inventory is useful only when it captures behaviour. Record listening ports, scheduled jobs, mounted filesystems, cron entries, sudo rules, service dependencies, certificate locations, and outbound connections. A server may appear to run one application while quietly supporting reporting, backups, monitoring, and a nightly integration with another system.

Build a representative test host from the intended Rocky Linux image and apply configuration through the same automation used in production. Compare package versions, file permissions, environment variables, firewall rules, time synchronisation, DNS resolution, and log output. Testing the actual deployment process reveals errors that a manually prepared virtual machine can hide.

Pay close attention to Python, PHP, Java, and database connectors. An application can start successfully while failing later when it handles a specific character set, TLS negotiation, file upload, or scheduled report. Local testing should include realistic time zones, Australian daylight-saving behaviour where relevant, and integrations with providers whose endpoints may sit outside the country.

Handling Applications And Data

Most migration failures occur above the operating system. Configuration files often contain hard-coded paths, user IDs, library locations, or assumptions about service names. Compare the old and new hosts with checksums and structured configuration reviews, while keeping secrets in a vault or protected deployment system rather than copying them into temporary notes.

Storage deserves its own rehearsal. Validate filesystem labels, mount ordering, UUID references, permissions, quota settings, RAID monitoring, and backup restoration. For database workloads, test both a logical restore and a recovery from the normal backup platform. A successful backup job is not proof that the data can be recovered within the required business timeframe.

For PHP services, confirm the enabled extensions, web-server integration, PHP-FPM pools, upload limits, and opcode caching. For custom F# or other .NET services, verify runtime packages, service accounts, certificates, and native dependencies. A clean operating system provides little value if an application silently loses access to its data directory after the cutover.

Security And Compliance

A fresh Rocky Linux installation should begin with a defined security baseline. Enforce least-privilege access, disable unused services, apply SSH controls, configure firewalld, retain SELinux in enforcing mode where possible, and send useful audit and system logs to a central platform. Avoid solving compatibility problems by permanently disabling security controls.

Australian organisations commonly map technical controls to the Essential Eight, even when they are not formally required to implement every control. Patch management, restricted administrative access, multi-factor authentication, application control, and tested backups provide a practical framework for the migration. The Privacy Act 1988 and the Australian Privacy Principles also make data handling, access, retention, and breach response relevant to infrastructure design.

Security tooling must be tested on Rocky Linux before production deployment. Endpoint agents, vulnerability scanners, backup clients, and monitoring collectors may depend on kernel modules or specific package names. Check their CPU and memory impact as well: a small virtual machine in a Melbourne cloud region can have very different resource constraints from a larger on-premises host in Adelaide.

Cutover And Operations

A low-risk cutover has a written rollback path. Define the final data synchronisation, DNS or load-balancer changes, validation checks, monitoring thresholds, and the point at which rollback is no longer safe. Keep the original CentOS system intact but isolated until the new host has passed the agreed observation period.

Use more than a login test. Check customer transactions, background jobs, scheduled exports, alert delivery, certificate expiry monitoring, backup completion, log ingestion, and access from required networks. When an application serves regional offices, test from those offices rather than relying only on a data-centre administrator’s workstation.

Documentation should be updated during the migration, not months later. Capture the new image source, repository policy, hardening settings, service dependencies, recovery procedure, and ownership. For teams that need broader infrastructure experience, a professional background can also provide useful context when evaluating the operational skills required for platform work.

Practical Migration Priorities

The migration becomes manageable when each server has an explicit owner, a tested build process, and a measurable acceptance checklist. Avoid combining an operating-system change with an unrelated database upgrade, network redesign, or major application release unless there is a compelling reason.

The following priorities kept the work focused:

• Build a complete dependency and service inventory before selecting migration dates.
• Recreate each workload from automation on a clean Rocky Linux test host.
• Confirm vendor support for backup, security, monitoring, and hardware agents.
• Test SELinux, firewall rules, certificates, scheduled jobs, and external integrations.
• Rehearse backup restoration and document the recovery time and data-loss objectives.
• Schedule cutovers around Australian business operations, public holidays, and regional support coverage.
• Retain a tested rollback option until monitoring and user validation show stable performance.

A staged migration also creates useful operational evidence. Track failed deployments, unexpected package dependencies, performance changes, and support incidents. Those records can improve the next batch of servers and reveal whether the chosen image, repository strategy, and automation standards are sustainable.

Rocky Linux is a strong destination for teams leaving CentOS, but the lasting benefit comes from the discipline around the move. Inventory first, test with production-like workloads, preserve security controls, and make recovery part of the acceptance criteria. Start with one representative non-critical service, document what it teaches you, and use those results to guide each subsequent production cutover.