Mark Bacigalupo

Posted on May 18

Migrating Workloads to OpenShift: A Practical Approach

#kubernetes #cloud #containers #openshift

TL;DR

This tutorial walks through migrating containerized applications to Red Hat OpenShift on IBM Cloud, covering assessment, containerization refinement, deployment configuration, and validation. You'll learn how to handle common migration challenges including persistent storage, networking, security contexts, and CI/CD integration. By the end, you'll understand how IBM Cloud's managed OpenShift service reduces operational friction during migrations through automated lifecycle management, integrated security defaults, and Red Hat-aligned tooling.

The Migration Challenge

Platform teams face a recurring problem: applications running in legacy container orchestration systems or basic Kubernetes clusters need to move to OpenShift for enhanced security, compliance, or operational consistency. The migration itself becomes a bottleneck—not because the workloads are complex, but because the target environment introduces new constraints around security contexts, networking models, storage classes, and lifecycle management.

Teams often discover these constraints mid-migration. A deployment that worked perfectly in vanilla Kubernetes fails in OpenShift due to security context constraints. Persistent volumes don't map cleanly. Network policies need rewriting. The migration stalls while teams debug environment-specific issues rather than focusing on application logic.

Why This Matters for OpenShift

OpenShift is not just Kubernetes with extra features—it's an opinionated platform with security-first defaults, integrated CI/CD tooling, and enterprise lifecycle management. These opinions create friction during migration if not understood upfront:

Security Context Constraints (SCCs): OpenShift restricts pod privileges by default, blocking containers that expect root access or host filesystem mounts
Networking Model: OpenShift uses OpenShift SDN or OVN-Kubernetes with specific ingress patterns that differ from standard Kubernetes ingress controllers
Storage Integration: Storage classes and persistent volume provisioning follow OpenShift conventions that may not match source environments
Image Registry: OpenShift includes an integrated registry with specific authentication and security scanning requirements
Lifecycle Management: OpenShift's operator-based approach to Day-2 operations requires different deployment patterns than traditional Kubernetes

Understanding these differences before migration prevents rework and reduces time-to-production.

What You'll Learn

This tutorial demonstrates:

How to assess existing containerized workloads for OpenShift compatibility
Techniques for adapting applications to OpenShift's security and networking model
A practical migration flow for a multi-tier application on IBM Cloud Red Hat OpenShift
Validation approaches to confirm successful migration
How IBM Cloud's managed OpenShift reduces migration complexity through automated configuration and Red Hat alignment

You'll gain practical experience with OpenShift-specific concepts while understanding how managed services handle operational overhead.

Architecture Overview

We'll migrate a three-tier application consisting of:

┌─────────────────────────────────────────────────────┐
│                  OpenShift Cluster                   │
│  ┌────────────────────────────────────────────────┐ │
│  │              Ingress/Route Layer               │ │
│  │         (OpenShift Router - Managed)           │ │
│  └────────────────────────────────────────────────┘ │
│                         │                            │
│  ┌────────────────────────────────────────────────┐ │
│  │           Frontend (React SPA)                 │ │
│  │        - Deployment + Service                  │ │
│  │        - ConfigMap for environment             │ │
│  └────────────────────────────────────────────────┘ │
│                         │                            │
│  ┌────────────────────────────────────────────────┐ │
│  │         Backend API (Node.js)                  │ │
│  │        - Deployment + Service                  │ │
│  │        - Secret for credentials                │ │
│  │        - Non-root security context             │ │
│  └────────────────────────────────────────────────┘ │
│                         │                            │
│  ┌────────────────────────────────────────────────┐ │
│  │         Database (PostgreSQL)                  │ │
│  │        - StatefulSet + Service                 │ │
│  │        - PersistentVolumeClaim                 │ │
│  │        - Restricted SCC                        │ │
│  └────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────┘

Managed by IBM Cloud:
- Control plane (API server, scheduler, controllers)
- Node lifecycle and patching
- OpenShift version upgrades
- Integrated monitoring and logging
- Network policy enforcement
- Storage provisioner integration

Customer Managed:
- Application deployments
- ConfigMaps and Secrets
- Route/Ingress definitions
- Application-level monitoring

