Migrating Workloads From CentOS To OpenSUSE Leap – Introduction

We have talk already 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.

Let’s start diving into more details, migrating to a new OS usually raises several questions. Here are a few to consider for efficiency:

• 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. Having identified the applications we need, what packages provide them in OpenSUSE Leap?

   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.

   Example table for applications to migrate

   App. Name	Pkg/s + Version	N. Servers	Other Requirements and notes
   myApp – frontend	apache2, python3-3.6.15, myapp-1.0, mybackupclient	1	Will require a load balancer to minimize service disruption
   myApp – backend	postgresql15-server, mybackupclient	1	Will require to setup replication to minimize service disruption

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 going forward may be the way, if we think it will take longer than 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.

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

Migrating from CentOS to 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 SUSE and openSUSE?, check out other blogs in this series:

(Visited 1 times, 1 visits today)