🦄 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, AWS experts Sree Ratnasinghe and Matthias Patzak present a holistic approach to modernizing monolithic and mainframe applications through refactoring. They address five key questions: why modernize, what to modernize, how to proceed, cost management, and ROI measurement. The session emphasizes transforming across six dimensions—architecture, technology stack, organization, ways of working, leadership, and features—rather than just technology. Key strategies include using Wardley Maps for capability visualization, implementing cell division for team scaling (starting with 2-5 teams and splitting quarterly), and leveraging AWS Transform for AI-powered modernization. Trey Tharp from The Hartford shares their success story, completing over 300 applications in three years and closing a data center. The presentation highlights that modernization requires adaptive steering with flexible funding, iterative planning, and measuring business value over scope completion, while generative AI can reduce timelines by 50% and costs by 40%.
; 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 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 just level set a bit and put this talk into perspective with the many other talks at re:Invent on migration and modernization.
So how many of you have heard of the seven Rs of migration and modernization? Cool. I see some hands raised. When we talk about modernization, people often refer to replatform and refactor. Today's talk, we're going to focus on refactoring, which is the complete rewrite of applications to be cloud native. Now one can argue that replatforming, which is taking applications, moving them to containers, managed services, 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.
So 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% of workloads are still on premises and 70% of legacy software for Fortune 500 companies was written well over two decades ago, and that creates a massive gap between what's possible and what most companies actually use today. It's a big divide. So 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 and risky and complex projects. Of course everyone wants to know about the costs and how will it pay off.
Why Modernize: The Hidden Costs of Legacy Systems and the Cloud-First Imperative
So let's begin with the why. Why modernize? We just heard that 70% of systems are older than 20 years old, but they still work. It's not like they break down on a single day. It's rather that they die by a thousand paper cuts, so customer experience is getting worse every single day by a little bit. And one of the consequences is that the organization that owns this legacy application is getting used to it. It's getting used to these downsides and paper cuts and reduced customer experience.
And so 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. Now with generative AI and agentic AI, they struggle to use data. The data in these legacy applications is usually core business data, and they've 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 the customer experience.
So 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 can't keep up with current demands, and they aren't just cumbersome. They put businesses at risk. And 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, and they want to reduce operational risk. They also 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 that they can reinvest these resources in areas of true competitive advantage. And some customers want to use cloud technology.
Cloud-first is the new normal. According to Foundry, 70% of organizations are defaulting to cloud for new technology. But, and this is an important aspect of this talk, so re:Invent is mostly about education. It's about talking about AWS services and technology, but modernizing a legacy application is not just about technology. It's about people, process, and technology. It's about reducing time to market, increasing throughput, and being able as an organization to experiment.
It's about being able to innovate, improve your agility, and make data available for generative AI use cases. So organizations that want to modernize legacy applications also need to reinvent themselves. They need to probably go through a cultural shift, need to reskill and upskill their people, and they have to reimagine their customer experience. So the next question is, what do you modernize to become cloud-native?
What to Modernize: From Monoliths to Microservices for Agentic AI Readiness
Not every company that's thinking about replacing a very old system and tech stack really understands what it is 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. So cloud-native requires a comprehensive holistic approach, as Matthias 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 that's 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's begin with the architecture, that foundation. So with traditional monolithic applications, they're built as one huge piece. Everything is connected, so it's 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're independently deployable components, so you can update one part, one microservice with a well-defined API, and other teams that support other microservices can deploy independently in a true DevOps model, and 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, just 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 as powerful as the tools and capabilities it can call. If you have legacy applications that are monoliths, agentic AI reasoning models and agents, when they go looking for those tools to call, 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 discover, find, and leverage. As you add capabilities as microservices, you quickly enhance the tools that your agents can leverage, and 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.
Technology Stack, Team Organization, and Platform Teams: The Building Blocks of Success
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, with the vast pace of change in the tech landscape, how can they 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. And 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.
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 to agile. 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, and we talked about these small two pizza teams that can be fed for lunch with 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, and 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 guardrails 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, and infrastructure platforms. As Matt Garman talked about this morning, platforms are fueled by capabilities like Amazon Bedrock for agentic AI, including security, compliance, and guardrails.
Pinterest's Journey: Scaling to 600 Million Users with Amazon EKS
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% 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 just give you a sense of scale at which Pinterest operates. The Pinterest recommendation engine is what 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. 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.
Their massive growth and innovation goals meant Pinterest has consolidated five different compute platforms into a single big data platform, made new technologies enabled to the developers, and given the developers opportunity for increased velocity and supporting new application types. For Pinterest, they were able to achieve that improved user experience with faster content discovery through machine learning and personalized recommendations. In addition, 85% of weekly active users make purchases based on their brand pins that they select.
They achieved 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% to this EKS-based platform. Congratulations, Pinterest. It's not enough to modernize the technology, the architecture, the ways of working, and leadership.
Leadership in a VUCA Environment: Adapting to Volatility and Uncertainty
For you as leaders, the tone that you set for the organization is most critical because 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, so we need leadership that works in a VUCA environment.
VUCA is volatile, uncertain, complex, and ambiguous. Things are changing, and we see this a lot with this AI era that we're in. What's true today is probably not going to 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 a support to you. Leaders who embrace the 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. So 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. And that leadership, which is critical for the success of these large complex projects, makes a difference throughout the entire organization. So now I will turn it to Maths to talk about features and functionality.
Features and Functionality: Using Wardley Maps to Visualize Value Chains
Yeah, so features and functionalities, this is your biggest lever for success. This is where you control cost, risk, and duration. Legacy systems are like icebergs. Just a small part of the legacy system is known and is visible. The largest part is hidden under the surface. It's business rules nobody documented, it's edge cases no one remembers, and it's dependencies no one really understands. And most modernization projects fail because they try to just replicate this iceberg.
Traditional requirements engineering won't work because they take 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. So it took you a year or 18 months until you came up with a new requirements document, but you really don't know and you can't test if this is what your user wants. And this is why we recommend a different approach, an iterative approach that uses smart visualization technologies.
And one tool that we recommend is Wardley Maps. Wardley Maps is a tool for visualizing value chains. So 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, it's a vertical dimension. If a component of a value stream is very visible, very close to a user, you would position it at the top. If it's not very visible for the user, you would position it at the bottom.
And on the horizontal dimension, you have the evolution of technologies. It's four phases. Genesis, this is where innovation happened. Think 20 to 30 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.
And this is an example, probably wrong. Nevertheless, 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, so they can do this by an app, by branch, by web, or by phone.
I won't explain every component here, but what is visible is that they have a lot of custom-built solutions, probably most of them older than 20 years. They use some products and they use some utilities. We recommend that you create Wardley maps for each value stream in your organization through cross-functional workshops, visualizing your components. If you have a common understanding of how your current system landscape looks like, you can decide for each component what to do in the future with this component.
Think about a call center solution. It might be a custom-built solution. You might have some developers maintaining it, and in the future state, you might think about, okay, this will become a product because there are great call center solutions out there, or we even outsource it and it might become a utility. Or you say in the future state we will move this call center solution in the area of Genesis because we want to use generative AI to really differentiate our organization from a customer service perspective. So you go capability by capability through your Wardley maps, and then you will come up with a new Wardley map.
This is a future state of a digital native bank implementing the use case of a customer who wants to pay a bill. In this example, digital native banks leverage utilities and AWS services a lot so that they free 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 to identify what to build and what to buy.
How to Proceed: Adaptive Steering and Prioritizing by Business Value
So the next section of the talk is how to proceed. We have defined the scope, so 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 budget, fixed timelines, and fixed capacity. They reduce risk by comprehensive risk mitigation plans. The primary measure of success is being in scope, in time, and in budget, and they try to increase the probability of success by 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 by rapid deployments.
So 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 they would start in the Wardley map with components that are at the bottom of the Wardley map because these are foundational components. So they would look for components which have a lot of dependencies and then they would work backwards from these dependencies.
As a consequence, following the Pareto principle, they will have 80% of the scope of the modernization project delivered but just 20% 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, it's new architecture, it's new ways of working. We will make assumptions, we will make decisions, and some of the decisions and assumptions might be wrong. So 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, and then 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, where you test your ways of working and
put the first features into production, the features with the highest technical risk, and you prove that your new architecture works. And at the end of the bootstrapping phase, when you know your ways of working, 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, and these are usually the features with the highest business value and the highest technical risk.
Then you shift your focus to features that have also high business value but less technical risk. This is phase three. 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. And this approach also defines your sourcing strategy. Because for the first two phases with high technical risk, you need a partner, probably from a boutique consultancy that are very good technical experts, architects, and infrastructure specialists. They can help you to 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 phase one and two, your teams and your organization should be able to drive the modernization. They should be able to define your microservices. They should 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. And start working on features with little technical risk, you can then even leverage a more cost-effective labor like freelancers.
The Bootstrapping Phase and Cell Division: Scaling Teams Through Structured Growth
So, how to set up the first team? Let's talk a little bit about this bootstrapping phase. 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, or 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 put 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 out of internal and external people that help to define and shape the architecture. So 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 one, but severity three, 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.
And 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, deploy multiple times a day into production. The best organizations deploy every little change to the code base 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,
also a bootstrapping phase needs some preparation. At AWS we have a specific program that helps you to become ready. It's called Experience Based Acceleration. It's a 5 to 7 weeks 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 ship into production, we have several teams already productive, 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. But what we approach in this talk, what we propose is a structured and adaptive approach that balances scaling, knowledge transfer, quality, and delivery of features.
And the mental model that we propose is cell division. And this is how it works. So you would start in the first quarter with a single team or as we recommended, 2 to 5 teams. In this team, we consist out of 50% external, 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. And so you have a structured approach how to scale.
But actually it's not just about scaling. In this approach, teams can exist in one out 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, no, no, now we want to deliver features. We need to show progress to our stakeholders, so you keep all 4 teams stable, no changes, and you start delivering features. In this way, it gives you room to maneuver. It gives you ability to adopt and to steer depending on what's going on in your organization, in your project.
This is a more specific approach, so we start with 3 teams. They are capable at the end of the first quarter. We split them in the platform team, we keep 1 team stable. And having a stable team from the beginning on 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, and this is how you can manage your teams.
And 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, so keeping the old core application running. And then you start taking the first people out, 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, being mentors, or they will be a member of a team that is in product delivery mode and so they are at the peak productivity.
Measuring Progress Through Business Outcomes and Adaptive Simulation Models
And this adaptive approach enables you to simulate your modernization project and this simulation helps you to communicate with your stakeholders. So 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 on paper. But if we look at their productivity, because we constantly split these teams for the first five quarters, none of the team is really productive. They will deliver features, but with long cycle time, low throughput, and low quality. This 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's a little bit slower. We will have all 100 teams at Q11, but productive teams. It's 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. 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 the timeline. So let's assume our target is completing 2,000 features according to our backlog and we want to scale, and this is the aggressive approach. So the aggressive approach will have delivered these 2,000 features somewhere between Q10 and Q11. The moderate approach, it will take them until Q13, so it's 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 first working day of the next quarter, everyone expects teams to split or teams staying to be productive. You will have regular feedback loops that help you to adapt, and you have continuous adaptation.
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're already working two years on it, and then you say, okay, we are 60% done. What would be the reaction? Okay, 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 an 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 as the main KPIs for success: 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's hard to argue against that.
It's 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, 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, as a product manager, you need to define beforehand what 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 enables faster scaling, while every six months results in lower scaling. What is the ratio between external and internal people? A higher internal ratio means faster capability building but 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 as a Force Multiplier: AWS Transform and the 50% Timeline Reduction
Generative AI is one of the fastest scaling levers for modernization that we have seen. McKinsey studied organizations using AI tools for modernization projects, and they found, based on real data from real customers, 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 to take down costs. Our vision for AWS Transform 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, produce a business case, an assessment, a plan, and with your input, humans in the loop, they execute on that refactoring plan. They cover capabilities ranging from that business case, test case generation, 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 VMware, Windows, mainframe, all of this is good, but I want to attack all the other tech debt in my 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 build custom transformation agents so that no matter what kind of tech debt 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. 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 are the teams feeling, that 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.
The Hartford's Modernization Success: From Monoliths to Microservices and Data Center Closure
Good afternoon everyone. I think I'm like Matt. I'm on a 10 minute shot clock here from his keynote. So 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's 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.
So 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. And so they started with some challenges that we were posed with. So 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's 50 states. Different states have different requirements in rating, policy, underwriting, pricing, and so forth. So when we deploy something as a product, we have to make it unique for each state. So it's a big challenge for us.
So monolith, when we have to update a monolith, you have to update that across all 50 states. Huge challenge. So we want to try and break monoliths apart. That leads into speed and innovation. So getting into that innovative space, we wanted to break those monoliths up into microservices. We wanted to do by state, and we wanted to move faster. Technical debt, 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.
And another challenge that we were facing was how to reduce cyber risk. So we wanted to build out a cyber recovery environment, increase our cyber resiliency. And for us to do that, we wanted to leverage the cloud as an air gap place to take place for that. So 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, senior leadership approval, and we launched.
So 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 R's, I know we were focusing on replatform and rewrite here, but retire was a big favorite that I want to leave off the table. So retiring applications, using current applications to replace those. Enhancing the experience, so AWS Transform was a huge benefit to us. Q Developer was another experience for us. We're improving our development teams.
We launched what we call reliability engineering squads. We use the cell split technique. We started with two squads in two different lines of businesses. We took about 2 to 3 months to get those first squads up and running, and then we split those out. We were able to go to 3 squads, 4 squads, and then we were able to go to 7 and 8 squads. And now we're at the point where we've got over 95% of our lines of businesses covered by those squads.
So I want to talk about our approach. We started with planning, we talked about the seven R's. I think almost everyone raised their hand about which of the seven R's that everybody knows about. And we rationalized the entire portfolio, give or take a couple 1000 applications, and we first started with the architecture. So we talked about having an architecture team as one of those foundational teams. We created target state architectures. These architectures were the modern, using modernized services, you'll see some of those called out here on the slide.
And when we created a target state architecture, that was the go forward direction for that application. And then we 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, how you're getting better. Some of the early modernization scores in the first year of the journey weren't so great, right?
We were challenged with how to get from A to B and whether we had the tools to get to 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.
Then we mobilize. I mentioned those RE squad teams and the developer teams. With the tools we were able to improve the speed of rewriting code. EBAs, the accelerators, were a huge benefit for us in bringing AWS. We had AWS and our team sit together in EBAs, which I mentioned take five to seven weeks. A lot of that is planning. The actual EBA is usually two to three days in the room. We take an actual application. We started with applications over 200,000 lines of code. We recently completed an EBA where we did over 140,000 lines of code. So 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. We're increasing our modernization score, we're mobilizing teams faster, and we're putting more and more teams through this and more and more applications. We've completed over 300 applications to date, with many hundreds more to go over the next couple of years.
I want to wrap up and give you a summary. Transform has been instrumental for us. We've gotten to the point where some of the early applications where we were taking 35, 45 days to rewrite 20,000 lines of code, we're now under two weeks for that number of lines of code. So great improvements. Transform recently started supporting mainframe. 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, we continue to scale out where we do the EBAs across the organization. More and more teams are getting in line to do these. They understand that that heavy lift or that five 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. So super excited about the speed and improvements there.
The next thing is data center infrastructure modernization. We've talked a lot about application modernization. Let me tell you about some infrastructure modernization. There's a program AWS has called Accelerate to the Cloud and Data Center, ACDC is the name for that. 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 a 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 in a two-year time frame on that one. That will take a little bit longer because there's quite a bit more infrastructure in there. So we're really excited to continue to partner with AWS, and I hope you all are as well. I'm going to hand it back to Shree to give you a little more details on cost. Thank you for sharing this journey with us.
Managing Costs and Final Principles: Treating Modernization as a Business Investment
So 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.
So 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 and 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 that adaptive steering. Second, embrace generative AI as an accelerant and force 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 both 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)