Skip to content

The four Ms of data loss — and how to recover with confidence

If you’re responsible for your organization’s data — whether in IT, security, compliance, or ops — there’s a good chance you’ve already dealt with some form of data loss. If not, odds are you will. The key is understanding how those losses happen and how to recover. 

In my experience, most incidents fall into one of four categories — I call them the four Ms: Malicious attacks, mistakes by admins, mishaps at your cloud provider, and migrations gone bad. 

Let’s take a look at each. Along the way, I’ll share real examples, the patterns I’ve seen over and over again, and what you can do to make sure you’re ready when (not if) something goes wrong. 

 

Malicious attacks: You will be targeted 

Let’s start with the one everyone knows: cyberattacks. You’ve seen the headlines — ransomware, data-wipes, stolen credentials, you name it. But what doesn’t always make the news is how modern attacks are increasingly hybrid and decreasingly targeted. 

We’re no longer dealing with isolated ransomware gangs. Today’s attacks are more coordinated, more hybrid, and less targeted than ever. Nation-state actors like MERCURY (now Mango Sandstorm) and DEV-1084 (now Storm-1084) have proven they can compromise on-prem environments, escalate privileges, and then pivot into cloud systems like Azure — where they delete Azure-based backups and try to erase the recovery path itself. That’s right: They don’t just go after your data, they go after your recovery plan. 

These aren’t theoretical. Microsoft’s Threat Intelligence blog and others have published chilling case studies on how hybrid attackers operate — and how hard they are to stop once inside. 

Attacks also don’t need to be that sophisticated to be devastating. Many start with a user doing something they shouldn’t — clicking a phishing link or exposing credentials. It’s not intentional, but it’s all an attacker needs to get in, elevate access, and start deleting data. 

Other times, it’s far more advanced. A state-sponsored actor might compromise your local AD, escalate access, and pivot into Azure using a synced identity. From there, they target and delete your backups. Not only is your operational data gone — your safety net is too. 

You might read this and think “well, no nation-state would target us,” but the sad fact is that attack technology always trickles downward. What takes a sophisticated team of experts today can be done by a ransomware gang next week and by a run-of-the-mill ankle-biter next month. As the ransomware market expands, and criminals compete with each other more, they’re being much less discriminating about who they attack, which increases the odds that you’ll get hit. An untargeted attack can do just as much damage to your business as one specifically aimed at you. 

Recovery tip: You can’t assume your backup is safe just because your data is in the cloud. Backups are often the first thing targeted —  here’s why backups are targeted. That means you need copies in a location your attacker can’t reach. Backups need to be immutable, isolated, and independent of your production systems. It’s not enough to say you have a backup. You need to know you can get it back when it counts. 

 

Mistakes by admins: The most common cause of data loss 

We all make mistakes. I’ve been in this field long enough to say that with confidence — even great admins on a good day can misconfigure something. The problem is, with today’s systems, small changes can have major ripple effects. 

Retention policies are a great example. Someone misconfigures a retention policy and sets it to 9 days instead of 90. Or a PowerShell script gets deployed with the wrong scope and clears out a folder structure. These are honest mistakes, but they carry real consequences. 

Then there are more complex cases — like the major U.S. bank that trusted its SaaS provider’s default retention policy. There was a bug in the logic. The result? Federally mandated records were deleted. By the time anyone realized, the recovery window had passed, and the bank’s risk committee had to be notified. 

No matter how well-trained your admins are, in a world where every IT team is under crushing pressure to do more, faster, with less, mistakes are guaranteed to happen. 

Recovery tip: Your backup strategy has to account for people. The good ones, the tired ones, the well-meaning ones who just made a bad change — and the ones who might mean harm. That means external, versioned backups you can access independently — even if someone on your own team made a critical change or deleted something maliciously. And more than that, it’s about building trust and a strong security culture. People need to feel comfortable admitting when something went wrong, before it escalates. 

 