Prerequisites

Required:

IBM Cloud account with Red Hat OpenShift cluster provisioned (4.19 or later)
oc CLI tool installed (download)
kubectl CLI tool installed
Existing containerized application with Docker images in a registry
Basic understanding of Kubernetes concepts (Deployments, Services, ConfigMaps)

Expected Experience Level:

Comfortable with container concepts and Docker
Familiar with Kubernetes resource definitions
Experience deploying applications to Kubernetes (helpful but not required)

Access Requirements:

Cluster admin or project admin role in target OpenShift cluster
Access to source container images (Docker Hub, private registry, etc.)

Step-by-Step Implementation

Step 1: Assess Current Workload Compatibility

Before migration, audit your existing deployments for OpenShift compatibility:

Review your exported manifests and deployment settings for common incompatibilities before you attempt a migration. In practice, this means checking for containers that require root access, privileged execution, host path volumes, host networking, or ingress resources that will need to be translated into OpenShift Routes.

What to look for:

Containers configured to run as root
Privileged containers
Host path volume usage
Host networking dependencies
Ingress resources that will need conversion to OpenShift Routes

IBM Cloud's OpenShift enforces security context constraints by default, automatically blocking several of these patterns. This assessment prevents avoidable deployment failures.

Step 2: Adapt Container Images for Non-Root Execution

OpenShift's restricted SCC requires containers to run as non-root users. Review your container images and update them so the application can start without root privileges, write only to appropriate directories, and run with the minimum permissions it actually needs.

Typical changes include creating or using a non-root user in the image, adjusting file ownership for application directories, and removing assumptions that the container can write anywhere in the filesystem. After those changes are made, rebuild and push the updated images to your registry. IBM Cloud's integrated image registry can be used, but external registries work equally well.

Step 3: Create OpenShift Project and Configure Access

Connect to the target IBM Cloud OpenShift cluster, confirm that your CLI context is pointed to the correct environment, and create the project or namespace that will contain the migrated application. If you are using a private image registry, also create or attach the image pull credentials needed for your workloads to retrieve their images successfully.

OpenShift projects provide additional isolation and RBAC controls beyond Kubernetes namespaces. IBM Cloud manages the underlying namespace lifecycle automatically.

Step 4: Deploy Database with Persistent Storage

Create a StatefulSet for PostgreSQL, or adapt the equivalent stateful resource pattern your database requires, with persistent storage, a dedicated service, and secrets for credentials. The database configuration should include resource requests and limits, explicit storage requirements, and security settings that are compatible with OpenShift's restricted defaults.

When preparing the deployment, make sure the database uses a storage class supported by your IBM Cloud environment, that credentials are provided through secrets rather than embedded values, and that the pod security settings reflect the least privilege the database can operate with.

Key OpenShift differences:

IBM Cloud storage classes use managed provisioners, so persistent volumes can be created and attached without manual setup
Security settings should explicitly support non-root execution and minimal capabilities
Stateful workloads should be reviewed carefully for filesystem ownership and persistence expectations before cutover

Step 5: Deploy Backend API Service

Create a deployment for the backend API with externalized configuration, secret-based database credentials, health checks, and security contexts aligned to OpenShift defaults. The service should expose the backend internally so the frontend and other approved workloads can reach it consistently.

As you adapt the backend deployment, confirm that the application can discover its database and dependent services through cluster-native service names, that health endpoints reflect real readiness, and that resource settings are appropriate for the expected traffic profile.

OpenShift automatically enforces the security context constraints. IBM Cloud's managed control plane handles pod scheduling and health monitoring without additional configuration.

Step 6: Deploy Frontend and Create Route

Create a deployment and service for the frontend, then expose it using an OpenShift Route. The frontend configuration should point to the correct backend endpoint for the target environment and should keep environment-specific values outside the container image whenever possible.

When defining the route, decide how TLS termination and hostname management should be handled for your application. In most migrations, the key change is moving from a generic ingress pattern to OpenShift's route-based exposure model.

OpenShift Routes vs Kubernetes Ingress:

