🦄 Making great presentations more accessible.
This project aims to enhances multilingual accessibility and discoverability while maintaining the integrity of original content. Detailed transcriptions and keyframes preserve the nuances and technical insights that make each session compelling.
Overview
📖 AWS re:Invent 2025 - A leader's guide to cloud-native application modernization (SNR302)
In this video, Sree Ratnasinghe and Matthias Patzak from AWS, along with Trey Tharp from The Hartford, present a holistic approach to modernizing monolithic and mainframe applications through refactoring. They address five key questions: why modernize (70% of Fortune 500 legacy software is over 20 years old), what to modernize (architecture, technology stack, organization, ways of working, governance, and leadership), how to proceed (using Wardley Maps, iterative planning, cell division team scaling), and cost management. The session emphasizes moving from monoliths to microservices to enable agentic AI capabilities, establishing cross-functional two pizza teams, and leveraging AWS Transform for AI-accelerated modernization. The Hartford shares their success story, completing over 300 application modernizations and closing a data center using the ACDC program. Key metrics include 50% reduction in modernization timelines and 40% cost reduction through generative AI tools. The speakers stress measuring business value over feature completion, adaptive steering in VUCA environments, and transforming people, process, and technology holistically.
; This article is entirely auto-generated while preserving the original presentation content as much as possible. Please note that there may be typos or inaccuracies.
Main Part
Introduction: Building the Foundation for Agentic AI Through Modernization
Welcome. Have you ever imagined the future of your business with workflows fused with agentic AI? Have you imagined building a house or building an office building without a strong and scalable foundation? Your current IT landscape and your modernization strategy serve as that foundation for an agentic AI future. My name is Sree Ratnasinghe. I'm the Director of Customer Solutions for Migration and Modernization in AWS Industries. I'm joined by my colleague Matthias Patzak, who works as an Executive in Residence at AWS, and together we work with customers across diverse industries to accelerate their modernization strategy.
Today's 300-level talk is going to be about the holistic approach to take a monolithic or mainframe application and transform and modernize it. We'll also be joined by Trey Tharp, Assistant Vice President of Cloud Services at The Hartford, to share more information and learnings from their modernization journey. First, I want to level set a bit and put this talk into perspective with the many other talks on reinvention, migration, and modernization. So how many of you have heard of the Seven Rs of migration and modernization? I see some hands raised.
When we talk about modernization, people often refer to re-platforming and refactoring. Today's talk, we're going to focus on refactoring, which is the complete rewrite of an application to be cloud native. One can argue that re-platforming, which is taking applications and moving them to containers, managed services, and managed databases, is also a form of modernization. Yes, but the one that yields the most benefits in the long term, even though it takes the most work, is refactoring, and that's what we will focus on today to unlock the value.
Why Modernize: The Legacy System Crisis and Business Imperatives
Over the last 20 years, digital transformation has moved through four big waves starting with the Internet era, the mobile era, which put the power of computing into each and every person's pocket, social computing and connectivity, and now we're in the AI era with AI automating complex workflows. Despite all these advances, the reality is that most enterprises, especially ones that have a long history of tech stack, have faced a critical challenge with their existing technology infrastructure.
Today, 70 percent of workloads are still on premises and 70 percent of legacy software for Fortune 500 companies was written well over two decades ago. That creates a massive gap between what's possible and what most companies actually use today. It's a big divide. In today's talk, we're going to answer the five most common questions that customers have asked us about modernization. We'll start with why: What is the driver to modernize? What do you modernize and where do you start? How do you go about it, which is where we'll spend the most time with proven strategies so that you can take on large, risky, and complex projects. Of course, everyone wants to know about the costs and how it will pay off.
Let's begin with the why. Why modernize? We just heard that 70 percent of systems are older than 20 years old, but they still work. It's not like they break down on a single day. Rather, they die by a thousand paper cuts. Customer experience is getting worse every single day by a little bit. One of the consequences is that the organization that owns this legacy application gets used to it. They get used to these towels and paper cuts and the reduced customer experience. These are the challenges we hear from customers. One of the most important challenges is cost. Legacy systems are costly. They have long time to market, and security is an issue because you can't harden legacy applications against new threats.
Customers also complain that attracting talent is very hard. When support is limited, and now with generative AI and agentic AI, they struggle to use data. The data in these legacy applications is usually core business data, and organizations have started to use this data as context and knowledge bases for generative AI. But from my perspective, one of the most important issues and challenges of legacy applications is customer experience. This phone once seemed cutting edge. Everyone wanted to have it, and it was a status symbol. But now it no longer exists. Legacy systems cannot keep up with current demands, and they are not just cumbersome. They put businesses at risk.
So what do we hear from customers about why they want to modernize? They want to adapt faster, they want to be innovative, they want to attract digital native talent, they want to reduce operational risk, and they want to improve reliability, availability, and performance. Some want to create AI-first businesses and pivot their current business model. Some want to free up resources so they can reinvest these resources in areas of true competitive advantage. Some customers want to use cloud technology. Cloud-first is the new normal. According to Gartner, 70% of organizations are defaulting to cloud for new technology. But this is an important aspect of this talk: Reinvent is mostly about education. It is about talking about AWS services and technology, but modernizing a legacy application is not just about technology. It is about people, process, and technology. It is about reducing time to market, increasing throughput, being able as an organization to experiment, being able to innovate, improving your agility, and making data available for generative use cases.
What to Modernize: The Six Dimensions of Cloud Native Transformation
Organizations that want to modernize legacy applications also need to reinvent themselves. They need to probably go through a cultural shift, need to rescale and upscale their people, and they have to reimagine their customer experience. So the next question is what do you modernize to become cloud native? Not every company that is thinking about replacing a very old system and tech stack really understands what it means to become cloud native. From your perspective, show of hands, have you thought about what it means to be cloud native? I see some raised hands.
Cloud native requires a comprehensive holistic approach, as Matias mentioned, across multiple dimensions: people, process, and technology. The more dimensions where you reach state of the art, the more successful your modernization will be in terms of unlocking value. You can start anywhere, but you want to make sure you look to progress across all six work streams. We look at moving to a modern architecture, which is often one of the first things discussed: your technology stack, how your organization is structured, your governance, your ways of working, and your leadership, because leadership is very important to the direction of the organization and what features and capabilities you prioritize.
Let us begin with the architecture, that foundation. With traditional monolithic applications, they are built as one huge piece. Everything is connected, so it is hard to deploy individual pieces fast because when you deploy one part of the application and make changes, that impacts the rest, and failures often propagate and affect the entire application. But microservices are different. They are independently deployable components, so you can update one microservice with a well-defined API, and other teams that support other microservices can deploy independently in a true DevOps model. That increases your time to market, failures are contained, quality is improved, resilience can be improved, and that delivers real business value because you can launch faster.
So with that, let's talk about what that means for agentic AI. Gartner predicts that in 2028, a couple of years from now, over a third of all enterprise applications will be powered by agentic AI. But the truth is an agentic AI system is only powerful based on the tools and the capabilities that it can call. If you have legacy applications that are monoliths, agentic AI reasoning models and agents, when they go look for those tools to call, they can only navigate some sub portions of your legacy application.
Microservices changes that because microservices are exposed with API driven interfaces and those APIs are perfect to be served up as tools through protocols like agent to agent and model context protocol for reasoning models and agents to go discover and find and leverage. As you add capabilities as microservices, you quickly enhance the tools that your agents can leverage. What you're really doing is modernization. Now this is a mindset shift because it isn't just about infrastructure. It's about building that technical and organizational foundation that makes agentic AI viable.
So we looked at architecture. Let's talk about the technology stack. There are four key components to the technology stack that you want to take into consideration. When I talk to senior leaders in organizations, they're really thinking about the vast pace of change in the tech landscape and how they can make decisions that are what I call unregrettable investments. You go in a certain direction, you take a fork in the road, and you don't regret that tomorrow as the tech landscape keeps changing.
The first thing is to look for technical maturity and stability, technologies that have a proven track record in the enterprise with predictable updates. Second, you want to look for a large and active community ecosystem, and this is where the open source ecosystem comes in. This is why many organizations have standardized on open platforms like Kubernetes as the foundation for their modernization. Talent availability is very important because you want to attract talent into your organization and have a great pipeline. Second is industry adoption. What are the technologies that the industry is putting its momentum behind? When you look at all of these and consider those, then you have the best chance of making investments that are unregrettable.
Organizing for Success: Two Pizza Teams, Platform Engineering, and Pinterest's Data Platform Journey
Now let's look at ways of organizing. When replacing a monolith with microservices, we've seen best success with our customers and even within Amazon in creating cross functional teams that are aligned to your business capabilities and your business value streams. In Amazon we call these two pizza teams, and every product team is decomposed into two pizza teams. They own their goals. They define their goals. They take full ownership of their services and microservices and follow a true model of building it, running it, and supporting it all the way through so that they can move fast.
In addition to that organization, we also need to modernize how teams work, and there are four key principles behind the ways of working for successful modernizations. The first one is being iterative and incremental, moving the organizational culture and governance from waterfall. The second is being customer outcome focused. It's not about measuring how much you shipped or how many pull requests. That's an interesting KPI, but the value to the business and the customer is most important. Moving to a DevOps model is also a foundational shift in culture. We talked about these small two pizza teams that can feed off of for lunch two big pizzas, not any bigger. They're loosely coupled and they're highly aligned so that they can move very fast.
When you have loosely coupled teams that modernize for speed and outcomes, we want to prevent those teams from all solving the same problems like authentication, DevOps, having common platforms for payments and observability.
This is where platform teams come in to set the foundation. Platform teams essentially build products that are used internally to the enterprise by product teams so that product owners and microservices owners can move fast, be efficient, leverage these central platforms and incorporate guard rails like security, performance and compliance.
For example, you could have a business platform that covers capabilities like payments or order processing, a data mesh platform because that data fabric and the ability to produce and consume it as a product is very critical across the enterprise including the governance infrastructure platforms and as Matt Garman talked about this morning, platforms fueled by capabilities like Amazon Bedrock for agentic AI including security, compliance, and guard rails.
A customer that has been very successful in growing their business through a modernized data platform is Pinterest. Who here has browsed or shopped using the Pinterest app or web properties? I personally love to shop and love to browse. I'm actually redecorating some areas of my house right now using Pinterest. It's a visual search and discovery platform where people find inspiration, curate ideas, and shop, and you're not alone if you use Pinterest. In the third quarter of this year, Pinterest grew 12 percent year over year to 600 million monthly active users.
With that growth they experienced evolving needs for cost efficient and scalable growth using machine learning and incorporating user preferences for increased personalization and shopping. I want to give you a sense of scale at which Pinterest operates this platform. The Pinterest recommendation engine ingests massive volumes of data from your smartphone, from web properties and partner properties and drives personalized recommendations. That leverages the batch processing platform that processes over 230 petabytes of data per day and growing.
In addition to those business and user engagement drivers, Pinterest wanted to modernize due to technical drivers as well. With the scale and cost growth, they wanted to move to price performance processors and cost efficiency. Speaking of open technology, they wanted to leverage and converge to Spark and maintain a growing big data ecosystem. So to enable this next generation data processing, Pinterest selected Amazon EKS, Elastic Kubernetes Service, for the basis of their cloud native container orchestration platform for scalability, security, deployment flexibility, and ability to deploy across modern price performance processors like Graviton, all well supported by their massive growth and innovation goals.
Pinterest has consolidated five different compute platforms into the single big data platform, made new technologies enabled to the developers, and given the developers opportunity for increased velocity and supporting new application types. So for Pinterest, they were able to achieve improved user experience with faster content discovery through machine learning and personalized recommendations. In addition, 85 percent of weekly active users make purchases based on their brand pins that they select. Scalability with 1.5 billion pins saved weekly supported by this platform, and they were able to consolidate these five platforms and have moved 90 percent to this EKS based platform. Congratulations, Pinterest.
Leadership in a VUCA Environment: Adapting to Volatility and Complexity
It's not enough to modernize the technology, the architecture, the ways of working, leadership, and for you as leaders,
the tone that you set for the organization is most critical. When you're modernizing legacy systems, nothing is simple. You have so much accumulated code, risks, dependencies, and hidden business logic at every single step. We need leadership that works in a VUCA environment. VUCA is volatile—things are changing. We see this a lot with the AI era we're in. What's true today probably won't be fully true tomorrow. It's uncertain with risks and dependencies. There are multiple interconnected factors driving complexity, and there's ambiguity. You don't know what could be a threat or a benefit and support to you.
Leaders who embrace adaptability and resilience and empower their organizations to do that will thrive in this VUCA environment. Additionally, leaders who are successful in these modernizations set aggressive top-down goals, empower and listen to their teams, and create an environment where diverse, inclusive teams can thrive. Here's what changes in this VUCA-oriented operating model. Instead of all upfront planning, you plan very iteratively. You expect things to change and you adjust quickly so that you can respond to risks.
Fixed budgets go away in partnership with finance and operations in favor of flexible funding. You move from measuring scope and timeline to measuring the actual value and ROI delivered. You move from planning and predicting upfront to adapting, learning, and adjusting. Leadership, which is critical for the success of these large, complex projects, makes a difference throughout the entire organization. Now I will turn it to Matthias to talk about features and functionality.
Defining Scope with Wardley Maps: Visualizing Value Chains and Future State Architecture
Features and functionalities represent your biggest lever for success. This is where you control cost. Risk duration and legacy systems are like icebergs. Just a small part of the legacy system is known and visible. The largest part is hidden under the surface. It's business rules nobody documented, edge cases no one remembers, and dependencies no one really understands. Most modernization projects fail because they try to just replicate this iceberg.
Traditional requirements engineering won't work because it takes long. Usually it's really hard to analyze the current scope and feature set of a project to properly document it. But the main challenge is that even if you are able to define innovative new requirements in your next-generation system, you can't test it. It took you a year or eighteen months to come up with a new requirements document, but you really don't know and you can't test if this is what your users want. This is why we recommend a different approach—an iterative approach that uses smart visualization technologies.
One tool that we recommend is Wardley Maps. Wardley Maps is a tool for visualizing value chains. In a Wardley Map, you would visualize the different components that you need in a value stream, and it has two dimensions. One dimension is visibility, which is a vertical dimension. If a component of a value stream is very visible and very close to a user, you would position it at the top. If it's not very visible to the user, you would position it at the bottom.
On the horizontal dimension, you have the evolution of technologies. It's four phases: Genesis, this is where innovation happened. Think twenty to thirty years ago when e-commerce was invented. You would put an e-commerce shop as a capability in the Genesis area. Then organizations started to build custom-built webshop functionality. Then it would move into custom-built solutions. Then some other organization created webshops as a product, and maybe now it became a utility. This is an example, probably not entirely accurate, but it was created by a former CTO of a bank. It visualizes the value stream of a banking customer who wants to pay a bill. They can do this by an app, by branch, by web, or by phone.
While I won't explain every component here, what is visible is that they have many custom-built solutions, probably most of them older than 20 years. They use some products and some utilities. We recommend that you create value by developing Wardley Maps for each value stream in your organization through a cross-functional workshop that visualizes your components. Once you have a common understanding of how your current system landscape looks, you can decide for each component what to do with it in the future.
Consider a call center solution. It might be a custom-built solution with some developers maintaining it. In the future state, you might decide that this will become a product because there are great call center solutions available, or you might even outsource it and it becomes a utility. Alternatively, you might say that in the future state, you will move this call center solution into the Genesis area because you want to use generative AI to really differentiate your organization from a customer service perspective. You go through your Wardley Maps capability by capability and then you come up with a new Wardley map.
This is the future state of a digital native bank implementing the use case where a customer wants to pay a bill. In this example, digital native banks leverage utilities like AWS services extensively, which frees up resources. They use some products, but most of the engineers are in the area of custom-built solutions. This is how you create a landscape of your current system, and Wardley Maps also help you identify what to build and what to buy.
How to Prioritize: Adaptive Steering and the Bootstrapping Phase
The next section of the talk is how to proceed. We have defined the scope. Let's talk about how to prioritize. As we already heard, we act in a VUCA environment, so we need a different approach. We don't want to apply the traditional approach of following a plan. We want to have adaptive steering. Traditional organizations invest in upfront planning because then they can define fixed budgets, fixed timelines, and fixed capacity. They reduce risk through comprehensive risk mitigation plans. The primary measure of success is being in scope, on time, and within budget, and they try to increase the probability of success through exhaustive analysis and documentation.
In an adaptive approach, you act differently. You apply iterative planning. You use flexible funding. You reduce risk by continuously discovering risk by putting features and capabilities early into production. The primary measure of success is business value delivered, and you increase the probability of your legacy modernization through rapid deployments. You have defined your Wardley Maps. You know the components and the future state of your system. Now we need to start somewhere. We need to order these capabilities.
In most organizations, they optimize for efficiency and would start in the Wardley Map with components at the bottom because these are foundational components. They would look for components which have many dependencies and then work backwards from these dependencies. As a consequence, following the Pareto principle, they will have 80 percent of the scope of the modernization project delivered but just 20 percent of the business value. If you follow this path, you're probably doomed. We recommend a different approach. We recommend an approach that optimizes for effectiveness.
We want to deliver business value as soon as possible, and we want to fail fast because it's new technology, new architecture, and new ways of working. We will make assumptions and decisions, and some of those decisions and assumptions might be wrong. The consequence of a wrong decision must be limited. This is why we categorize capabilities in the Wardley Map by technical risk and by business value. This classification also drives the roadmap of the project. You can visualize all your features of your legacy application in a 3 by 3 matrix. We recommend that you start with the first phase, which is a bootstrapping phase. This is the phase where you set up your first teams. This is where you set up your architecture, your developer experience, your infrastructure, and where you test your ways of working.
You put the first features into production—the features with the highest technical risk—and you prove that your new architecture works. At the end of the bootstrapping phase, when you know your ways of working and your organization setup works, you can deliver into production. You start scaling your organization, you start scaling your teams, and then you focus on delivering core features, which are usually the features with the highest business value and the highest technical risk.
Then you shift your focus to features that have high business value but less technical risk. This is phase 3. Usually this is where innovation happens, and then we move into the area of value delivery—the nice to have features and the sundown of other features. This approach also defines your sourcing strategy.
For the first two phases with high technical risk, you need a partner, probably from a boutique consultancy that has very good technical experts, architects, and infrastructure specialists. They can help you define your architecture, but one of the main responsibilities of these boutique consultancies is to enable, rescale, and upscale your own people. At the end of phases one and two, your teams and your organization should be able to drive the modernization. They should be able to define your microservices and know how to implement features in the new technology.
So if you move to features with less technical risk, you can exchange the partner you work with from a probably most expensive boutique consultancy to a standard supplier if you continue in the project. When you start working on features with little technical risk, you can then even leverage more cost-effective labor, like freelancers.
Scaling Through Cell Division: Managing Team Growth and Measuring Business Value
Let's talk about how to set up the first team. In the bootstrapping phase, we recommend that you start with two to five teams. You need to have one platform team. A platform team creates your infrastructure, your developer experience, and the tooling that is necessary for the product development teams to build the first features. By building the first features, proving your microservice architecture, and putting these features into production, each team consists of 50% internal people—your domain experts—and 50% external people bringing in technical expertise.
We also recommend that for the beginning you have an architecture enabling team made up of internal and external people that help define and shape the architecture. What are success criteria for a platform team? At the end of the bootstrapping phase, your platform team is successful if you have a production-ready AWS environment. If you have a working CI/CD pipeline that deploys into production, both of it being infrastructure as code. In the organization where I used to be a CTO, we treated every manual change to a production environment as an incident—not severity 1, but severity 3—but nevertheless it was an incident.
You need to have monitoring and observability capability. You need to have security scanning integrated in your delivery pipeline, and you need to have runbooks for platform operations. So actually you want to have an environment that is able to scale and bring in more teams. Success criteria for our product teams are similar.
So the product teams at the end of the bootstrapping phase must have delivered the first business components into the production environment. The teams need to have the ability to ship features and deploy multiple times a day into production. The best organizations deploy every little change to the codebase immediately into production. So you need to have an automated testing suite integrated into your CI/CD pipeline.
You also have validated your user experience because users are already using your features. You know that your microservice architecture works, and because we ship features early into production, you will have for a longer period of time both systems working in parallel. So you have data migration synchronization patterns working, and you have proven it. In general, we recommend that you become ready by starting and not start when you're ready, but nevertheless, a bootstrapping phase needs some preparation.
At WBS we have a specific program that helps you to become ready. It's called Experience Based Acceleration. It's a 5 to 7 week program. If you're interested in this program, reach out to us or your account team and get some information about this program.
So we're in a bootstrapping phase. We can now ship into production. We have several teams already productive, and now we want to scale. But scaling is tricky. If you scale too fast, your quality will collapse. If you scale too slow, you will miss deadlines. What we propose in this talk is a structured and adaptive approach that balances scaling, knowledge transfer, quality, and delivery of features. The mental model that we propose is cell division.
This is how it works. You would start in the first quarter with a single team, or as we recommend, 5 to 2 to 5 teams. This team consists of 50% external and 50% internal people. You will make this team productive. This talk assumes it will take a quarter. It depends on your technology, on your architecture, on the skills of your current team members, but let's assume it's a quarter. At the end of the quarter, the team is productive, and then you split the team into two small teams. You bring in more people, your domain experts, external technical experts. You make these two teams productive. It takes another quarter, and then you split again. Then you have 4 teams, you make these 4 teams productive, and at the end of the quarter you split again into 8 teams. So you have a structured approach for how to scale.
But actually, it's not just about scaling. In this approach, teams can consist in one of two phases: either training on the job or product development. So in this example, from the 1st to the 3rd quarter we are scaling teams from 1 team to 2 to 4 teams, but at the end of the 3rd quarter you decide, no, now we want to deliver features. We need to show progress to our stakeholders, so you keep all 4 teams stable with no changes, and you start delivering features. In this way, it gives you room to maneuver. It gives you the ability to adapt and to steer depending on what's going on in your organization and your project.
This is a more specific approach. We start with 3 teams. They are capable at the end of the first quarter. We split them into the platform team and keep 1 team stable. Having a stable team from the beginning is very important because you need data about your throughput, about your cycle time, about the quality, about the motivation in the team so that you can forecast the progress of your project. But in the 2nd quarter we keep one platform team stable, but we split two more platform teams so that we have 5 platform teams in total, and then we continue. At the end of the 3rd quarter we have 8 teams in total. This is how you can manage your teams following this team setup.
You will have 5 different phases that act like a funnel for all of your team members at the beginning of the project. Everyone in the organization is probably maintaining the legacy system, keeping the old core application running. Then you start taking the first people out and put them in a formal training program with zero productivity. Then you put them in a team that is on the job learning, so the individual contributor is also in an on-the-job learning mode. Later on they might become capable, experienced people on a new team, training others and being mentors, or they will be a member of a team that is in product delivery mode and so they are at peak productivity.
This adaptive approach enables you to simulate your modernization project. This simulation helps you to communicate with your stakeholders. It's a system model. In this example we will compare an aggressive approach with a moderate approach. Let's assume our target picture is 100 teams. We want to grow up to 100 teams and we choose an aggressive scaling approach where we start with 5 teams and then we split every team every quarter. So we start with 5 teams and in quarter 5, after more than a year, we will have 100 teams.
But if we look at their productivity, because we constantly split these teams for the first five quarters, none of the teams are really productive. They will deliver features, but with long cycle time, low throughput, and low quality. It is hard to communicate to your stakeholders. Let's have a look at a moderate approach where we just split every other team each quarter. So we see it is a little bit slower. We will have all 100 teams at Q11, but productive teams. It is a much slower number. So we can deliver earlier during the first year already features, we can prove our throughput, our cycle time, and the quality. But we will be finished later. What would you choose? Who would choose aggressive? Who would choose moderate? A few.
So let's have a look at the future perspective. So we want to deliver 100 features per month. And with aggressive scaling where we split every team every quarter, we will have very little productivity for the first five quarters. But from quarter six on, we will have an organization that is at peak productivity. The moderate approach outperforms just for the first two quarters, and for the rest of the scaling, they have lower productivity. But for the first year they had higher reliability.
And now let's have a look at timeline. So let's assume our target is completing 2000 features according to our backlog and want to scale, and this is the aggressive approach. So the aggressive approach will have delivered this 2000 features somewhere between Q10 and Q11. The moderate approach will take them until Q13, so it is about nine months later. And so you see with different scaling approaches, you can simulate your approach and you can communicate with your stakeholders how you want to proceed.
An important factor is that you apply timeboxed cadences and the definition of the length of the timebox is how long it takes on average to make a team that is training on the job productive. And this fixed cadence enables you to have a predictive planning system. It forces decision making because you know the next working day of the next quarter, everyone expects teams to split or teams staying too productive. You will have regular feedback loops that help you to adapt and you have continuous adoption.
So how to measure progress, how to report progress? Usually companies report progress by feature completion rate. Imagine you enter an elevator and a colleague asks you, "Hey, how is your project going?" You are already working two years on it, and then you say, "OK, we are 60% done." What would be the reaction? OK, 60% after two years, I assume it takes 18 months longer and you have a long way to go. So what about if you would be able to say, "We have 60% of the features delivered, and this 60% of the features deliver 80% more revenue." This would be awesome.
Actually, this is how I approached a modernization that I did. I was brought in as a CTO to modernize the e-commerce application, an organization that tried it before for two or three years. Actually they failed and they came up to me with a long list of features they asked me to deliver, but I agreed on three main KPIs. The main KPIs for success were revenue per session, conversion rate, and basket size. And then we started building features in this e-commerce shop that proved the conversion rate. So we started with the product detail page and the conversion funnel just for social media traffic. And then we optimized with this small fraction of the user base the conversion rate and the revenue, and then we scaled and we built more features.
And then after eight to ten months we had another steering committee meeting and I proposed based on 20% of the overall user base being on the new system that we should shift over all of the traffic to the new system. The CEO was shouting at me, yelling at me at this meeting because he said, "Hey, essential features are missing," and he was right. Payment methods were missing, but for the private equity this was an easy decision: 80% more revenue. It is hard to operate this way, but this is the way to go.
When you want to have your major business KPIs as the main success criteria, this is how you should define and specify features. We believe that this feature and this capability will result in this outcome, and we will know we have succeeded when we see a measurable signal. So as a product owner or product manager, you need to define beforehand how the success criteria looks like.
This adaptive approach gives you some levers for success. The first is training duration—how long your people are in this formal training period. Shorter training means lower cost but lower quality. How often do you split your teams? Every month allows faster scaling, while every six months results in lower scaling. What is the ratio between external and internal people? A higher internal ratio is faster for capability building but comes at higher cost. How many people do we have in a certain team mode? And finally, are you using generative AI in this project? Generative AI is one of the fastest scaling levers for modernization that we have seen.
Accelerating with Generative AI: AWS Transform and the 50% Efficiency Gain
McKinsey studied organizations using AI tools for modernization projects, and based on real data from real customers, they found a 50% reduction in modernization timelines and a 40% reduction in costs from taking down that tech debt. This is the type of efficiency gain that really changes the economics of modernization. Projects that previously were not viable due to the time and cost that they would take are suddenly possible with much improved business cases. In May of this year, we released AWS Transform, which is the first agentic AI service that is built specifically for large-scale agentic-fueled migration and modernization based on what customers told us were the most urgent and complex problems to solve.
We began with agents for IBM z/OS mainframe modernization, VMware moving to Amazon EC2, and modernizing .NET applications from Windows to Linux to modernize and reduce costs. AWS Transform's vision is to be an extension of your IT team with deep expertise in modernization and migration. AWS Transform agents are an extension of your organization. They get to understand your goals, your preferences, your enterprise standards, your workloads and dependencies, and they produce a business case, an assessment, and a plan. With your input and humans in the loop, they execute on that refactoring plan. They cover capabilities ranging from business case and test case generation to dependency mapping, and all of this reduces risk for your modernization.
For example, BMW Group modernized seven mainframe applications in just six months, which was previously unheard of. Yesterday, we released AWS Transform Custom, and this was born from customers telling us that while VMware, Windows, and mainframe modernization is good, they want to attack all the other tech debt in their organization—old SDKs to new SDKs, old Lambdas, old versions of Java with specific build packs to new versions, compliance upgrades, and more. So we released AWS Transform Custom, which gives you the capability to find custom transformation agents so that no matter what kind of agent you have, you can tackle the technical debt that you wish. This generative AI can be a force multiplier in your modernization, and those who use it will leapfrog.
The Hartford's Modernization Success: From Monoliths to Microservices in 215 Years of Insurance
So now, how do you know if your plan is working? You need to measure reality, and that enables you to steer adaptively and show progress. There are five key KPIs of a modernization project:
business value, how fast you're generating throughput, your quality, your employee engagement, how the teams are feeling—motivation is very important—and of course cost. One of the most important questions leadership teams ask themselves is will it pay off? I'd like to rephrase this to how much value can you unlock. It is my great pleasure to introduce Trey Tharp from The Hartford to talk about the benefits of their modernization journey.
Good afternoon everyone. I'm on a ten-minute shot clock here from the keynote. I'm going to introduce myself. I'm Trey Tharp. I'm with The Hartford. I'm part of the cloud services team. We build those platforms and products that were mentioned earlier. The Hartford is an insurance company that just celebrated its 215-year anniversary. We've insured everything from the Golden Gate Bridge. We were there for the Chicago Fire. Abraham Lincoln had a policy with us, so we've been around the US for a very long time.
I'm going to talk about how we started our cloud journey. I joined The Hartford two years ago. I was excited about the cloud journey that was going on at The Hartford and the progress that they were making and the progress they wanted to make. We started with some challenges that we were posed with. How do we keep sustainable growth? How do we enter market segments? A little bit about the insurance industry for those who don't know: every state has different regulations, so there are fifty states. Different states have different requirements in rating, policy, underwriting, pricing, and so forth. When we deploy something as a product, we have to make it unique for each state. That's a big challenge for us.
When we have to update a monolith, you have to update that across all fifty states. That's a huge challenge. So we wanted to try and break monoliths apart, which leads into speed and innovation. Getting into that innovative space, we wanted to break those monoliths up into microservices by state, and we wanted to move faster. Technical debt is another challenge. We may or may not have code that survived Y2K running out there. We've got mainframes, we've got a lot of legacy infrastructure. We had assets that are far past their useful life. Another challenge that we were facing was how to reduce cyber risk. So we wanted to build out a cyber recovery environment and increase our cyber resiliency. For us to do that, we wanted to leverage the cloud as an air gap place for that.
Those are some of the reasons why we got started, and we launched a program internally that was called Ignite. That was our code name for the program. We got board-level approval and senior leadership approval, and we launched. Simplify and modernize was a big foundation. When we think of simplifying, we had multiple systems that were doing similar things. We had multiple different payment systems, multiple different claim systems, and we wanted to bring those together. One of the popular Rs—I know we were focusing on replatform and rewrite here—but retire was a big favorite that I want to highlight. Retiring applications using current applications to replace those was important to us.
Enhancing the experience was another benefit. Transform was a huge benefit to us. AWS Q Developer was another experience for us. We're improving our development teams. We launched what we call reliability engineering squads. We used the cell split technique. We started with two squads in two different lines of businesses. We took about two to three months to get those first squads up and running, and then we split those out. We were able to go to three squads, four squads, and then we were able to go to seven and eight squads. Now we're at the point where we've got over ninety-five percent of our lines of businesses covered by those squads.
I want to talk about our approach. We started with planning. We talked about the seven Rs. I think almost everyone raised their hand about which of the seven Rs everybody knows about. We rationalized the entire portfolio—give or take a couple thousand applications. We first started with the architecture. We talked about having an architecture team as one of those foundational teams. We created target state architectures. These architectures were modernized services, and you'll see some of those called out here on the slide. When we created a target state architecture, that was the go-forward direction for that application.
We then scored it, and one of the nice things about a scoring model is it allows you to see how you're improving along the way, what progress you're making, and how you're getting better. Some of the early modernization scores in the first year of the journey weren't so great.
We were challenged with how to get from A to B and whether we had the tools to reach a more modern place. Now we're about three years into the journey, and our modernization scores are almost double what they were in the very beginning. We mobilized RE squad teams and developer teams with the tools we were able to improve the speed of rewriting code.
EBAs were a huge benefit for us in bringing AWS. We had AWS and our team sit together in EBAs, which mentioned 55 to 7 weeks. A lot of that is planning, and the actual EBA is usually 2 to 3 days in the room. We take an actual application, and we started with applications over 200,000 lines of code. We recently completed an EBA where we did over 140,000 lines of code. We're seeing exponential improvement in the lines of code and the complexity of applications that we're able to modernize, rewrite, and refactor.
This is all a flywheel. The idea is how do we take what we learned from the previous one and get better at the next one. We're speeding up how fast we make the target state architectures, increasing our modernization score, mobilizing teams faster, and putting more and more teams through this and more and more applications. We've completed over 300 applications to date, with many more to go over the next couple of years.
Transform has been instrumental for us. We've gotten to the point where some of the early applications where we were taking 35 to 45 days to rewrite 20,000 lines of code, we're now under 2 weeks for that number of lines of code. Transform recently started supporting mainframe, and we're super excited about that. We're looking at leveraging Transform in our mainframe space right now and how we can start targeting that code.
EBAs continue to scale out across the organization, and more and more teams are getting in line to do these. They understand that the heavy lift or that 5 weeks ahead of time for the planning and preparation really yields the results when you execute the EBA. We're now at the point where almost every EBA that we've done, the code that comes out of that EBA is near production ready. It's going into a QA environment and it only needs a little bit of time before it can make itself all the way to production.
The next thing is data center infrastructure modernization. We've talked a lot about application modernization, but let me tell you about some infrastructure modernization. There's a program AWS has called Accelerate to the Cloud and Data Center, or ACDC. I'm happy to report and tout success that this weekend will be the last cutover weekend where we're going to fail over our last set of applications to close one of our data centers. It's extremely exciting to be able to close the data center, and we'll be getting all that equipment out of there through the end of the year and into Q1.
We've had such good success over that data center closure this past year that we're already in conversations with our account team at AWS to look at one of our largest, our single largest primary data center to close that, probably on a 2-year time frame. That one will take a little bit longer with quite a bit more infrastructure in there. We're really excited to continue to partner with AWS, and I hope you all are as well.
Managing Costs and Taking Action: Investment Principles and Next Steps
Every modernization conversation arrives at this last dimension, which is cost. There is a way to move from traditional rigid upfront planning of costs, which really doesn't work, to a more iterative dynamic model where you have rolling forecasts that you can adjust very regularly. You project costs, you adjust, you iterate, and you include fully loaded costs.
How do you calculate this critical cost? First, you establish your baseline costs. Then you simulate that cell division model. You control the team split and the training intervals. You model that growth in the best case, the worst case, you estimate your fully loaded system cost, and you continuously recalibrate with your teams, your finance, and your business stakeholders. This moves you to a model where you can adapt your cost forecasts.
Modernization is a business investment. Four principles will help you manage it like one. First, set a fixed budget. Frugality breeds constraints.
Adjust that scope based on the capabilities that will deliver the biggest ROI for your business. Measure that ROI on an iterative basis and make decisions based on completion percentage.
To close, we've talked about a holistic approach today to modernize legacy systems. While it's challenging, you can succeed with a focus on three things. First, focus on outcomes, not outputs, and measure business value. Ship fast and embrace adaptive steering. Second, embrace generative AI as an accelerant and multiplier. It will enable you to leapfrog and shatter that tech debt. Third, transform the entire system: people, process, and technology. You are ready to succeed and begin with these principles.
I would like to leave you with a call to action to leverage some of our books that we have authored, like The Future of Software and The Octopus Organization. Also engage your account team so you can start to use AWS Transform and try a modernization experience-based accelerator. Thank you. Please fill out the session feedback. We'll be available of course through LinkedIn and in the hallway outside.
; This article is entirely auto-generated using Amazon Bedrock.
Top comments (0)