Mishaps at your cloud provider: The shared responsibility reality 

Even the biggest cloud providers have bad days. In September 2024, Microsoft lost weeks of security logs for some customers due to a bug in their internal monitoring agents. Earlier, Google Cloud deleted critical pension data of one of Australia’s largest pension providers due to a misconfiguration of the Google Cloud VMware Engine (GCVE). The customer had no way to get it back through Google, but they fortunately had their own third-party backup in place. 

And these mishaps aren’t rare. These kinds of failures may be complex, but they’re not impossible. If your DR plan assumes your cloud vendor won’t mess up — or that they’ll be able to fix any problems they cause — you’re gambling. 

Recovery tip: Shared responsibility means your vendor protects the infrastructure — not your data. They essentially promise not to lose all of your data at the same time—not to help you recover if you lose all your data at the same time. If something gets deleted, overwritten, or lost due to their error (or yours), it’s your responsibility to recover. That’s why independent backup, stored off-platform and regularly tested, is so important. 

 

Migration gone bad: Underestimated and over-impactful 

Migrations should be straightforward — but they rarely are. They’re a little like home renovations in that they always take longer than expected, cost more than planned, and something breaks along the way. 

In larger transitions, like moving from one cloud provider to another, things can go completely sideways. A large EU retailer migrated to Google Cloud and experienced serious sync and data integrity issues. They didn’t have a rollback plan. Their recovery hadn’t been tested. They were stuck. 

We like to think of migrations as upgrades. But they’re also risk windows — times when data is in transit, systems are shifting, and safeguards are at their weakest. 

Recovery tip: Treat migrations like disaster scenarios. You need complete, point-in-time backups of everything critical before you cut over. And you need to test recovery as part of the migration plan. If you don’t, you might find yourself restoring yesterday’s lunch menu while your billing system stays offline. 

 

Final thoughts: Plan like it’s going to happen, because it will 

There’s a recurring theme in every scenario I’ve laid out: testing. Not theory. Not a spreadsheet. Actual, practiced, verifiable recovery testing. 

It’s not enough to say you have a disaster recovery plan. You need to prove it works — to yourself, to your team, and maybe even to regulators. That’s where real resilience comes from. Not from wishful thinking, but from preparation. 

You can’t predict every attack. You can’t prevent every mistake. And you can’t control what your cloud vendor does. But you can control how you prepare, and how quickly you bounce back. 

So test your plan. Test it again. And if it fails, fix it now — not during an actual incident. 

RansomwareBackup and recoveryAnomaly detectionCyber resilienceShared responsibilityDisaster recovery planning

About Keepit
At Keepit, we believe in a digital future where all software is delivered as a service. Keepit’s mission is to protect data in the cloud Keepit is a software company specializing in Cloud-to-Cloud data backup and recovery. Deriving from +20 year experience in building best-in-class data protection and hosting services, Keepit is pioneering the way to secure and protect cloud data at scale.

About Version 2 Limited
Version 2 Digital is one of the most dynamic IT companies in Asia. The company distributes a wide range of IT products across various areas including cyber security, cloud, data protection, end points, infrastructures, system monitoring, storage, networking, business productivity and communication products.

Through an extensive network of channels, point of sales, resellers, and partnership companies, Version 2 offers quality products and services which are highly acclaimed in the market. Its customers cover a wide spectrum which include Global 1000 enterprises, regional listed companies, different vertical industries, public utilities, Government, a vast number of successful SMEs, and consumers in various Asian cities.

The four Ms of data loss — and how to recover with confidence

If you’re responsible for your organization’s data — whether in IT, security, compliance, or ops — there’s a good chance you’ve already dealt with some form of data loss. If not, odds are you will. The key is understanding how those losses happen and how to recover. 

In my experience, most incidents fall into one of four categories — I call them the four Ms: Malicious attacks, mistakes by admins, mishaps at your cloud provider, and migrations gone bad. 

