Let's start with a story: An enterprise customer invests heavily in Red Hat OpenShift to establish a modern, secure container platform. Shortly thereafter, they purchase a critical business application from a third-party software vendor who promises "out of the box" support for OpenShift. But this customer quickly discovers that either their internal engineering teams lack the OpenShift skills required to deploy and maintain this specific workload, or the vendor's definition of "out of the box support" falls short of reality. Consultants like myself are brought in to bridge the divide, unifying the enterprise platform with third-party software to create a reliable, secure, and maintainable solution.
The pitfalls
I have found third-party vendors regularly stumble in the same places when adapting their software to an enterprise containerized environment. Not every vendor makes the same mistakes, but each of these have come up more than once.
Virtual machines lifted-and-shifted to containers
I frequently encounter applications originally built for web servers running on a legacy virtual machine (VM) that have been packaged directly into a container image without underlying architectural changes. Vendors often assume that because an application compiles inside a container, they can claim Kubernetes support. The customer, and sometimes the vendor, refer to it as "cloud native" without necessarily being able to define what that means.
However, these containerized applications retain tight interdependencies between pods at startup, carry liveness probes that don't reflect actual application state, and lack support for dual-site deployments (more on this later) or rolling updates. Getting support from the vendors is challenging, as they wrestle with the application servers they're used to and the platform they're now trying to run on.
Another side effect particular to ported web or application servers is in resource consumption. Where previously several applications were deployed to the same server, the containerized solution delivered by the vendor is one pod—one application. The overhead of running the server is then duplicated for each application and each replica. This can quickly inflate the resource consumption on the cluster, pushing up the associated hardware and licensing costs for the customer.
Multi-tenancy
The single most common issue and biggest technical hurdle I encounter stems from vendors failing to test or design their deployments for a multi-tenant environment. In order to run their applications, vendors frequently assume they will be granted full cluster access and unrestricted control over the platform.
In practice, this manifests as demands for unbound access to the cluster:
- cluster-admin privileges
- cluster-scoped roles with wildcard permissions (
*,*,*) that grant access to every resource on the cluster - unrestricted
anyuidorprivilegedsecurity context constraints (SCC).
SCCs define the set of conditions and permissions a pod must run with in order to be accepted into the system. By default, OpenShift applies the restrictive restricted-v2 SCC to enforce the principle of least privilege, preventing containers from running as root or accessing host-level resources unless explicitly granted higher permissions. The privileged SCC is the most risky, effectively allowing workloads to elevate privileges up to the equivalent of cluster administrators with full access to everything on the platform.
In other cases, there is the expectation that workloads can run without resource limits. The limits exist to prevent any one workload from unexpectedly consuming more memory or compute than was planned for. In dedicated clusters, or for mature workloads, the need for resource limits is lower: The application has been thoroughly stress tested or the potential impact is limited only to itself. In a multi-tenant cluster, a workload under stress with a memory leak can quickly affect the ability for others to operate.
In a multi-tenant enterprise cluster, scope must be strictly limited to reduce the overall blast radius in the event of a security incident or resource-intensive outage. If the workload were running on a VM, you wouldn't give it unrestricted access to your hypervisor, and the same applies here.
Parallel environments and upgrades
Another barrier is the inability of multiple parallel deployments of vendor solutions to co-exist within the same cluster. A standard architectural pattern among my enterprise clients is maintaining a shared non-production OpenShift platform hosting development, testing, and staging environments side by side.
Even when vendors claim parallel support, I often discover that it has not been thoroughly tested. Where a product relies heavily on cluster-scoped resources, it frequently fails to support concurrent installations representing different lifecycle environments. When an update is released, clients are unable to upgrade individual non-production environments independently.
Multi-cluster, failover, and storage dependencies
As enterprise architectures transition away from stretched clusters toward multi-cluster topologies, legacy application approaches to resilience break down. Some applications cannot handle multiple instances running concurrently, unaware of each other. Many vendor products rely on direct network visibility or legacy shared storage (such as expecting unmanaged NFS behavior across host nodes) rather than utilizing modern, cloud-native storage solutions like Red Hat OpenShift Data Foundation (ODF), which abstracts and dynamically provisions storage based on precise access modes:
ReadWriteOnce(RWO): Delivers low-latency block storage (backed by Ceph RBD) attached to a single pod, ideal for databases or stateful applications with native cluster replication.ReadWriteMany(RWX): Provides a resilient, cluster-wide shared filesystem (backed by CephFS) allowing multiple pods across different nodes to simultaneously read and write data without relying on external, unmanaged file servers.
Legacy vendor applications frequently misuse these modes, demanding RWX for simple static data because they haven't decoupled application state.
When deployed across separate clusters, these applications struggle with site-to-site failover. They often require complex, manual failover procedures, full workload shutdowns in Site A before initializing in Site B, and manual interventions to clear stale state.
Manual operations and scripts
Vendor installation guides frequently mirror procedural documentation from the VM era. Operators are instructed to manually download files, modify local variables, and execute imperative shell scripts from a local workstation. Vendor support often resists declarative, GitOps-driven delivery pipelines (such as OpenShift GitOps or ArgoCD) or modern Kubernetes Operator patterns.
Requires cluster-admin / privileged SCC
- Reality: Multi-tenant namespace isolation & mandatory non-root execution
- Impact and risk: Violates compliance; expands cluster blast radius
Relies on cluster-scoped resources
- Reality: Multiple parallel environments (Dev, Test, QA) on shared platforms
- Impact and risk: Prevents independent non-prod testing & upgrades
Imperative deployment scripts
- Reality: Declarative GitOps (ArgoCD) and Operator lifecycles
- Impact and risk: Manual overhead, drift, and unreliable deployments
Legacy NFS / shared host paths
- Reality: Dynamic cloud-native PV provisioning via OpenShift Data Foundation
- Impact and risk: Storage bottlenecks, poor elasticity, failover failures
How to avoid the pitfalls
Begin by critically evaluating the requirement before addressing technical details. Engage both the customer and the software vendor with key initial questions: Is this third-party product truly necessary, and does it strictly need to run on OpenShift?
In many enterprise environments, organizations attempt to onboard legacy software that offers none of the benefits of a modern cloud-native platform while inheriting all the operational risks. Identifying these constraints during the initial product-evaluation stage allows the team to address potential deal-breakers early and establish realistic mitigation strategies before deployment begins.
Architecture and packaging
- Is the application packaged for declarative management using Kubernetes operators, Helm charts, or standard Kubernetes manifests compatible with OpenShift GitOps (ArgoCD)?
- Does the delivery model support fully disconnected and air-gapped environments and private mirror registries?
Multi-tenancy
- What specific security context Constraints (SCCs) and Linux capabilities are strictly required by your containers?
- What specific ServiceAccounts, namespace-scoped roles, and cluster-level RBAC permissions (including deployment of cluster-scoped resources) does the deployment demand?
- What are the resource requirements under load for a production deployment?
Parallel environments and upgrades
- What is the upgrade procedure?
- Can multiple instances of the application co-exist on the same cluster? If so, how does this affect the upgrade procedure?
Multi-cluster and failover
- How is application high availability (HA) managed (for example, native pod replication, StatefulSets, or custom logic)?
- Can the application support concurrent active-active or active-passive deployment across separate physical OpenShift clusters? If not, what's the failover procedure?
Storage
- What are the precise persistent volume (PV) storage requirements (RWO vs. RWX, latency sensitivity, ODF/Ceph compatibility)?
Lifecycle and governance
- Which specific versions of Red Hat OpenShift is the current product release certified against?
- What is the vendor's SLA for patching base container images following critical CVE disclosures?
Additionally, refer to the Twelve-Factor App definition. Does the vendor solution conform to that standard? Outline where the application does align, where it doesn't and why not.
Delivering a solution
Navigating these engagements requires a balanced combination of rigorous technical execution and thoughtful customer management. These are some strategies I've found effective, and some suggestions for activities that would have helped if we had the opportunity.
Early architectural alignment
Establish a formal pre-deployment review involving vendor engineering, customer operations, and Red Hat consultants. Define clear operational boundaries between platform management and vendor application support.
Strict security baselines
Enforce non-root execution early and sandbox vendor workloads within well-defined SCC policies. If this is not possible and the customer wants to proceed, they need to be made well aware of the risks.
Standardize on GitOps and automation
Translate all manual installation procedures into declarative Helm charts or Kubernetes manifests. Store all configurations in version control to drive consistent, automated deployments with OpenShift GitOps.
If the vendor is supplying Helm charts as part of their application releases, package and publish these to the customer's artifact repository and include them as dependencies in your own deployments or parent Helm charts. When new releases are published by the vendor, all that's required is a dependency version update in your own deployment or parent Helm chart. If there is an issue to be investigated with the vendor it is clear what, if anything, has been added beyond what was originally shipped.
Editing vendor Helm charts may be more direct, but the customer must then maintain this amended code base for the entire lifespan of the application. The vendor may no longer be able to support the deployment effectively if the customer deviates too far from the original build.
Soft skills, managing expectations, and sustainable handover
These technical challenges present a true test of a consultant's soft skills. Managing relationships with customers who have already paid for a "Kubernetes-ready" solution — and are now paying Red Hat Services to make it work — requires empathy and clear communication.
When delivering difficult news regarding vendor software limitations, keep feedback strictly evidence-based. Articulate the exact platform requirement, document the problem transparently, and suggest constructive remediations that benefit all parties involved.
Finally, keep the customer engineering team that will own the solution long after the consulting engagement ends top of mind. Red Hat Services are often brought in due to internal skills gaps. We knowledge-share with and upskill our partners in the customer teams, but the reality is we have years of experience in this field where they may have none. If the architecture is overly complex, the engineering team will struggle to operate, upgrade, and maintain it. Our goal is to leave behind a clean, maintainable platform that the customer can manage with confidence.
Key takeaways
Successfully deploying third-party vendor applications on Red Hat OpenShift requires proactive engagement, firm platform standards, and early architectural alignment. By establishing clear security boundaries, enforcing GitOps automation, and asking the right technical questions upfront, enterprise teams can transform complex vendor deployments into predictable, repeatable successes.
- Challenge assumptions: What we hear from the customer (and sometimes the vendor themselves) about the third party software may not be accurate
- Customer-centric delivery: Ensure that the customer and their engineering team are at the heart of the solution
- Lead by example: Show through our own delivery the standards that need to be met
I encourage platform architects, consultants, and enterprise IT leads to share these baseline requirements with procurement and enterprise vendors during the initial procurement phase, long before the software hits your clusters.
Learn more about what makes a successful cloud-native application and organisation with the Accelerate your path to cloud-native applications e-book and find out how Red Hat Services can help you get there.
