Customer Story · Telecom

Docomo lifts 1,300+ Windows apps onto EKS without touching source code.

Industry Telecom Cloud AWS Outcome Speed
65%
Faster than the projected schedule — six months against an 18-month estimate — with operational costs down 55% and not a line of application source code rewritten.
At a glance
Challenge
A data-center exit forced by a lease expiry, against 1,300+ mission-critical apps on 2,500 VMs — with no mandate to rewrite source code or pause operations.
Approach
CHAI DART ran agentless WinRM discovery and dependency mapping; CHAI Flow built Windows containers and generated the Kubernetes blueprints for Amazon EKS.
AWSAmazon EKSWindows ContainersAmazon ECRElastic Load Balancing
Result
65% faster modernization

Want the full success story?

The full success story — architecture details and measurable outcomes.

CHAI by CloudHedge — Agent View
/success-stories/docomo-windows-containers-eks/
# Telecom Customer Story — 65% faster modernization

**Industry:** Telecom
**Cloud:** AWS
**Outcome:** 65% faster modernization

## Summary
A data-center exit on a lease deadline: 1,300+ apps across 2,500 VMs containerized onto Amazon EKS in six months, with zero source-code changes.

## The Challenge
Docomo pioneered W-CDMA and runs an international mobile commerce platform — the kind of estate where mission-critical is a literal description rather than a category label. That estate was 1,300+ applications spread across 2,500 virtual machines, largely .NET on Windows Server, accumulated over years of platform growth.This was a data-center exit rather than an opportunistic migration, and that distinction set every constraint that followed. A lease was expiring, which turned the move from a roadmap item into a fixed date. And the existing footprint could not scale — capacity was pinned to provisioned VMs in racks that were about to stop being available.What made it hard was the pair of things the business ruled out. There would be no source-code rewrite — 1,300 applications is not a refactoring programme anyone finishes before a lease runs out. And there would be no disruption to a live commerce platform. The projected timeline for doing this conventionally was 18 months. The lease did not offer 18 months.

## The Solution
CloudHedge treated the estate as a discovery problem before it treated it as a migration problem. At 1,300 applications, the expensive failure mode is not moving a workload badly — it is not knowing what a workload actually depends on until it breaks in the new environment.CHAI DART ran agentless discovery over WinRM, connecting to the Windows fleet with no software installed on any target server. It collected services, configuration files, dependencies, and runtime characteristics, then produced application dependency graphs — the relationships between applications, services, and infrastructure that no inventory spreadsheet contained. Metadata stayed on-premises in the CloudHedge Enterprise Server rather than leaving the customer estate.DART then rationalized and grouped the applications by dependency, usage pattern, and business criticality. That clustering is what made 1,300 applications schedulable: they moved as dependency-complete groups in a prioritized sequence, not as 1,300 individual projects.Transformation ran through CHAI Flow. BuildBox packaged each application into a Windows container image — lifting the application and its runtime dependencies as-is, which is precisely why no source code had to change. Images were built, tested, and pushed to Amazon ECR. Flow generated the Kubernetes blueprints for each workload — Deployments, Services, and Ingress rules — and deployed them into Amazon EKS clusters with Windows node groups, with Elastic Load Balancing fronting the services that needed external endpoints. Deployment was wired into continuous delivery pipelines, so the same path that carried the migration carries every release since.

## The Outcome
The migration completed in six months against an 18-month projection — 65% faster. That is the number that mattered, because the deadline was a lease expiry rather than an internal target: the alternative to hitting it was paying to extend a data center the company had already decided to leave.Operational costs fell 55%. Containers on EKS pack many workloads onto shared, right-sized nodes where the previous model dedicated a virtual machine to each — so the saving is structural, a consequence of the density change rather than a negotiated rate.Zero source-code changes across 1,300+ applications. Windows containers preserved each application's runtime contract, which kept the migration out of the development backlog entirely: no regression-test cycle per app, no feature freeze, no rewrite risk priced into the timeline.What Docomo runs now is a Kubernetes platform with continuous delivery attached, not a lift-and-shift that landed and stopped. The applications are containerized and orchestrated, capacity scales with demand instead of with procurement, and the runway to refactor individual services is open — on the platform's schedule rather than a landlord's.Published as a case study on the AWS Modernizing with AWS blog.


## Stack
- AWS
- Amazon EKS
- Windows Containers
- Amazon ECR
- Elastic Load Balancing
- Kubernetes
- WinRM
- CHAI DART
- CHAI Flow
- CHAI Universe
- .NET Framework
- Windows Server
- CI/CD



## Contact
Book a demo: /contact/
Email: hello@cloudhedge.io