Let’s take a look at each. Along the way, I’ll share real examples, the patterns I’ve seen over and over again, and what you can do to make sure you’re ready when (not if) something goes wrong. 

Malicious attacks: You will be targeted 

Let’s start with the one everyone knows: cyberattacks. You’ve seen the headlines — ransomware, data-wipes, stolen credentials, you name it. But what doesn’t always make the news is how modern attacks are increasingly hybrid and decreasingly targeted. 

We’re no longer dealing with isolated ransomware gangs. Today’s attacks are more coordinated, more hybrid, and less targeted than ever. Nation-state actors like MERCURY (now Mango Sandstorm) and DEV-1084 (now Storm-1084) have proven they can compromise on-prem environments, escalate privileges, and then pivot into cloud systems like Azure — where they delete Azure-based backups and try to erase the recovery path itself. That’s right: They don’t just go after your data, they go after your recovery plan. 

These aren’t theoretical. Microsoft’s Threat Intelligence blog and others have published chilling case studies on how hybrid attackers operate — and how hard they are to stop once inside. 

Attacks also don’t need to be that sophisticated to be devastating. Many start with a user doing something they shouldn’t — clicking a phishing link or exposing credentials. It’s not intentional, but it’s all an attacker needs to get in, elevate access, and start deleting data. 

Other times, it’s far more advanced. A state-sponsored actor might compromise your local AD, escalate access, and pivot into Azure using a synced identity. From there, they target and delete your backups. Not only is your operational data gone — your safety net is too. 

You might read this and think “well, no nation-state would target us,” but the sad fact is that attack technology always trickles downward. What takes a sophisticated team of experts today can be done by a ransomware gang next week and by a run-of-the-mill ankle-biter next month. As the ransomware market expands, and criminals compete with each other more, they’re being much less discriminating about who they attack, which increases the odds that you’ll get hit. An untargeted attack can do just as much damage to your business as one specifically aimed at you. 

Recovery tip: You can’t assume your backup is safe just because your data is in the cloud. Backups are often the first thing targeted —  here’s why backups are targeted. That means you need copies in a location your attacker can’t reach. Backups need to be immutable, isolated, and independent of your production systems. It’s not enough to say you have a backup. You need to know you can get it back when it counts. 

Mistakes by admins: The most common cause of data loss 

We all make mistakes. I’ve been in this field long enough to say that with confidence — even great admins on a good day can misconfigure something. The problem is, with today’s systems, small changes can have major ripple effects. 

Retention policies are a great example. Someone misconfigures a retention policy and sets it to 9 days instead of 90. Or a PowerShell script gets deployed with the wrong scope and clears out a folder structure. These are honest mistakes, but they carry real consequences. 

Then there are more complex cases — like the major U.S. bank that trusted its SaaS provider’s default retention policy. There was a bug in the logic. The result? Federally mandated records were deleted. By the time anyone realized, the recovery window had passed, and the bank’s risk committee had to be notified. 

No matter how well-trained your admins are, in a world where every IT team is under crushing pressure to do more, faster, with less, mistakes are guaranteed to happen. 

Recovery tip: Your backup strategy has to account for people. The good ones, the tired ones, the well-meaning ones who just made a bad change — and the ones who might mean harm. That means external, versioned backups you can access independently — even if someone on your own team made a critical change or deleted something maliciously. And more than that, it’s about building trust and a strong security culture. People need to feel comfortable admitting when something went wrong, before it escalates. 

Mishaps at your cloud provider: The shared responsibility reality 

Even the biggest cloud providers have bad days. In September 2024, Microsoft lost weeks of security logs for some customers due to a bug in their internal monitoring agents. Earlier, Google Cloud deleted critical pension data of one of Australia’s largest pension providers due to a misconfiguration of the Google Cloud VMware Engine (GCVE). The customer had no way to get it back through Google, but they fortunately had their own third-party backup in place. 

