On 15 May 2025 I attended the AWS Modernization Roadshow in Amsterdam, a session in a kloia-branded deck titled “EMEA AWS Modernization Roadshow”, whose title slide listed London, Amsterdam, Dubai and Istanbul as the stops. kloia is an AWS Premier Tier Services Partner according to that slide. The day had two halves: AWS slides on modernization strategy and Amazon Q Developer’s transformation agents, then a kloia session on how a partner approaches application, Windows, database and VM modernization. These are my notes from the slides; AWS and kloia content is theirs, so I only describe what was shown.
Why modernize: the business case
AWS framed modernization around three business priorities.
The opening slide grouped the drivers in three rows:
- Agility, speed, innovation: get to market faster, enter new markets, shorten the time to release features, improve customer satisfaction
- Performance and resiliency: minimise risk and downtime, roll out security patches quicker, decrease customer churn
- Efficiency and cost optimization: reduce operational inefficiencies, reduce infrastructure and licensing costs, improve utilisation
Migration patterns and how a typical estate splits
“Typical IT environment by migration pattern”, with AWS’s rough percentages (the bar continues past the right edge of my photo).
The “Modernization Pathways” slide showed a typical estate by pattern: rehost (lift and shift to capture benefits quickly) at about 30 to 40%, rehost plus (lift and upgrade, such as moving Windows Server 2005/2008 to 2016) at 5 to 10%, relocate (VMware-based apps to Amazon EVS) at 5 to 10%, replatform (for example to reduce OS and database licensing costs) at about 20%, refactor (reimagine the app architecture) at 5 to 10%, repurchase (move to SaaS) at about 5%, and retain (not prioritised for migration) at 5 to 10%; the right edge of the bar was cut off in my photo. These are AWS’s own rules of thumb, not measured data, but they match what I see: most workloads move as they are, and only a minority justify a rewrite.
Amazon Q Developer: .NET, VMware and Java
The Amazon Q Developer section opened by describing it as the first generative-AI assistant for large-scale modernization of .NET, mainframe and VMware workloads. The .NET part made the case for moving to cross-platform .NET: support for Windows, macOS and Linux on x86-64 and arm64, a larger developer pool, performance, and support and security. It also said why porting classic .NET apps is hard: a complex endeavour, inadequate tooling, resource intensive, large numbers of projects and namespaces, NuGet package dependencies and legacy codebases.
Same agent capabilities, two front ends: Visual Studio for a developer, a web dashboard for a modernization team.
The slide on “Two experiences for .NET porting” explained the split. Developers use the AWS Toolkit with Amazon Q in Visual Studio. IT and modernization teams use a web experience to port .NET at large scale, with a dashboard that tracks waves and applications, for example how many of 75 applications are completed, in progress or not started. The sample numbers on the slide are demo data, not customer results.
The VMware flow: inventory discovery, network conversion and deployment, wave planning, server migration.
The VMware slide listed the same pipeline: inventory discovery, network conversion and deployment, wave planning and server migration. A further slide on Java upgrades mentioned Java 17 and 21 targets and a fix-errors loop. AWS has since published this work under the name AWS Transform for .NET (see the AWS blog linked below), so check current product names before planning around the 2025 slides.
kloia: how a partner approaches it
kloia’s modernization framework: five tracks from infrastructure to software architecture.
The kloia section laid out an application modernization framework with five tracks: cloud-native modernization, converged infrastructures, Windows modernization, database freedom, and software architectural modernization (micro refactorings, splitting the monolith into microservices, and event sourcing with CQRS). Three topics stood out in the slides:
- Database advice. A slide titled “Don’t Force Everything into RDBMS” said relational databases often scale vertically, high throughput raises IOPS and cloud bills, and complex joins and ACID operations are resource intensive. It suggested DocumentDB for non-relational data, Amazon Timestream for time series, Amazon Neptune for graph relationships and Redis for key-value lookups. A separate slide covered ACID versus BASE.
- Patterns for splitting systems. Further slides covered the strangler-fig migration pattern (identify an asset in the monolith, move it to a microservice, then redirect calls) and CQRS, with separate command and query models.
- VMs with cloud-native practices. A slide on converged infrastructure said you can run legacy VMs in containers for significant reuse, as an alternative “VMware exit” strategy that also unifies team practices.
“Don’t Force Everything into RDBMS”: use the database that matches the access pattern.
A customer data point
The customer quote slide: the figures are a customer’s estimate, quoted on the slide.
A customer slide quoted Marc Pearce, Head of Cloud Operations at Intelliflo: with Amazon Q Developer transformation they saved about 40% of their costs, and AWS Graviton-based processors could save an additional 10%. AWS publishes a similar statement from the same person in its overview of AWS Transform for .NET, where it is framed as an estimated saving from moving .NET Framework apps to cross-platform .NET on Linux, with an additional 10% possible with Graviton. Treat it as one vendor-selected case, not a benchmark.
My take
The most practical idea of the day was the split of the estate: a third or more rehost, a fifth replatform, and a minority refactor. Tooling that automates .NET porting helps most in the replatform bucket, where the work is mechanical but huge. The part I would still plan by hand is the data layer, and the kloia database slide is a good checklist for it. For the Kubernetes side of the VM question, see Operationalizing OpenShift Virtualization.
