![]()
Roughly 96% of companies are using or evaluating Kubernetes. Yet, around 65% of businesses still operate on legacy infrastructure. Legacy system modernization requires courage and the right strategy. This guide offers a structured, actionable path forward.
The Legacy Paradox
Legacy .NET Framework and Java EE apps power critical business operations. They’re also held together by undocumented dependencies, stateful sessions, and tribal knowledge. McKinsey research shows organizations burning 20-40% of their IT budget maintaining legacy systems and technical debt.
The real cost isn’t the maintenance. It’s the opportunity cost of staying put.
Phase 1: Assess and Discover – Know What You’re Dealing With
Before touching a single Dockerfile, map your landscape.
Use Gartner’s TIME model (Tolerate, Invest, Migrate, Eliminate) combined with AWS’s 7 Rs (Rehost, Replatform, Refactor, etc.) to categorize each application. Some apps should be retired instead of being moved to Kubernetes.
Legacy systems conceal dependencies in ways formal documentation never covers. Expect the unexpected.
Key dependency traps to look for:
For .NET Framework apps:
- Windows Registry dependencies;
- COM/COM+ components (non-portable to .NET Core);
- Global Assembly Cache (GAC) usage;
- WCF with System.Web, which has no full equivalent in .NET Core;
- MSMQ and Windows Authentication (Kerberos/NTLM).
For Java EE/J2EE apps:
- Stateful EJBs;
- RMI (a port management nightmare in Kubernetes);
- JNI calls to native libraries;
- Hard-coded file system paths;
- Custom ClassLoaders.
Discovery tools worth using:
|
Tool
|
Best For
|
|
Microsoft .NET Upgrade Assistant
|
.NET Framework → .NET 8 compatibility analysis
|
|
Red Hat Migration Toolkit for Applications
|
Java EE modernization assessment
|
|
IBM Cloud Transformation Advisor
|
WebSphere-specific migrations
|
|
Azure Migrate
|
Dependency mapping across the estate
|
Phase 2: Containerization Strategy – From VM to Image
Three paths exist. Pick based on risk tolerance and ROI targets:
- Lift and Shift (Rehost): Minimal changes. Fast. But you carry all legacy baggage into the container. Lowest risk, lowest reward.
- Replatform: Externalize config, fix session state, make it stateless. This is the sweet spot for most legacy migrations.
- Refactor: Rearchitect to microservices. Highest ROI, highest effort. Worth it for apps with long futures.
The Windows Container Problem (.NET Framework)
If your .NET framework app can’t be ported to .NET 6+, you’re locked into Windows containers. Windows nodes in Kubernetes run Windows containers only. Linux pods and Windows pods don’t mix on the same node.
The cost implication is significant:
- mcr.microsoft.com/windows/servercore ≈ 4GB+
- .NET Framework 4.x runtime image ≈ 7-8GB
- Compare to .NET 8 on Linux Alpine ≈ ~100MB
Larger images imply slower pull times, higher storage costs, and more expensive Windows node licensing. Factor this into your cloud budget before committing.
Taming the JVM in Containers
Java in containers has JVM heap sizing. An this is a notorious pitfall. Before Java 8u191, the JVM ignored cgroup memory limits. It read host RAM instead, then Kubernetes killed the pod when it exceeded its container limit. OOMKills everywhere.
Java 8u191+ and Java 11+ enable UseContainerSupport by default. This makes the JVM respect cgroup limits. Always verify your Java version before containerizing.
Additional Dockerfile best practices for Java:
- Use JRE not JDK in your final image (cuts image size ~50%).
- Set -XX:MaxRAMPercentage=75.0 instead of fixed -Xmx values, which scales dynamically with pod memory limits.
- Use multi-stage builds to keep build tools out of production images.
- Use Google’s distroless Java base (~200MB) instead of full JDK images (~700MB+).
Phase 3: Kubernetes Configuration – The First Flight
Getting the app containerized is half the battle. Getting it stable on Kubernetes is the other half.
Session State: The #1 Technical Blocker
In-process session (InProc ASP.NET, HttpSession in Java EE) breaks immediately when you run multiple pod replicas. Kubernetes load-balances across all pods. Your user’s session data lives in one pod and disappears on the next request.
Solutions:
- ASP.NET: Migrate to SQL Server session state provider or Redis (Azure Cache for Redis / AWS ElastiCache).
- Java EE: Use Spring Session with a Redis or JDBC backend, or Hazelcast/Infinispan for distributed cache.
- Best path: Redesign to stateless JWT-based auth, which eliminates the problem entirely.
Resource Management
Kubernetes evicts pods when they exceed memory limits. It wastes cluster resources when limits are set too high. Getting this right pays off.
- Set requests accurately. This is what the scheduler uses to place your pod.
- Set limits conservatively higher. This is the ceiling before eviction/throttling.
- For Java apps, use Vertical Pod Autoscaler (VPA) before HPA. JVM heap doesn’t shrink easily, so horizontal scaling triggers are unreliable until memory is properly profiled
Health Probes for Slow-Starting Legacy Apps
Large Java EE application servers (WebSphere, JBoss) take 60-120 seconds to start. Liveness probes will kill your pod before it finishes booting without startup probes (available since Kubernetes 1.16).
Configure startup probes with a generous failureThreshold × periodSeconds window. Only after the startup probe passes should liveness probes activate.
Other critical configurations:
- Replace web.config and application.properties with Kubernetes ConfigMaps and Secrets.
- Use External Secrets Operator or HashiCorp Vault Agent Injector for enterprise-grade secret management.
- Map legacy local disk writes to PersistentVolumeClaims. Use ReadWriteMany StorageClass if multiple pods need shared file access.
Phase 4: Observability and Security – Trust What You Can See
The Three Pillars for Legacy Apps
- Metrics: Prometheus + Grafana (both CNCF graduated projects). For Java, use the JMX Exporter to bridge legacy MBeans to Prometheus metrics. For Windows/.NET Framework, use windows-exporter.
- Logs: Legacy apps writing to Windows Event Log or flat files need sidecar containers or DaemonSet-level collectors (Fluent Bit supports Windows log sources since 2020).
- Traces: OpenTelemetry’s Java Auto-Instrumentation Agent adds distributed tracing to legacy Java apps with zero code changes. Attach the agent as a JVM argument. Invaluable when source code is untouchable.
Security: Fix RBAC First
Red Hat’s 2023 State of Kubernetes Security report identifies insufficient access controls as a top concern (30%), with misconfiguration incidents being a persistent problem across Kubernetes deployments. Fixing RBAC early prevents the most common security failures.
Enforce these immediately:
- Apply Pod Security Standards, enforcing restricted or at a minimum baseline profiles.
- Never run containers as root (most legacy apps default to root, and this must change).
- Integrate Trivy into your CI/CD pipeline for container image vulnerability scanning.
Phase 5: Optimize and Future-Proof
Average Kubernetes clusters run at 12-15% CPU utilization despite allocated capacity. You’re paying for idle nodes.
Use Goldilocks (open source, FairwindsOps) to get VPA-based resource recommendations per workload. Use Spot/Preemptible nodes for non-critical workloads. Savings range from 60-90% on node costs.
GitOps for Predictable Deployments
Helm is used by 70%+ of Kubernetes users for application packaging. Pair it with Argo CD or Flux for declarative, Git-driven deployments. Every change is versioned, auditable, and rollback-ready.
Emerging trends worth watching:
- Java 21 Virtual Threads: GA since September 2023. Thread-per-request models now scale without memory overhead, and Spring Boot 3.2+ supports them natively. Fewer replicas, different resource profiles.
- eBPF-based observability (Cilium, Pixie): Instruments networking and app behavior without sidecar containers.
- Platform Engineering / IDPs: Gartner predicts 80% of large enterprises will have an Internal Developer Platform by 2026. Tools like Backstage abstract Kubernetes complexity away from dev groups entirely.
The Anti-Patterns That Kill Migrations
Roughly 75% of cloud migrations ran over budget, with 37-38% running behind schedule. Most failures come down to avoidable mistakes.
Technical anti-patterns to eliminate on the first day:
- Running containers as root;
- Hardcoding environment values in images (violates 12-factor app Principle III);
- Omitting resource limits, which causes noisy neighbor problems cluster-wide;
- Using latest image tag in production: non-deterministic, untraceable;
- Single-replica stateful deployments without PVCs;
- Missing PodDisruptionBudgets, which guarantees downtime during node maintenance.
According to the CNCF 2025 Annual Survey, the top challenges for cloud-native adoption include cultural changes with the development group (47%), lack of training (36%), and security (36%). Structure your migration around these constraints.