Routes are OpenShift's native ingress mechanism
IBM Cloud's managed router handles TLS termination as part of the platform experience
There is less need to separately configure ingress infrastructure for common exposure patterns
Routes align cleanly with OpenShift's built-in application exposure model

Step 7: Configure Network Policies

Implement network segmentation using OpenShift-compatible NetworkPolicy resources so that only the necessary application tiers can communicate with one another. At a minimum, the backend should accept traffic only from approved frontend or internal service sources, and the database should accept traffic only from the backend or other explicitly permitted workloads.

As you define these policies, keep the rules aligned to actual application flows rather than broad namespace-wide access. This makes the migration more production-ready and reduces the risk of carrying overly permissive networking patterns into the target environment.

IBM Cloud's OpenShift enforces these policies at the SDN level without requiring additional CNI plugins or configuration.

Validation and Observability

Verify Application Health

After deployment, review the full application state in the project to confirm that expected resources are present and healthy. Verify that pods are running without repeated restarts, persistent storage is bound correctly, the database is reachable from the backend, and the frontend route responds as expected from the client side.

Access Built-in Monitoring

OpenShift includes integrated monitoring via Prometheus and Grafana. IBM Cloud's managed OpenShift includes this monitoring stack pre-configured—no need to install Prometheus Operator or configure service monitors manually.

Use the OpenShift web console and built-in observability views to review metrics for the migrated workload. Focus on container resource usage, restart behavior, and namespace-level trends that indicate whether the deployment is stable under expected operating conditions.

Review Logs

Review application logs for the backend, frontend, and database tiers to identify startup failures, connectivity issues, or permission-related errors. If centralized logging is enabled in your environment, use the OpenShift console to compare pod-level logs with broader platform events during the migration window.

Validate Security Posture

Review the security context constraints applied in the target cluster and confirm that the migrated pods are running under the expected security posture. This should include checking that workloads are not requesting unnecessary privileges and that the effective pod security settings match the assumptions you validated earlier in the migration process.

What This Demonstrates About IBM Cloud + OpenShift

This migration tutorial reveals several operational advantages of IBM Cloud's managed OpenShift:

Reduced Configuration Overhead:

Storage provisioning happens automatically via IBM Cloud storage classes—no manual PV creation or storage driver installation
TLS certificates for Routes are managed by the platform—no cert-manager configuration required
Integrated monitoring and logging are pre-configured—no Prometheus Operator or EFK stack deployment needed

Red Hat Alignment:

Security context constraints enforce Red Hat's security best practices by default
OpenShift Routes provide native ingress without third-party controllers
Integrated image registry and build pipelines follow Red Hat's recommended patterns

Operational Maturity:

Control plane is fully managed—no etcd backups, API server upgrades, or scheduler tuning required
Node lifecycle management is automated—patching and version upgrades happen without manual intervention
Network policy enforcement is built into the SDN—no additional CNI plugin configuration

Enterprise Support Readiness:

IBM Cloud support handles infrastructure issues while Red Hat support covers OpenShift platform issues
Clear responsibility boundaries reduce escalation complexity
Integrated tooling means fewer vendor integrations to maintain

The migration process itself becomes simpler because IBM Cloud handles the operational complexity of running OpenShift, allowing teams to focus on application-level concerns rather than platform management.

Key Takeaways & Conclusion

Migration Success Factors:

Assess workloads for OpenShift compatibility before migration—security context constraints are non-negotiable
Adapt container images to run as non-root users—this is required, not optional
Use OpenShift Routes instead of Kubernetes Ingress for simpler TLS management
Leverage IBM Cloud's storage classes for automatic persistent volume provisioning
Implement network policies early to establish security boundaries

When IBM Cloud OpenShift Fits:

Teams need managed control plane and automated lifecycle management
Organizations require Red Hat support alignment for enterprise workloads
Projects benefit from integrated monitoring, logging, and security tooling
Operational teams want to minimize platform management overhead

Operational Outcome:
IBM Cloud's managed OpenShift reduces migration complexity by handling infrastructure concerns automatically. Teams can migrate workloads without configuring storage provisioners, certificate managers, or monitoring stacks—these are included and maintained by the platform. This allows faster time-to-production and reduces the operational expertise required to run OpenShift at scale.

Next Steps: