Containerize during migration: Replatform applications to containers with AWS Transform
AWS Transform can containerize legacy Java and .NET workloads during lift-and-shift with 60-70 % less effort than manual rewrites, cutting migration timelines from 12 months to 4-6 weeks for 60 % of surveyed enterprises (AWS re:Invent 2024 data). By orchestrating this change through Amazon ECS or EKS, Southeast Asian companies reduce post-migration TCO by 23 % on average while gaining elastic scale.
Why containerise *during* migration instead of before or after?
Containerising mid-migration shortens the critical path: teams refactor once and land on a cloud-native stack immediately, avoiding the 2-3 “double-work” cycles observed when refactoring is postponed (McKinsey Cloud Survey 2025). AWS Transform automates the heavy lifting—parsing application artefacts, generating Dockerfiles, and wiring in IAM roles—so the same migration team can hit go-live dates 30 % earlier.
Cost of delay: the re-platform tax
- 45 % of delayed re-platforming projects exceed budget by 2× because of duplicated testing and security reviews (Gartner 2024).
- Every additional quarter on VMs raises licensing overhead for Windows/SQL by 9 % (Flexera 2025 State of the Cloud).
- AI workloads (see our post on agentic AI workflows) require GPU-accelerated containers; retrofitting later adds 4-6 weeks of infra re-provisioning.
What exactly does AWS Transform automate?
AWS Transform is a managed service that ingests application binaries (WAR, JAR, MSI), reverse-engineers dependencies, and emits production-ready ECS task definitions or EKS Helm charts in under 90 minutes per application (AWS internal benchmarks across 200 migrations). It embeds AWS best-practice security baselines—including Secrets Manager integration, IAM least-privilege policies, and VPC endpoint routing—so ops teams inherit compliance out-of-the-box.
Anatomy of an automated transformation run
- Discover: Application Discovery Agent maps process-level dependencies and ports.
- Analyse: Machine-learning rules classify frameworks (Spring Boot, .NET 6, etc.) and flag anti-patterns like hard-coded IPs.
- Generate: Dockerfiles use Amazon Linux 2023 base images with multi-stage builds to keep images <150 MB (median 135 MB).
- Validate: Built-in cfn-nag and Trivy scans block images with CVE score ≥ 7.0.
- Deploy: CloudFormation stack lands in a blue/green ECS cluster wired to Application Load Balancer.
How does AWS Transform compare with manual refactoring?
Manual container refactoring requires 8-12 developer-weeks per legacy monolith, whereas AWS Transform shrinks the same to 1-2 consultant-days, according to a 2024 NTT Data field study across 37 engagements. The delta is greatest when organisations lack in-house Docker expertise—exactly the scenario we see in 68 % of mid-market Southeast Asian firms.
| Metric | Manual Refactor | AWS Transform |
|---|---|---|
| Average calendar time | 14 weeks | 3 weeks |
| Dev-FTE required | 6 | 1 (review only) |
| Security review cycles | 3 | 1 (pre-baked baselines) |
| Post-migration incidents (P1+P2) | 7 | 2 |
Source: NTT Data ASEAN Modernization Index, 2024
Architecture patterns that work in Southeast Asia
In our implementations across 40+ Southeast Asian enterprises, we pair AWS Transform with a “hub-and-spoke” landing zone: central shared services (logging, secrets, CI/CD) in Singapore region and spoke clusters in Jakarta, Bangkok, and Manila to respect data-sovereignty mandates. This pattern satisfies PDPA, Bank Negara, and BI regulations while keeping image pull latency <50 ms inside each country.
Best-practice stack
- Compute: Graviton3-based ECS Fargate for cost-sensitive batch; GPU-enabled EKS for AI inference (see AI workflow automation case study).
- Networking: AWS PrivateLink endpoints to S3, CloudWatch—removes need for costly NAT Gateways.
- Observability: Amazon Managed Prometheus + Grafana; alerts route to Slack and PagerDuty.
- CI/CD: CodePipeline triggered on GitHub pull request; image scanning with Clair + Sigstore Cosign.
Step-by-step container migration playbook
Follow this seven-step playbook we refined while replatforming a Thai conglomerate’s 22 legacy Java applications in 2025.
1. Inventory & dependency graph
Run AWS Application Discovery Service for 14 days; export CSV to Excel for stakeholder sign-off. Flag shared databases <10 ms latency as potential microservice boundaries.
2. Pilot selection criteria
Choose 1–2 stateless apps with externalised config and < 5 GB memory footprint; these containerise in < 2 hours and build confidence.
3. Run AWS Transform
Upload artefacts to S3 bucket migration-landing-{acctId}; select “ECS Fargate (Graviton)” target; Transform outputs CloudFormation in ./output/.
4. Security & compliance hardening
Enable GuardDuty ECS Threat Detection, attach SCP to deny privilege-escalation IAM actions; run Prowler CIS benchmark—target score ≥ 90 %.
5. Performance validation
Execute JMeter scripts in AWS CodeBuild; baseline: p95 < 200 ms @ 1 k RPS. If latency regresses > 15 %, resize Fargate vCPU (1→2).
6. Blue/green cut-over
Use CodeDeploy with weighted target groups; shift 10 % traffic every 30 minutes, rollback on CloudWatch alarm > 1 % 5xx.
7. Cost optimisation
Enable Fargate Spot for non-prod; savings average 68 % in ASEAN (AWS Price List, March 2026).
Common pitfalls and how to avoid them
The top three failure modes we observe are: (1) oversized images, (2) stateful containers, and (3) neglected license compliance—each adding ~USD 50 k downstream rework.
| Pitfall | Symptom | Mitigation |
|---|---|---|
| 1. Fat base images | Image > 1 GB, pull time > 90 s | Use distroless or Alpine + multi-stage builds |
| 2. Persisting state inside container | Lost data on restart | Externalise to Amazon EFS or DynamoDB |
| 3. Oracle/SQL Server license drift | Audit finding | Use AWS License Manager rules before deploy |
Measuring ROI: metrics that matter
Across TechNext Asia’s 2025 portfolio, containerised replatforming delivered a median 23 % reduction in total cost of ownership and 4× faster feature velocity within nine months of go-live. We track four KPIs in an executive dashboard:
- Migration velocity: Apps containerised / month (target ≥ 4).
- Defect density: P1 incidents per 1 k deployments (baseline ≤ 0.3).
- Cloud unit cost: USD per transaction, trending down 8 % MoM.
- Developer productivity: Merge-to-prod lead time (median 22 min with CodePipeline vs 2.4 days pre-migration).
Frequently Asked Questions
How long does it take to containerise a typical legacy Java monolith?
1–3 consultant-days using AWS Transform versus 8–12 developer-weeks manually. The automated pipeline discovers dependencies, generates Dockerfiles, and produces ECS task definitions; the team only reviews and tunes memory limits.
Is AWS Transform only for Java and .NET?
Today it officially supports Java 8–21, .NET Framework 4.x and .NET 6–8, plus PHP and Python in preview. Node.js and Go are on the 2026 roadmap according to the latest AWS container road-map session.
Can we keep Windows containers?
Yes, but Fargate only supports Linux; use EKS Windows node groups or ECS EC2 launch type. Licensing remains BYOL—watch SQL Server core limits.
How does containerisation affect compliance with ASEAN data laws?
Containers themselves are neutral; the hosting layer must reside in-country. We deploy spoke EKS clusters in ap-southeast-1 (Singapore), ap-southeast-3 (Jakarta), and ap-southeast-7 (Bangkok) to satisfy PDPA, BI, and BOT regulations.
What if we already started lift-and-shift to EC2?
No problem—AWS Transform can re-import existing AMIs and re-emit container artefacts. We routinely back-port 20–30 % migrated workloads, cutting the remaining migration timeline in half.
Ready to accelerate your container migration? Talk to TechNext Asia’s cloud architects for a tailored AWS Transform pilot that proves ROI in four weeks.