Don’t Redo the Work: How to Migrate OS the Easy Way
So, you think you want to migrate OS (AKA operating systems)? In (most) everyone’s life there comes a time where you look toward migrating to another operating system. There are a variety of reasons why — take for instance the recent trouble with CentOS and RedHat. This process change has broadened adoption of new Enterprise Linux variants like Rocky, Alma Linux, or even Ubuntu.
Instead of rebuilding from the ground up, Puppet can be an excellent choice to make the work of evaluating or moving to a new operating system a much more pleasant experience.
Table of Contents:
- Reasons to Migrate OS (or Not!)
- The DRY Principle for Migrating OS
- Tips and Tricks to Migrate OS if You Use Puppet
- Try Puppet for Your OS Migration
Reasons to Migrate OS (or Not!)
If it ain’t broke, why fix it? There are reasons for and against migration to consider before you start the work, especially if you’ve dedicated a lot of time to building images and ensuring that your code is already working well on the current OS. While extended support options do exist and can be extremely useful for migrating on your own schedule, eventually everything needs to move forward or be decommissioned.
So, besides RedHat trying to decide your fate, what are some other reasons to migrate?
Why Migrate OS?
If your OS has reached end of life (EOL) or it’s a legacy OS with too many incompatibilities for your current requirements, it might be time to take the plunge and migrate.
Let’s look at a few specific reasons why you might want to migrate OS:
- End-of-Life (EOL): This is typically the primary driver for migration. If your OS has reached EOL or newer releases of your application are becoming incompatible with your legacy components, migrating to an updated version or another operating system may be your best choice.
- Software Testing: If your application needs to run on multiple operating systems, being able to provision a newer version of the operating system or any new OSs that arise is essential.
- Legacy Code Management: Inherited a system with a labyrinth of unmanaged configurations? You will likely need to analyze your existing system and predict compatibility with the new OS — something that Puppet can help with!
Keep in mind, you also don’t have to make the decision to migrate and commit 100% to it — you can A/B test before a major move to see which OS will work best for your needs.
When Shouldn't You Migrate OS?
In some cases, you can find legacy support for EOL operating systems. If you want to avoid the effort, testing, and configuration — you might want to stick with what you currently have.
We’ll use a real-world example here with Centos 7 hitting EOL — OpenLogic currently provides long term support for this EOL operating system, which is great if you want to take more time to decide on your next move, or simply keep things running the way that they were as long as possible.
Here are a few more reasons you might not choose to migrate, at least for now:
- Driver Availability: You’ll need to make sure any new OS has compatible drivers for all your hardware components. Missing drivers can render crucial hardware inoperable.
- Overall Costs: Migration isn't free. Factor in potential costs like software licenses, additional training for your team, and the time investment required for the migration process itself.
- Downtime: Downtime during a migration can disrupt workflows and potentially impact productivity.
- User Comfort: Consider the comfort level of your users — a drastic change in the operating system has a learning curve that will take time.
The DRY Principle for Migrating OS
In a world full of IT acronyms, the DRY (Don't Repeat Yourself) Principal is crucial for anyone managing infrastructure. This principle applies beautifully to OS migrations, where a significant chunk of your existing configuration can often be reused.
What is the DRY Principle?
DRY (Don't Repeat Yourself) avoids code duplication in software development. It prioritizes abstractions and data normalization to streamline maintenance and future changes. Puppet’s resource abstraction layer helps greatly reduce the effort of managing infrastructure, moving a server to the cloud or migrating to a later version or different OS.
DRY extends beyond code reuse. Here are some additional ways to embrace DRY during OS migrations:
- Modular Design: Break down your code into reusable modules. This allows for easier migration and reduces the risk of errors.
- Documentation: Maintain thorough documentation for your code. This clarifies the purpose of each module and simplifies future modifications, regardless of who tackles the migration.
- Version Control: Use version control systems like Git to track changes in your code. This allows you to revert to previous configurations if needed and simplifies collaboration during the migration process.
If you can move over existing code, and you will be able to do just that using a cross-OS platform like Puppet, you’re already one step closer to doing it the easy way (the DRY way).
Tips and Tricks to Migrate OS if You Use Puppet
From our own experience, here are a few fast tips and tricks to keep in mind as you Migrate OS using Puppet:
1. Forge Compatibility Check:
Before you migrate: Head to the Puppet Forge and verify compatibility for the modules you currently use with the new OS. You should also take this time to update modules if necessary.
Pro Tip: Stay tuned for the new Puppet Forge, offering even more streamlined compatibility checks.
2. Using the “Puppet Resource” Command:
If you are new to Puppet, you can install an agent on any supported system and use the “puppet resource” command to return example Puppet language that models the state of what’s running on your systems - resources like users, packages, Windows features and more.
3. Conditional Code for OS-Specific Tweaks:
Embrace the power of conditional statements (like if and else) in your Puppet code. If you have existing Puppet profiles for your OS, you may be able to start testing quickly on the new operating system to see what works and what doesn’t. If you know of “code breaking” changes within the new OS, implementing conditional statements may be a quick way to utilize the same profile, otherwise copying what works into a new profile and building from there may be your best option.
For example, "If it's CentOS 9, install package httpd, otherwise install apache2." This ensures your code adapts automatically during migration.
Pro Tip: Refer to our extensive documentation on writing conditional statements in Puppet.
4. Ensure Agent Availability:
Planning is key! Before migration, consult Puppet's software requirements for the target OS and Puppet Enterprise (PE) version, which double-checks that you have the appropriate agent available for the new environment.
Pro Tip: Break down complex configurations into smaller, reusable modules. This will simplify the migration and reduce the risk of errors.
Try Puppet for Your OS Migration
Not using Puppet? Puppet puts DRY to work during an OS migration — to test this out you can start by installing a Puppet agent on a single machine. From there, you only need a few basic Puppet commands to demonstrate how it manages configurations quickly and easily.
Puppet’s Professional Services team also has a lot of experience with migrating customers to a new operating system and helping establish those profiles quickly, so you can move fast and with confidence.
Why not try out Puppet Enterprise for free before your migration? You can see for yourself how easy it is to set up a node and see how it performs in different OS.
