Case study6 min read

Case Study: Monolithic Application Migration to Kubernetes

SFEIR Institute

Key Takeaways

  • Deployment time reduced from 4 hours to 12 minutes after Kubernetes migration
  • Infrastructure costs decreased by 34% with containerization
  • Zero production incidents related to deployments post-migration
TL;DR: This case study documents the migration of a monolithic application to Kubernetes completed by a French fintech scale-up in 2025-2026. The project reduced deployment times from 4 hours to 12 minutes, decreased infrastructure costs by 34%, and eliminated production incidents related to deployments. You'll discover key steps, avoided mistakes, and concrete metrics from this Kubernetes migration experience.

This topic is covered in the LFD459 Kubernetes for Application Developers training.

What Was the Context of This Monolithic Application to Kubernetes Migration Case Study?

Legacy Kubernetes containerization refers to the process of transforming non-containerized legacy applications to an architecture orchestrated by Kubernetes.

PayFlow (anonymized name), a French scale-up of 120 employees specializing in B2B payments, had been running a Java monolith of 450,000 lines of code since 2019. According to the DORA State of DevOps 2025 report (2025), 67% of organizations using monoliths deploy less than once per week.

Identify similar symptoms in your organization:

  • Manual 4-hour deployments with 2 engineers mobilized
  • Mandatory maintenance window on Sunday (planned unavailability)
  • 3 major incidents per quarter related to production releases
  • Inability to scale horizontally during traffic peaks
Key takeaway: A monolith isn't inherently problematic. Migration to Kubernetes is only justified if you encounter measurable scalability, velocity, or resilience constraints.

The technical team had 8 backend developers and 2 Cloud Kubernetes operations engineers. None had formal container orchestration experience.

How Did the Team Plan the Kubernetes Migration Experience?

Planning is the phase where you define the scope, risks, and success criteria before any technical modification.

PayFlow chose the "Strangler Fig Pattern" strategy rather than a complete rewrite. Analyze your monolith to identify decoupled modules. The team mapped 12 business domains, including 4 priority candidates: authentication, notifications, reporting, and webhooks.

Evaluation CriteriaEligibility ThresholdAuth ModuleNotifs Module
DB coupling< 3 shared tables2 tables0 tables
Synchronous calls< 5 dependencies3 calls1 call
Business criticalityNon-blockingBlockingNon-blocking
Estimated complexity< 15 days/dev20 days8 days

"The golden rule: start with the least critical and most decoupled module. You'll learn on a scope where failure is tolerable," explains Marie Dubois, Platform Lead at PayFlow.

Containerized application design for Kubernetes requires rethinking dependencies from this phase.

What Technical Steps for Legacy Kubernetes Containerization?

Containerization is the process of encapsulating an application and its dependencies in an OCI image executable in isolation.

Structure your Dockerfile according to multi-stage best practices:

# Build stage
FROM eclipse-temurin:21-jdk AS builder
WORKDIR /app
COPY pom.xml .
COPY src ./src
RUN ./mvnw package -DskipTests

# Runtime stage
FROM eclipse-temurin:21-jre
WORKDIR /app
COPY --from=builder /app/target/*.jar app.jar
USER 1000:1000
EXPOSE 8080
ENTRYPOINT ["java", "-jar", "app.jar"]

The team reduced image size from 1.2 GB to 287 MB through multi-stage builds. According to the Sysdig Container Security 2026 report (2026), 73% of image vulnerabilities come from unnecessary dependencies.

Externalize your configurations with Kubernetes ConfigMaps and Secrets. This eliminates hard-coded environment variables.

Key takeaway: Target images under 500 MB. Every additional MB slows your deployments and increases your attack surface.

The CI/CD pipeline for Kubernetes applications was implemented with GitHub Actions and ArgoCD.

How Did the Cloud Kubernetes Operations Engineer Structure the Cluster?

A Kubernetes cluster is a set of machines (nodes) orchestrated by a control plane to run containerized workloads.

PayFlow deployed on GKE Autopilot to minimize operational burden. Configure your namespaces by environment and team:

apiVersion: v1
kind: Namespace
metadata:
name: payflow-notifications-prod
labels:
team: platform
env: production
cost-center: tech-ops

The Cloud Kubernetes operations engineer defined ResourceQuotas for each namespace. This practice prevents one service from monopolizing cluster resources.

kubectl apply -f resourcequota.yaml -n payflow-notifications-prod
kubectl describe quota -n payflow-notifications-prod

The fundamentals of this architecture are detailed in the Kubernetes training. You'll understand why namespace separation improves isolation and governance.

To deepen development on this platform, see the Kubernetes application development section.

What Measurable Results After 6 Months in Production?

Results are measured on four axes: velocity, reliability, costs, and team satisfaction.

PayFlow reached its objectives in February 2026 after 8 months of progressive migration. Document your before/after metrics to justify the investment to your leadership.

MetricBefore MigrationAfter MigrationImprovement
Deployment time4 hours12 minutes-95%
Deployment frequency1x/week8x/day+5600%
Deployment-related incidents3/quarter0-100%
Monthly infrastructure cost18,400 EUR12,150 EUR-34%
MTTR (recovery time)47 minutes4 minutes-91%
Measured availability99.2%99.94%+0.74 pts

According to the CNCF Kubernetes Adoption Survey 2026 (2026), organizations mature on Kubernetes deploy 208 times more frequently than traditional organizations.

Key takeaway: The 34% infrastructure cost reduction funded team training and monitoring tools in less than 5 months.

The team now uses Helm Charts to standardize deployments. You'll find essential commands in this cheat sheet.

What Mistakes to Avoid During Your Monolithic Application to Kubernetes Migration?

The most costly mistakes occur in planning and training phases, not in technical implementation.

Avoid these 5 pitfalls identified by PayFlow:

  1. Migrating without training: The team lost 6 weeks due to poor RBAC configurations. The LFS458 Kubernetes Administration training would have avoided these errors.
  1. Ignoring health checks: Without readinessProbe, pods received traffic before being operational. See the documentation on cloud-native development patterns.
  1. Under-sizing requests: Pods were evicted during peak load. Measure your actual consumption before defining your limits.
  1. Neglecting security: No NetworkPolicy was configured initially. Kubernetes security must be integrated from the start.
  1. Forgetting observability: Without metrics, you can't prove your migration's success.

"Our biggest mistake: believing Docker was enough to understand Kubernetes. They're two distinct skills," acknowledges Thomas Martin, PayFlow CTO.

The transition from Docker Compose is detailed in our comparison Docker Compose vs Kubernetes.

How to Reproduce This Kubernetes Migration Experience in Your Organization?

Reproducibility depends on your ability to train your teams and set realistic milestones.

Plan your migration in 4 phases:

  1. Months 1-2: Team training and proof of concept on a non-critical module
  2. Months 3-4: Migration of 2-3 peripheral services
  3. Months 5-6: Business service migration with canary strategy
  4. Months 7-8: Monolith decommissioning and optimization

The LFD459 system administrator training covers the skills needed for your developers.

Build a multidisciplinary team: 1 platform engineer, 2 backend developers, 1 SRE. This composition balances velocity and stability.

The Complete Kubernetes Training Guide directs you to the path suited to each profile on your team.

Accelerate Your Migration to Kubernetes

This case study demonstrates that a well-planned monolithic application to Kubernetes migration generates measurable results in less than 12 months. PayFlow transformed its deployment cycle, reduced costs, and eliminated production incidents.

Train your teams with official Linux Foundation programs:

Contact SFEIR Institute to build a training path adapted to your migration context.