And these mishaps aren’t rare. These kinds of failures may be complex, but they’re not impossible. If your DR plan assumes your cloud vendor won’t mess up — or that they’ll be able to fix any problems they cause — you’re gambling. 

Recovery tip: Shared responsibility means your vendor protects the infrastructure — not your data. They essentially promise not to lose all of your data at the same time—not to help you recover if you lose all your data at the same time. If something gets deleted, overwritten, or lost due to their error (or yours), it’s your responsibility to recover. That’s why independent backup, stored off-platform and regularly tested, is so important. 

Migration gone bad: Underestimated and over-impactful 

Migrations should be straightforward — but they rarely are. They’re a little like home renovations in that they always take longer than expected, cost more than planned, and something breaks along the way. 

In larger transitions, like moving from one cloud provider to another, things can go completely sideways. A large EU retailer migrated to Google Cloud and experienced serious sync and data integrity issues. They didn’t have a rollback plan. Their recovery hadn’t been tested. They were stuck. 

We like to think of migrations as upgrades. But they’re also risk windows — times when data is in transit, systems are shifting, and safeguards are at their weakest. 

Recovery tip: Treat migrations like disaster scenarios. You need complete, point-in-time backups of everything critical before you cut over. And you need to test recovery as part of the migration plan. If you don’t, you might find yourself restoring yesterday’s lunch menu while your billing system stays offline. 

Final thoughts: Plan like it’s going to happen, because it will 

There’s a recurring theme in every scenario I’ve laid out: testing. Not theory. Not a spreadsheet. Actual, practiced, verifiable recovery testing. 

It’s not enough to say you have a disaster recovery plan. You need to prove it works — to yourself, to your team, and maybe even to regulators. That’s where real resilience comes from. Not from wishful thinking, but from preparation. 

You can’t predict every attack. You can’t prevent every mistake. And you can’t control what your cloud vendor does. But you can control how you prepare, and how quickly you bounce back. 

So test your plan. Test it again. And if it fails, fix it now — not during an actual incident. 

About Keepit
At Keepit, we believe in a digital future where all software is delivered as a service. Keepit’s mission is to protect data in the cloud Keepit is a software company specializing in Cloud-to-Cloud data backup and recovery. Deriving from +20 year experience in building best-in-class data protection and hosting services, Keepit is pioneering the way to secure and protect cloud data at scale.

About Version 2 Limited
Version 2 Digital is one of the most dynamic IT companies in Asia. The company distributes a wide range of IT products across various areas including cyber security, cloud, data protection, end points, infrastructures, system monitoring, storage, networking, business productivity and communication products.

Through an extensive network of channels, point of sales, resellers, and partnership companies, Version 2 offers quality products and services which are highly acclaimed in the market. Its customers cover a wide spectrum which include Global 1000 enterprises, regional listed companies, different vertical industries, public utilities, Government, a vast number of successful SMEs, and consumers in various Asian cities.

What Gartner’s Latest ITSM Report Means for Mid-Market ITSM Teams

The Gartner® ITSM report is a popular guide for IT leaders. They use it to stay updated on ITSM platforms. The report shows which platforms can best help them meet their business goals. The Gartner Market Guide for ITSM tools 2025 dives deep into several service management platforms that are key players in the industry.

Let’s look at some of the compelling information to be found in the report. We’ll also examine if the major players are the right fit for mid-market IT teams.

3 Key Takeaways from the Gartner ITSM Report

When IT leaders begin their tool search, they consider the tactical objectives that they need to address within the next one to two years. They must also think about the long-term usefulness of the service management ITSM tool the choose. They consider scalability, how processes will mature, and even if it’s fit for enterprise-wide usage.

As such, leaders must consider tomorrow’s trends and how ITSM providers are addressing these within their solutions. The Gartner Market Guide ITSM addresses three notable trends.

Artificial Intelligence (AI)

Artificial intelligence in ITSM helps support business objectives by speeding up work and improving customer experiences. Vendors are seeking new ways to incorporate AI into their platforms. Examples of AI usage in ITSM are summarizing ticket data, conversational chatbots or knowledge generation.

Enterprise Service Management (ESM)

Enterprise service management is a digital transformation initiative that pushes service management principles into business units outside IT. In ESM, teams like HR and facilities deliver their services in a value-added way. They use tools like those found in IT settings. These may include service portals, knowledge bases, real-time reporting, and ticketing.

Automation

When teams automate repetitive tasks, they improve response times and enhance the overall user experience. Tools that leverage advanced process managers aid I&O teams in meeting these goals.

Many ITSM Tools Fall Short for Mid-Market Leaders

While keeping trends in mind is important for IT organizations, mid-market leaders need to balance “bells & whistles” with practicality. Too often, teams over-buy their ITSM solution which leads to big spending and little value. Mid-market buyers need to be aware of the following when considering an ITSM investment.

Enterprise desire on a mid-market budget

Enterprise solutions have enterprise price tags. By their nature, they are not designed for budget conscious buyers.

In contrast, mid-market ITSM vendors fill the gap. They may not be well-known names because they are not always in the Gartner Market Guide. However, they provide high-quality ITSM solutions that fit the needs of mid-market buyers.

For example, vendors may offer a concurrent user pricing model to help businesses save on licensing costs.

People powered: lack of time and skills reduce value

Hefty tools built for enterprise environments require a lot of set up and administration. From challenging integrations and workflow customization to feature overload and complex CMDBs, the setup and maintenance of enterprise solutions is a huge commitment. It generally requires increased headcount or significant service costs.

Avoiding this is critical for the mid-market buyer. A better option is to find a solution that:

  • Offers managed options. Let the experts handle updates, security and patching.
  • Aligns with your core needs. Don’t try to do everything at once. Consider starting with incident management. Aim to expand from that point.
  • Has pre-configured workflows. If your aim is to mature the organization, begin with pre-built workflows. This allows you to get started by leveraging the expert knowledge. Then, you can adapt these to fit your specific needs as you gain experience.

Need for speed: implementations are too slow.

Few mid-market players can wait a year before they enhance their infrastructure and operations departments. Yet, implementation time with enterprise solutions can take that long – or longer.

Most midsized businesses need to be nimble. They must innovate to keep pace with their markets. They need their IT organizations to keep up.

In talking with vendors, ask about their project management and onboarding speed with organizations similar to yours. How fast did they become operational?

Evaluate ITSM Tools Beyond the Market Guide

According to Gartner, there are hundreds of ITSM solutions in the market. Only 20 vendors are identified in the Gartner Market Guide, so there are many others to explore. In fact, the Guide itself indicates that exclusion from the report does not mean that a product lacks viability.

This is good news for the mid-market buyer when choosing an ITSM tool. They aren’t simply stuck with the same old 20 vendors. Beyond basic features, ITSM software evaluation should a holistic view on the offering and vendor.

Total Cost of Ownership (TCO)

The total cost of ownership is the total of all items needed for a long-term solution for your company. Consider costs beyond the licensing price tag, such as:

  • Modules and add-ons
  • Usage costs, like texting or social media
  • Costs related to hosting
  • Cost increases as you scale
  • Services and support for customizations, integrations, or configuration
  • Data migration services
  • Training
  • End user onboarding

Flexibility and Integration

Flexibility is a crucial consideration. Ultimately, you’re not just putting money into current requirements. You should be forecasting your needs into the future so that you find a solution that will scale with your business. Points to investigate include:

  • Workflow adaptation. How easily can workflows be adapted? Does it need extra development services? Is it low-code / no-code, allowing internal teams to manage it effortlessly?
  • Pay as you grow. Are you required to cover all expenses now? We noted earlier that ITSM buyers often pay for more than they are able to use right now. Instead of having HR workflows available on day one, for instance, ask if these can be added later.
  • Self-service savings. As you change, can you easily modify the solution internally. For instance, can you update the service portal on our own? Are you able to administer it internally?
    Support and Service Options
    Of course, if you’re considering internal administration, make sure to have product support experts available. They can assist you when you’re feeling lost. Training and customer service should be top priorities when engaging with vendors. Understand the vendor’s:
  • SLAs. Will you be able to reach someone quickly and easily enough to ensure business operations? Do they have 24/7 operations? Are representatives regional to your area?
  • Support channels. Are there specific processes to follow? Will you have a dedicated Customer Success Manager who you can contact to resolve issues?
  • Onboarding. Is the procedure clear? Do you know what to expect for configuration, integration and training? Are there established processes to expedite the rollout?

Conclusion

As a flexible ITSM solution, OTRS deserves a look. It’s built with ITSM best practices in mind and has over 17 pre-configured ITSM processes on board. Highlights of the offering include:

  • Request management/ticketing
  • CMDB/asset management
  • Reporting and analytics
  • Knowledge management
  • Customizable service portal
  • Easy-to-use process manager

Add OTRS to your shortlist. As a mid-market purchaser, keep in mind that this and other alternative options are available to you.

And, take time to read the Gartner Market Guide. It offers perspective on the market and trends that are shaping the industry. You will think about what’s possible and your own vision for the future – regardless of your team’s size.

About OTRS

OTRS (originally Open-Source Ticket Request System) is a service management suite. The suite contains an agent portal, admin dashboard and customer portal. In the agent portal, teams process tickets and requests from customers (internal or external). There are various ways in which this information, as well as customer and related data can be viewed. As the name implies, the admin dashboard allows system administrators to manage the system: Options are many, but include roles and groups, process automation, channel integration, and CMDB/database options. The third component, the customer portal, is much like a customizable webpage where information can be shared with customers and requests can be tracked on the customer side.

About Version 2 Limited
Version 2 Digital is one of the most dynamic IT companies in Asia. The company distributes a wide range of IT products across various areas including cyber security, cloud, data protection, end points, infrastructures, system monitoring, storage, networking, business productivity and communication products.

Through an extensive network of channels, point of sales, resellers, and partnership companies, Version 2 offers quality products and services which are highly acclaimed in the market. Its customers cover a wide spectrum which include Global 1000 enterprises, regional listed companies, different vertical industries, public utilities, Government, a vast number of successful SMEs, and consumers in various Asian cities.

How to Plan a CentOS to AlmaLinux Migration

The end of the CentOS Linux community support lifecycle has left many organizations searching for a stable, permanent replacement for their operating systems. AlmaLinux, as an open source RHEL fork, has gained massive traction, especially among system administrators, developers, and IT decision-makers.

However, moving from CentOS to AlmaLinux, particularly in large scale deployments with thousands (or tens of thousands) of servers, is far from a plug-and-play migration. It requires careful planning, technical expertise, and meticulous execution to ensure business continuity and operational efficiency.

Below, we’ll walk you through the essential steps for a successful CentOS to AlmaLinux migration, focusing on some of the common obstacles teams may encounter during the process.

Editor’s Note: This blog was originally published on September 12, 2022 and was updated for accuracy in March 2025. 

Table of Contents

  1. Why Migrate From CentOS to AlmaLinux?
  2. CentOS to AlmaLinux Migration Steps
  3. Other Considerations
  4. Final Thoughts

Back to top

Why Migrate From CentOS to AlmaLinux?

Red Hat’s decision to  phase out CentOS’s stable release model to focus on CentOS Stream — which delivers more frequent updates due to its rolling release model — left enterprises craving stability and predictability. AlmaLinux emerged as one of the top CentOS alternatives due to its binary compatibility with RHEL and its steadfast support of the stable release model.

