When it was released in 2015, Red Hat OpenShift 3 was a revolutionary solution for many organizations by enabling them to run containerized workloads that provide high availability and resilience. Numerous organizations around the globe invested in a robust OpenShift 3 infrastructure and deployed large numbers of mission-critical applications on these platforms.
[ For more on OpenShift's history, read PaaS to Kubernetes to cloud services: Looking back at 10 years of Red Hat OpenShift. ]
However, OpenShift 3 is nearing the end of its life, with support ending on June 30, 2024. As with most Red Hat technologies, this has been an extraordinary length of support for the platform, but organizations now have an important reason to start planning their migration to OpenShift 4.
These organizations are now facing the task of migrating many OpenShift 3 workloads to OpenShift 4 to maintain support and take advantage of the latest features in OpenShift, such as ease of upgrades, service mesh, and much more.
Some of the challenging scenarios you might face with migrating workloads include:
- Workloads with large amounts of data in persistent storage
- Workloads with dependencies on platform specific features (such as Kuryr load balancers)
- Workloads that have been deployed manually
- Workloads that are no longer managed by a team
This article offers some tips to help you plan your migration from OpenShift 3 to OpenShift 4.
High-level project phases
There are three main phases to consider in planning your migration project:
- Discovery
- Categorization
- Implementation
[ Related reading: Kubernetes: Everything you need to know ]
1. Discovery phase
To begin your migration, identify all applications and namespaces along with:
- Application name and description
- Application software or technology components (for example, Java frontend with a Postgres database backend)
- Current storage usage
- Dependencies: Does this application have any specific OpenShift or non-OpenShift dependencies?
- Current owner: Who (person or team) is responsible for this application?
- Deployment method: Is the application deployed with automation (pipelines, ArgoCD, and so on) or deployed manually?
2. Categorization phase
Once you gather this information, divide your applications into three categories:
- Category 1: Applications that are deployed with automation (by their teams) and have no platform-specific dependencies nor data in persistent volumes. These applications can be deployed to OpenShift 4 through their respective teams.
- Category 2: Applications that are deployed through automation (by their teams) but have platform-specific dependencies or data in persistent volumes. These applications need to be examined and an appropriate migration strategy formulated.
- Category 3: Applications that are manually deployed, have no current team managing them, and may or may not have platform-specific requirements or data in persistent volumes.
3. Implementation phase
This is not a straightforward phase; it may be complex and have many different branches. But once you categorize all the applications, you can keep track of each one's progress and completion.
Once you're ready to migrate, check the Migrating from version 3 to 4 overview documentation for specific guidance.
Information is power
Managing a large migration project can be a daunting task, especially with all the unknown variables in the beginning. To alleviate much of the uncertainty, your first step should be gathering as much accurate information as possible about each of the applications (or namespaces) running on OpenShift 3. This can flow into a project-implementation plan, which can demonstrate a predictable way forward.
[ Check out Red Hat's Portfolio Architecture Center for a wide variety of reference architectures you can use. ]
