We recently published a blog about how easy it is to adapt to OpenSUSE Leap when coming from CentOS. In this blog post, we will provide some guidance on how to plan and prepare for an actual migration and what considerations we should take into account.

Migrating to a new OS usually raises several questions:

Can I accomplish the same tasks on OpenSUSE Leap that I could on CentOS?

Yes, there are more similarities than differences in terms of how to operate it and software availability. This is not a drastic migration from completely different operating systems, like migrating from Linux to Windows. We already highlighted many similarities in our previous blog “How to Feel at Home”, a recommended reading to understand it doesn’t require a big effort to start using OpenSUSE Leap when you are already familiar with CentOS.

What steps should I take to migrate my workloads?

1) Identify the applications to migrate and their versions.

Here, I don’t mean every installed application, but those that provide a service or are needed for our operational and automation tools.

In the case where the same versions aren’t available on both platforms, we can test whether the existing version in the new platform is sufficient. In most cases, it will be. Distributions like RHEL or SLES strive to ensure the updates are seamless and don’t impact existing applications, with much effort put into backporting bug fixes so security won’t be a concern even if it looks like an old version.

2) Identify the packages in OpenSUSE Leap that provide the applications we need.

We will provide all the necessary technical details in further posts. Although, in many cases, the package names will be the same on both platforms so this may not even be necessary.

We can use a table similar to the one below to prepare our migration:

• The first column contains the application name, as per function and system requirements, for example if we have a web application that consists of a front end web server and backend database we will split into two rows, one for the frontend and another one for the backend.
• The following column contains the main packages we need on the new system including their versions if necessary to specify.
• Then the number of servers we need to setup.
• And the last all the other requirements and notes we need to do the migration.

3) Prepare the migration itself

Can we execute the migration without downtime? The answer depends on the application, but there are always methods to minimize downtime using a temporary (or permanent if you want to have more resilience and a worry-less setup), Active-Active or Active-Passive setup.

Depending on the importance of the service, you can decide whether it’s worth investing in these mechanisms. We will examine some examples of this in upcoming blogs.

Please bear in mind, migrations can be tedious and prone to human error. This is the perfect opportunity to automate.

Automate the deployment of the application in our new OS and, perhaps, the migration process itself to minimize downtime, especially if the effort is reasonable and we can reuse it for further use cases.

Last but not least, don’t forget to include a task to do a backup.

4) Prepare the rollback plan

Can we use the previous setup if our migration is not successful at the first attempt? It is always recommended to have a rollback plan in case the migration doesn’t go as expected, for that it is important to identify what to do to keep our services running in case something doesn’t go as expected. How can we keep the data in sync so that it can be used back in our previous system? etc… it is also very important to try not to mix application upgrades with migration, to avoid complicating it and introducing more variables.

In some cases fixing forward may be the way, if we think it will take longer to rolling back, and nothing irreversible has to be done.

In any case, we don’t want problems and the best way to avoid them is by testing the migration, and the rollback plan, on a development environment as close as possible to the productive one.

5) Bonus – Automated Testing

To ensure that our application functions as expected, this migration process offers a great opportunity to start building our automated tests. Although we may not migrate to a new OS in the near future, these tests can be beneficial when updating or deploying new applications instances. They are a good practice to adopt, particularly if we plan to move this services to a Kubernetes environment in the future.

Conclusions

This blog post briefly outlines some of the necessary steps to migrate from CentOS to OpenSUSE Leap from a more practical perspective.

As a CentOS alternative, openSUSE brings numerous benefits, including stability, SUSE’s support to the community, powerful system management tools, advanced distro features, and access to a rich package repository. The active openSUSE community and easy migration tools further enhance the transition process. If you are seeking a robust and reliable Linux distribution for your workloads, you should consider openSUSE.

Looking for further insights into what you can achieve by migrating to openSUSE?, check out other blogs in this series:

• From CentOS to openSUSE Leap: How to Feel at Home
• Step-by-Step Guide Installing openSUSE Leap on your virtualized environment
• 10 Reasons to Migrate from CentOS to openSUSE