What Makes AlmaLinux a Good CentOS Alternative?

  • Stability: Unlike CentOS Stream, AlmaLinux stays committed to stability, making it suitable for production environments.
  • Community-Driven: Maintained by the AlmaLinux Foundation, AlmaLinux has an active and devoted community.
  • Binary Compatibility: AlmaLinux mirrors RHEL, ensuring minimal disruptions when transitioning.
  • Cost-Effective: Unlike RHEL, it is free but offers comparable enterprise-level reliability.

If maintaining critical business operations on a predictable, secure Linux distribution is your priority, AlmaLinux is an excellent choice.

Need More Time on CentOS? Get Long-Term Support Today

CentOS LTS from OpenLogic extends your migration runway up to five years past community EOL. Secure your deployments and stay compliant while you plan your migration.

Explore CentOS LTS

Back to top

CentOS to AlmaLinux Migration Steps

Migrating hundreds or thousands of systems across environments involves more than swapping repositories. Here we break down the steps involved before, during, and after you migrate. 

1. System and Application Compatibility

Conduct a detailed inventory of your CentOS systems. Identify:

  • Applications, databases, and processes tied to your OS.
  • Third-party packages and dependencies for compatibility checks.
  • Proprietary or custom-built tools that may have version-specific constraints.

2. Hardware Requirements

Ensure your infrastructure supports AlmaLinux versions. Legacy hardware used with CentOS 6 or 7 may need replacements due to incompatibilities with newer kernels.

3. Backup and Rollback Strategies

Before initiating migration, confirm backup systems are in place and test their validity:

  • Perform full system snapshots and data backups.
  • Ensure rollback plans can reinstate current setups in case the transition introduces issues.

4. Testing and Validation

Pilot migrations in a staging environment, simulating production operations. Address migration errors or failures before implementing across critical systems.

5. Choosing the Right Migration Path

Select between in-place migration or new environment deployment. Each approach has distinct tradeoffs:

  • In-place migrations: Best for physical hardware when no substantial downtime is allowed. However, it carries risks of disruptions if interrupted.
  • New environment deployments: Ideal for virtualized or cloud systems. This approach minimizes disruptions but requires additional hardware or temporary instances.

If you are on physical hardware, migrating in place may be the easiest (and cheapest) route because it does not require more systems. In this scenario, it’s important to make sure that connections are stable, and the machine will be available the whole time, because the system could end up in an unrecoverable state if the script gets interrupted. If that were to happen, you would need a rescue disk and some manual work to get back to functionality. If you can’t take a system out of use to rebuild, then running the migration may be the best option.

However, if you have spare hardware or are on a virtualized infrastructure, it would be preferable (and safer) to build a new system to your specifications, migrate the apps and data over, and then replace the old system with the new one.

Carefully weigh these considerations to tailor your CentOS migration strategy for your unique needs. Now let’s look at some actual migration paths:

CentOS 6 to AlmaLinux Migration Path

Since there is no direct migration path from Centos 6 to AlmaLinux (AlmaLinux starts at 8.4), you must be on CentOS 8.4 at least in order to migrate.

Two possible approaches — the first would be to upgrade from 6 to 7 to 8, and then migrate your data. However, this would be time-consuming and risky because of all the package changes between major versions.

The second (and more advisable) approach is to build a new machine prior to migrating. Best case scenario: All required third-party software has a new version, and data can be safely upgraded. Worst case: There is software that depends on CentOS libraries. If the latter is true, you would need to either find alternatives, or identify a way to run the software anyway. Fortunately, containerization makes it relatively easy nowadays to run older versions of software on newer systems, or even on completely different distributions.

CentOS 7 to AlmaLinux Migration Path

The migration path for CentOS 7 is virtually identical to CentOS 6, but a little easier because CentOS 7 already uses systemd for service management, whereas CentOS 6 uses legacy SysV init scripts. There are a few other changes, but that is a major one that makes upgrading from 7 less complex than 6.

For detailed instructions on how to migrate from CentOS 7 to AlmaLinux 9 (the current version), take a look at this blog on CentOS to Rocky Linux migration and simply ignore the steps that are specific to converting from the latest version of Alma to the latest version of Rocky. 

CentOS 8 to AlmaLinux Migration Path

Since CentOS 8 and AlmaLinux 8 are nearly identical, this is a relatively painless migration. Minor changes only; the CentOS repos are swapped out for AlmaLinux repos, and a handful of packages (mostly branding packages) are replaced.

CentOS Stream to AlmaLinux Migration 

The almalinux-deploy.sh script automates the process of converting a CentOS Stream system to AlmaLinux 8. It creates the repo files for AlmaLinux, replaces branded packages, and then performs a distro-sync to sync up the system to the current version of the packages in the repos.

Note: The migration will work with CentOS Stream, but some packages may be a little newer than the current AlmaLinux packages, so it downgrades packages using distro-sync to match the current version in the repos.

6. Run Pilot Migrations

Select non-critical systems to test the migration process:

  • Execute the switch to AlmaLinux.
  • Validate applications and services post-migration.
  • Modify or replace failed dependencies.

Based on test results, refine the migration plan for production systems.

7. Full-Scale Deployment

Once confident, proceed with rolling out migrations across production systems:

  • Schedule migrations during downtime or maintenance windows.
  • Maintain dedicated technical teams ready to handle interruptions on the fly.

Implement migrations in phases to minimize potential disruptions and rollback issues.

8. Post-Migration Testing

Run complete QA procedures post-migration:

  • Verify application functionality and security.
  • Monitor system logs for errors or warnings.
  • Confirm user access and permissions are intact.

Fix issues before declaring the migration successful.

9. Ongoing Maintenance

Post-migration upkeep ensures systems remain secure and scalable:

  • Enable AlmaLinux repos for regular OS updates.
  • Schedule periodic system health checks.
  • Establish monitoring and alert systems for performance optimization.

Back to top

Other Considerations

The only official migration script is almalinux-deploy.sh, provided by AlmaLinux itself. This script will not only migrate CentOS 8 to AlmaLinux, but also Oracle Linux 8, RHEL 8, Rocky Linux 8, Virtuozzo Linux (VZLinux) 8, and CentOS Stream, along with the version 9 variants. There may be others out there, but you should proceed with caution, and verify the script does what is wanted.

Back to top

Final Thoughts

Executing a CentOS to AlmaLinux migration is not without its challenges, but with proper planning and resource allocation, your organization can smoothly transition to a stable and future-proof Linux distribution. While migration may feel daunting, following structured processes ensures minimal risk while maximizing uptime for your business.

Lastly, if you’re navigating a large-scale migration and lack internal expertise, OpenLogic’s Linux experts can alleviate the strain. We can offer guidance or our Professional Services team can perform the migration itself. Once you have successfully migrated, we also offer 24/7 AlmaLinux support. 

About Perforce
The best run DevOps teams in the world choose Perforce. Perforce products are purpose-built to develop, build and maintain high-stakes applications. Companies can finally manage complexity, achieve speed without compromise, improve security and compliance, and run their DevOps toolchains with full integrity. With a global footprint spanning more than 80 countries and including over 75% of the Fortune 100, Perforce is trusted by the world’s leading brands to deliver solutions to even the toughest challenges. Accelerate technology delivery, with no shortcuts.

About Version 2 Limited
Version 2 Digital is one of the most dynamic IT companies in Asia. The company distributes a wide range of IT products across various areas including cyber security, cloud, data protection, end points, infrastructures, system monitoring, storage, networking, business productivity and communication products.

Through an extensive network of channels, point of sales, resellers, and partnership companies, Version 2 offers quality products and services which are highly acclaimed in the market. Its customers cover a wide spectrum which include Global 1000 enterprises, regional listed companies, different vertical industries, public utilities, Government, a vast number of successful SMEs, and consumers in various Asian cities.