🦄 Making great presentations more accessible.
This project enhances multilingual accessibility and discoverability while preserving the original content. Detailed transcriptions and keyframes capture the nuances and technical insights that convey the full value of each session.
Note: A comprehensive list of re:Invent 2025 transcribed articles is available in this Spreadsheet!
Overview
📖 AWS re:Invent 2025 - Accelerate .NET application modernization with generative AI (DVT211)
In this video, Derek Desjardins and Matt Dimich from Thomson Reuters present AWS Transform for .NET, an asynchronous agentic service that automates 40-70% of .NET Framework to .NET Core modernization tasks. The session demonstrates how this tool addresses resource constraints that typically stall modernization projects by running transformations in the cloud without tying up developer time. A live demo shows the complete workflow from transformation to validation using Kiro AI-enabled IDE on a Mac, successfully migrating a Windows application to cross-platform .NET 8. Thomson Reuters shares their experience modernizing 1.5 million lines of code monthly, reducing team sizes by half while maintaining quality. The Hartford and Experian case studies reveal savings of 300 engineering days and successful transformation of 700,000 lines of code. Key benefits include 40% cost reduction, 1.5-2x performance improvement on Linux, and compatibility with modern technologies like containers and serverless. The presentation emphasizes that while the technology accelerates modernization, success requires proper people, process, and organizational alignment to scale effectively.
; 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: The Challenge of .NET Modernization and the Promise of Generative AI
So welcome to Accelerating .NET application modernization with Generative AI. My name is Derek Desjardins. I'm a Senior Worldwide Specialist on the Gen AI team here at AWS, and I'm joined by Matt Dimich, VP Platform Engineering from Thomson Reuters. So here's our agenda for today. First, we're going to talk about modernization challenges and opportunities that partners and customers are facing. And then we're going to answer the question, why are .NET modernization projects stuck on the shelf in so many instances? We're going to introduce AWS Transform for .NET and Kiro and how they help with modernization projects. We'll talk about our partners, AWS partners who are involved with these modernization activities, and customers and customer successes. And then Matt is going to talk about how Thomson Reuters operationalizes .NET modernization.
But before we jump into all that, I thought we'd do a really quick survey, if that's okay. So how many in the audience have modernization projects underway, .NET or other? Okay, so almost everyone. How many in the audience have modernization projects stuck due to lack of resources? Significant number. Okay. And then how many in the audience are using generative AI tools to modernize legacy applications? Okay, well, hopefully we're going to make those numbers go up after our presentation today. Thank you guys so much for joining us. Okay, so modernization challenges and opportunities.
Here we go. So what are the challenges that we hear from customers? Now obviously we're focusing on Windows because we're talking about .NET today. So the big thing is Microsoft license cost. Microsoft license increases the service cost to run them by 2x for applications and 4x for databases. However, while there is a desire to move off that, there's a high cost of moving to open source. Right? It's not free, and it's not cheap. And then modernization projects themselves, as you guys know because of the show of hands, they have long timelines to realize the ROI that you can get from them. Meanwhile, while all these problems exist, technical debt continues to build up, right, and accumulate, and it blocks the path to innovation and, of course, these days to AI integrations.
So we thought we'd take a step back and talk a little bit about the modernization journey and how it's evolved. So in the past, we talked about lift and shifting to the cloud. The customers were super excited about doing it because it saved them a lot of money. Simply, hey, let's shut down our data centers and move stuff to the cloud. But the application modernization piece of that conversation was kind of postponed. It was like, we'll focus on that later once we move to cloud. So today with generative AI tools, application modernization could be part of the migration operation instead of a figure it out after the fact activity. So this new approach eliminates tech debt out of the gate and opens the door to cost-saving cloud technologies from the start. So we essentially are moving conversations and plans from get it there, then let's modernize to what does my app actually look like in cloud tech out of the gate up front. So why do this?
Why are customers and partners so excited about doing this? Why are people doing this? Why modernize .NET applications from Windows to Linux? There's three main points. First is the cost. We already talked about that. Typically that's licensing cost, but it is typically 40% less cost to run in Linux, which includes licensing. Performance. Linux servers and applications that run on them typically perform 1.5 to 2 times better or faster over Windows applications. And then if you tack, so as you're moving left to right on the slide, you're tacking on value. First costs, then my app performs better, and now I can scale more. So scalability is 50% more scalable. So if you kind of build from the left to the right, you're really tacking on value and you're saying, hey, I need less VMs to do what I used to do, and I have now more capacity potentially for new users. But once I get to Linux, that's when it really opens up. So once we're on Linux, we have compatibility potential with ARM64, which in the AWS world means Graviton processors, which can stack on more value on top of what we've talked about already. Containerization and orchestration with Kubernetes. Again, cloud technology, more value for customers.
Less uptime, only up when it needs to be up. And then to take that to the next level, serverless with Lambda. So why customers are doing it may be the big bar charts, but the benefits that they are getting in addition to the cost savings and the scalability are on the right, and that's modern technologies.
Why Modernization Projects Get Stuck: The Resource Problem
So with all this value, why are modernization projects stuck on the shelf so frequently? And I will say this, I created this slide because every customer I have talked to in the past since we GA'd AWS Transform for .NET on May 15th, 2025 has told me we have these projects but we cannot staff them. So to understand a little bit more deeply why these projects are stuck on the shelf, it helps to understand the process.
So the modernization process typically starts with a .NET Framework app or a collection of them. And then an analysis phase where we determine what tasks and resources are required to complete the work. Typically that means I'm looking at dependencies. I need to identify and analyze any parts of my applications that are running proprietary Windows APIs, things like that. I have to catalog that inventory, all of that, then I have to take that and create a project plan that has tasks and resources assigned to it. Once I get to that phase or that place, then I could begin the transformation phase where you actually transform and upgrade the code to the new framework and platform. And last but not least, a validation phase, which is where you validate the application runs in the new environment properly. So this looks pretty simple and it looks pretty clean, but there's a problem. And the problem is the people icons at the top.
Where do we get the engineers for our modernization project? And this is what I've heard time and time again from customers. So here at AWS we speak with customers and partners every day that simply do not have the resources available to assign to modernization projects, as modernization teams require developers with intimate knowledge of your legacy tech stack and the business logic within the applications themselves. To put it simply, these engineers that we have up here, these are senior engineers, not juniors, and these engineers are typically assigned to feature building projects. If you think about a legacy .NET application that's maybe 10 years old, 8 years old, maybe even more, a fresh out of college engineer is not going to know legacy .NET. They're not going to know that. They're going to know modern technologies. So you have to get the senior seasoned engineers and those engineers are typically, rightfully so, assigned to feature building projects.
So along comes generative AI and things got better. So the advent of coding assistants. So using tools like Q Developer or our AI enabled IDE Kiro, we could speed up all the engineers that are on this project. However, there's still a problem since Q Developer coding assistant and Kiro, an AI enabled IDE, are AI augmented engineering tools. It means I have to have an engineer to get the benefit of those tools. They don't do it themselves. I need an engineer. So we still have a problem. Where do we get the engineers?
So this is why we built AWS Transform for .NET as an asynchronous or away from keyboard service. I want to stop for a second and tell you what that means when you run this thing. We replace a portion of the senior engineering resource need with agents that run on your behalf in the cloud. So with AWS Transform for .NET we automate 40 to 70% of the transformation tasks that you would need to do to complete the transformation step, running in AWS Cloud, removing the need for a portion of those engineering resources, while always keeping a human in the loop during the analysis and validation phases. That's why you still see the people at the ends, because there are still people involved, not only for human in the loop, but there's always a little bit of extra work to be done.
And we talked about what the green box represents. It represents about 40 to 70% of the work. So this is a great accelerator. It's an accelerator that does not take people, and that is the point of it. So typically what we see with customers is the first thing they will do is use AWS Transform for .NET. It will assess the project, tell you, hey, this is how complex it is, these are the dependency issues, these are any roadblocks we might run into, then it will execute the transformation, it'll come back and tell you what it did. So then what we have is engineers will say, okay, great, I see I have this much work to be done. This is the type of work I have still left to do. Then they could properly assign the engineering resources to finish the job, and that number is
much less than it would have been upfront. That is the whole point of it. So with AWS Transform for .NET in your toolkit, you as a developer or a product lead can focus your time on projects more critical to your organization.
AWS Transform for .NET: An Asynchronous Agentic Solution
So what is this thing, this asynchronous service in the cloud that I talked about? AWS Transform for .NET is the first asynchronous agentic experience for modernizing .NET applications at scale. Scale is a very important point here. It starts with a .NET domain expert AI agent. Let me break that apart and tell you what that is. It has two pieces.
The first piece is a rules engine that we've built over the last 10 years modernizing .NET applications. So it's kind of old technology but still very useful. Rules engines happen to be cheap to run and fast to run, and that's good since this service is free today. The second piece is generative AI, where we're leveraging Amazon Bedrock and foundation models to add value and help our completion percentages get that 40 to 70% higher with generative value.
The other piece that the generative AI offers is it actually informs the rules engine, so it makes that rules engine better all the time. And of course you get the continuous improvement of LLMs. But we find that marrying the two systems together gives us the most deterministic result and continuous improvement result over time. That's why we built it that way.
As I said before, there is always a human in the loop, and that comes in two forms. There's an IDE experience for developers in Visual Studio 2022 and 2026, and a web experience for bulk transformations. Remember I said scale? Scale and bulk transformations in the web, and we'll talk about that in a second.
Developer Experience: Transforming Projects in Visual Studio
So let's double click into the developer experience a little bit. In the developer experience, you're able to transform these projects, so a solution or project or collection of them. In Visual Studio 2022 or 2026, basically your first step is to select which projects you want to transform. What we'll do is then execute an assessment step which assesses all of that. It's kind of that analysis phase but automated.
It comes back and gives you a report. That report then tells you, and transform itself, these are the steps that I'm going to take to execute this transformation. These are the things I'm going to do. It will tell you things that maybe it can't do. It will tell you things that maybe it would be hard for it to do, and it will tell you things that we could do pretty easily.
Once you review the plan, you could customize the plan as well. You could say don't do this, do this, or maybe take a different approach, use a different NuGet package. So you have some control over how it executes. Basically you right click and you say go transform.
So this is where the magic happens, and this is the part that I love the most about this. I'm a software engineer. I write code. That's what I do. And I don't like any kind of thing that ties up my machine or my IDE or my time. So once you right click and say transform, we take the code and we ship it to the cloud.
It builds in the cloud. We run it in the cloud. We run your tests in the cloud. It transforms in the cloud. It all happens. I could shut down my IDE, come back a week later, and it's going to check the status of the job. So it does not tie up an engineer or a machine or anything. And that's what I love about the service, the fact that it's asynchronous, because it's a transformation of a large project.
And when I say large, we work with customers that have monoliths with 1 million, 5 million, 10 million, and more lines of code. These things do not transform in one hour. It's days of work. But let it happen in the cloud and let it tell you when you need to do something. That's the way it works.
Web Experience: Scaling Modernization with Bulk Transformations
So web experience. Remember I said scale and bulk. So what is different about the web experience? As you might imagine in the web experience, we do not have access to source code like we do in an IDE. So how we achieve that is we connect to your source code repositories through code connections or S3. And we basically discover all the repositories that are in there.
We run transformations on entire repositories in the web experience. So we're not going project by project anymore. In fact, you could run 5, 10 at once, and we have customers doing that. The typical progression is people start with the IDE, get comfortable, and then they say hey you know I want to do a lot more at once, and that's when they move to the web.
But essentially the process is the same. You connect your source code repository, we discover the repositories that are there. We run an assessment, which is exactly the same as it ran in the IDE, that basically is a summary report of all the projects or all the repositories there, what could be transformed, what could not be transformed. The other piece to this that's a little different is private NuGets. So since we don't have as much access to source code, and if you want to specify the actual NuGets to use when we do the transformation, you could upload them as well or point at an artifact repository. So once you've done that, you've done your assessment, you specify your NuGets, execute transformation and go. And again, obviously this is a web app, so you don't have to worry about watching it or anything. You just come back and see it when you want to.
Live Demonstration: End-to-End Modernization Workflow with AWS Transform and Kiro
Okay, so the next piece to our presentation is going to be a demonstration. So what we're going to do is demonstrate an entire end-to-end .NET modernization workflow with two tools: AWS Transform for .NET, the asynchronous service that we've been talking about, and then Kiro, our AI-enabled IDE, which you may have heard of by now. I'm guessing you probably have seen a little bit of it around. So typically, people will use AWS Transform for .NET first, and then they will finish with Kiro, Q Developer, or pick your favorite coding assistant. It really doesn't matter.
So just a quick bit on Kiro. I like to say, when I think about Kiro, I think vibe coding my spec. So obviously you've probably heard about spec-driven development and how important it is to kind of contain and make useful vibe coding. And I'm a vibe coder just to be honest, like I love vibe coding, but I also recognize where it gets you. It gets you into the AI rat hole. Specs will keep you out of that rat hole, right? So it says, hey, after the AI builds all this awesome stuff, did you actually build what I wanted you to build? That's the whole point of it. That's all it is.
Okay, so what is the workflow we're going to show you in the demonstration? The first thing we're going to do is use AWS Transform for .NET to connect to our repositories and run our transformation. The next step will be I will download the code in the transformed branch and then complete the transformation and validate the application actually functions in Kiro. A cool thing I want to tell you is the Kiro part of the demo was all done on a Mac. So there's no Windows in any of this. It's kind of neat.
Okay, so here we go. I'm going to go over to the podium here and I'm going to kick off the demonstration. I will pause it at various points because there are key points, but basically this is what AWS Transform web console looks like. It starts with creating a workspace. Important thing: you do not need AWS console access to access this. So anybody can. An administrator will send you an invite and then you can get access, just like Q Developer. It's the same thing. I could use Q Developer or Kiro without accessing the AWS console. It's the same exact thing. And here we go.
So our first step will be to create a workspace. That was enter a workspace name. So interesting thing about a workspace while this is going: your workspace that you create in the web, the IDE automatically creates one for you as well, and when you're in the web, you can see the IDE workspace. So imagine I kick off a job in my IDE and I want to check the status of it. I don't even need to go to the IDE. I can go to the web and check it. So it's all the same back end.
You notice the interface has two sides. One, the left side is kind of like steps, like steps you click on. The right side is a more chat-based interface, sort of like an LLM that you can interact with. What I've just done here is I've kicked the job off and started, and the first thing we're going to do, as I said before, is connect our code repositories. So here I'm going to use CodeConnections, which means that my code repository has already been connected to AWS console. And that's an administrative thing, but you could also use S3 as well. Once we select the connector, I'll enter the connector information.
And then the assessment will start. So basically what it's going to do is look at that code repository and find all the repos in there, or that code connection, and it's going to look at, and this is GitHub. I'm connected to GitHub, so it's looking at all the repos. And now I can select which ones I want to assess. So you can imagine you could have hundreds in here, and that's what customers do. They'll have hundreds, and then they'll pick the ones they want to assess. I think I do like four in this example, and then I start the assessment.
So while the assessment is going, and in fact while anything is going, you could chat with this to understand where it is and what it's doing, and that's what I'm doing here. You notice, can you tell me the status of the assessment? I want to know, hey, how far along are you? Now I will say that this was five minutes after I started, but I cut that out so you guys didn't have to wait. But that's the point, right? It's asynchronous, but you could ask it, hey, where are you in this process at any time? I've also asked them to pull the work logs, and it pulled additional detail for me. The point of showing you this is just, hey, I can interact with it at any time to understand where it's at.
Once the assessment is complete, then we'll start the transformation. And let me pause right here. Okay, we are paused. Okay, so I wanted to point out a couple of things that are really important here. So you notice in the job details on the side, there's a branch name. When we're doing the web console and we're doing transformations, we're not going to do transformations on the branch you specify. We're going to create a new branch, right? Remember, human in the loop needs to approve everything. We're not going to go crazy. So that's the branch that I'll end up checking out and working on in Kiro afterwards. So that's the transform branch that you specify, and you're just giving it a name, essentially.
And now we're going to customize the plan and select the repository that I actually want to transform. We're just going to select one, which is BobsBookstore, which is a .NET Framework application, and we're going to kick it off. Now the transform is underway. What I've brought up here is to show you guys the work log. The work log is kind of neat to see because you'll see LLM activity in there, you'll see rules engine activity and overall service activity. It's super detailed. It's not something you're going to sit and watch a lot, but you could actually query it through the chat. Hey, tell me what's going on in the work log, so I don't have to look at it. That's what I did previously in the assessment.
Okay, and we'll just pause right here. Okay, cool. So now what has happened is my transformation has completed and the dashboard has popped up. The dashboard is going to give me the results of the job that I just ran, and you can see some high level things like, so remember I picked one repository, there were five projects in the repo, and you can see here that the repository was successful, the five projects were successful, but I have a failed test. One of the tests is failing. One of the things that AWS Transform for .NET does for you is run all your tests for you. So it validates that your tests work at the end of a transformation or don't. In this case they don't.
So what do we do next? What do we do next? We have two options. Option one is to continue the transformation within AWS Transform itself. So we have an incremental transformation mechanism which allows you to basically retry or continue from where you left off. I would use that in a situation where maybe only half of it was transformed or seventy-five percent of it was transformed, or maybe the build didn't complete. It's just like interacting iteratively with an LLM. If you've ever used a coding assistant, it's exactly the same. You need to iterate on these things to get them to get you where you want to go.
This is obviously a simple example for the demonstration here, and we just have one test to fix. So I'm going to use Kiro, AI enabled IDE, to fix this. But before I do that, I'm going to download. So here we're just checking the status of the test, and the last piece will be downloading what we call a transformation summary. The transformation summary report is a detailed report. It's more detailed than you're seeing in the dash. This is what customers do, and I tell customers to do. After your transform is done with AWS Transform for .NET, download the summary, take the summary, and upload it into your assistant and ask the assistant, what do I do next? That's essentially the next step.
So here you can see we've broken out the projects, you get package changes, files that have changed, and then we go project by project with the same kind of detail. Now in this case, it's one hundred percent successful, so you're not seeing a lot of red here. If some of these failed, you'd see, oh, some are partial and maybe there's something red. Those are the things that a coding assistant could key off to to help you complete the job. Excellent. Okay.
So if all works well, great. Before I kick off my next steps, let's talk about what happened in between that you did not see. I downloaded the transformation summary report. I also checked out the new branch to transform code onto my Mac. This is my Mac. So now I'm on a Mac, and this was a bit of an experiment. I didn't know if it would work. I was kind of going for it. I'm like, you know, it'd be awesome if this thing just built because I had already installed .NET on my Mac. So you download the checked out code, you download the report, you point Kiro at it and you ask it some questions, and that's what we're going to do.
Oh my. So here we go, we're going to open the project folder. Now, of course, I think I confessed to this earlier. I didn't use spec coding in this situation just because it's a quick thing. If there were a lot of changes and maybe it was only half done or 75% done and I had build problems, I might actually ask Kiro to interrogate the code and then create me a spec for next steps. It's probably what I would do. In this case, I'm just going to ask it a quick question for vibe coding. From a vibe coding feature, yep.
So here we go, and basically it says, hey Kiro, just transformed this project from .NET Framework 4.8 to .NET Core 8.0. And some of the tests are failing. Can you build the project, run the tests, and suggest fixes where appropriate. Now this is going to be hard to follow because you know how fast these things spit out stuff, but basically this is what it's going to do. The first thing it's going to do is build the project with .NET command line. .NET builds BobsBookstore.solution. And there goes the build. And it picked up that there's one test failing. After it ran the tests and now I found that there was a null in one of the tests. I won't say who put that there. But I think you guys know what I was doing.
And now it's going to fix that test and run all the tests and validate that they've passed, and all 20 tests are now passing successfully. So let me just pause this real quick and tell you, what, how does this mirror real activity? So, again, customers will take their project, they'll throw it at AWS Transform for .NET because it doesn't cost them anything in resources or cost. Just do it. Tell me, see how far you get. Great. Now I've got this report and I've got this code base that's at some point transformed, and then use your favorite coding assistant or AI enabled IDE to keep going. That's basically what it's doing. In some instances, I would actually send it, I would retry it or continue the transformation through AWS Transform if there's a big chunk of stuff left, right? And that's the idea. It's like let's get it as close to the end as possible, and again, it's an iteration just like with an LLM.
So are we done? We're not done. So it's cool, the tests work, but how do we determine functional equivalence? You got to know if the thing runs right in the new platform. Does this thing run on my Mac, on .NET Core? It's never been done before. So let's see. So now I'm going to ask Kiro, could you, hey, can you run this thing on my Mac for me? Hopefully, it's going to come up. There it goes.
We run the BobsBookstore application on my Mac in .NET Core used to be .NET Framework running on Windows. Pretty cool, right? Like I was stoked when I saw this. I was like this is pretty cool, but we have a problem, two problems, big yellow image missing boxes. Sorry about the yellow, but I thought it would have an effect. So obviously we have some images missing on our homepage. So the question is, what do you do next? I could talk to Kiro and tell it this.
What I did was I just took a screenshot of it and gave it to Kiro and said, "Can you fix it?" And I'll show you. You'll see me do that. I just want to let you know it happens pretty quick. So basically what I do is take a screenshot, cut and paste it into Kiro's chat, and ask it, "Hey, could you fix the homepage?" And that's what we'll show you now.
So I'd like to introduce you to Heidi, our journey of becoming one of the biggest AI subscribers in the world and how we are navigating through. So Kiro, the app is running. However, there are missing images on the main page. See image attached, and you'll see me paste it in there. So I just pasted it in there. Can you fix this? It's just a plain simple question.
At this moment, we feel frustrated, but I can see the issue. The images are commented out. What's interesting is it actually checks to make sure that the image files exist before it just uncomments it and runs it, which I was impressed by. I was like, that's exciting to me. You saved me a step, but that's what it does. It uncomments it, makes sure that the images actually exist, and then it's going to rerun the application. And there we are. Bob's Used Bookstore Certified, and the app's working on a MacBook Pro M4 and .NET Core.
Partner Ecosystem and Early Customer Success Stories
So that is an abbreviated example of what a modern .NET modernization workflow looks like with AWS tools, using AWS Transform for .NET and of course Kiro. And that's not always high based on the doctors can go use the pills as. Okay, so now let's talk about our partners and customers who have been either engaging their customers or customers that have endeavored to do this themselves.
So we launched AWS Transform for .NET general availability on May 15, 2025 with over 30 partners, and it continues to grow. And I will encourage if there are any partners in the crowd, there's a way to link. There will be a way to get in touch with us, but come up to me afterward. We would love to have more partners join the party. And I'll tell you why.
So at first you might think, well, you have this agentic service that takes resource need away. Why would a partner be interested in that? And the answer is the value around it, right? Because while this helps you transform code, AWS Transform for .NET helps you transform code and get you to Linux, to run on Linux. You still have, do I want to decompose my monolith? Do I want to rearchitect? Do I want to insert other technologies, right? There's a lot around it that partners are doing for customers.
So what partners that I work with have found is, hey, we could offer a lot more value to our customers because this AWS Transform for .NET in particular is taking a chunk of the work away. So what they can offer is now higher value. So let's talk about a couple customers, and I know Matt's waiting. He's one of our customers as well.
A couple customers who had some early success around our GA time frame. So The Hartford jumpstarted .NET modernization with AWS Transform. They had a vendor management application that was legacy. No one wanted to touch it. No one wanted to touch the code that was running in .NET Framework 4.8 on Windows. They wanted to move it to cross-platform .NET 8.
They were very surprised and pleasantly surprised that out of the gate, immediately when they threw it at AWS Transform, it basically transformed 8,000 lines of code in a couple of hours, which was 30% of the code base for this application. And Gaurav Petraar commented on this, who's Director of Software Engineering at The Hartford. AWS Transform accelerated our modernization efforts and improved the speed to market of our cloud migration initiatives. And not only helped us speed up legacy code transformation from months to weeks, but also provided our developers with valuable insights and suggestions throughout the process.
Another one of our customers, Experian. So Experian had a collection of seven applications all running on legacy .NET. Again, they didn't want to touch them. No one wanted to touch these applications. They also had an executive directive in 2025 to use Gen AI to accelerate and automate developer workflows. That was a thing for them. So what caught their eye about working with AWS was the agentic or asynchronous nature of AWS Transform for .NET. Hey, that's like automating transformation. That's what it does, right? It automates it.
So we worked with them to migrate these seven applications, and we automated almost 700,000 lines of code transformed, which saved approximately 300 engineering days. Apancholi, a Principal Director of Technology and Software Engineering Experience, said, "Using AWS Transform for .NET, we saved approximately 300 engineering days across seven projects, which supported one of our key OKRs to embed agentic AI and automation into our teams."
One of the things the first blurb says is improve development velocity and reduce technical debt, which is what they got out of this. By automating transformations and migrations, more engineers are assigned to building features for them and off legacy code bases, right? They do not have to assign as many engineers to modernization projects because they use our automation, and that's the exciting part of it.
Thomson Reuters Case Study: Cloud Journey and Modernization Challenges
I am pleasantly surprised to introduce Matt Dimich, VP Platform Engineering from Thomson Reuters Technology, our third customer story of the day. Thank you, sir. Appreciate it.
Hey everybody, my name is Matt Dimich. I lead the Platform Engineering Enablement team at Thomson Reuters, which essentially means I have a team of engineers and architects that get to go around to our developers and help them get to the cloud safely and quickly. If you're not familiar with Thomson Reuters, we serve over 500,000 customers across the largest law firms and governments to startups and solo practitioners. We have a global scale of about 26,000 employees with 4,500 domain experts and one of the world's largest trusted content ecosystems, and we're investing over $10 billion to transform how high-stakes work gets done with AI.
AI is not new to Thomson Reuters. We've been using AI for over 30 years and generative AI since 2023. In fact, we actually have multiple products already in the market using generative AI. One of our most recent ones is Westlaw Deep Research. It's an agentic capability that plans and executes multiple steps of legal research workflows. It invokes Westlaw tools like KeyCite, reads what it finds, and adapts its strategy in real time. But before I get too far along our AI modernization journey, I want to give you some context.
In 2015, Thomson Reuters started our cloud journey. Before that, we had hundreds of data centers globally that we were operating. We decided to go to public cloud, and we started just with cloud-native greenfield development. Just new projects went to cloud. Everything else stayed in the data center. But just a couple of years later, we ended up divesting half our company, and so in 2018 we started a project that gave us two years to exit seven data centers. That meant about 400 applications or about 10,000 servers.
Shortly after that, in 2021, we started a program four times that size to exit our three remaining owned data centers. These were the biggest, gnarliest, largest applications that we have that consisted of about 800 applications and about 40,000 servers worth of workloads. In both of these programs, as you can imagine, we had a variety of migration strategies. We didn't have time to migrate everything modernized. So because of that, we were happy to use Amazon Managed Services to get many of the workloads that we couldn't modernize to the cloud, the ones that were able to run in the cloud but not be cloud-native.
But this means that once we were done and now we're 95% in the cloud, we have a lot of technology that is not modernized and a lot of, hence, we started a cloud modernization program. So just because we had a whole bunch of applications in the cloud and we had a bunch of tech that could be modernized doesn't mean that we needed to modernize it. So for us, there were a few reasons, or two big reasons, why it was imperative to our business to actually start the program, which is critical for success.
The first was obviously increasing cloud costs. When you're migrating a massive amount of servers to the cloud, your cloud costs increase, but they increase at a rate that's unsustainable, and that was the big point here. Because we didn't have time to optimize during the project, we knew we had to optimize quickly afterwards.
So that was important. Number two is increased business agility. Generative AI lends a particular challenge to the legal industry, opening up even more competition to our business. So it makes sense that increased business agility that modernization brings is very attractive and very valuable to the business.
So with those two reasons for investing in a cloud modernization program, we had a bunch of challenges, and four of them I want to highlight to you along the way. The first one was scale. The technology landscape at Thomson Reuters is really large and really wide, and there are not a lot of one-size-fits-all patterns and attempts that we can do to modernize. That really makes it challenging and really plays into the second one, which is this fear of changing legacy code. We have a lot of really talented engineers at Thomson Reuters that love to innovate, but some of our core products go back many years and they take an intense amount of manual care to keep the level of stability and service that we have. And modernization really challenges that when you're going to start unpicking that and changing that.
Challenge number three is, and maybe one of the biggest ones, resource contention. The opportunity cost for us to not work on a feature for our customers is very large, and we have a little bit of migration fatigue right after migrating and migrating for about six years straight. It's really hard to get that next step going, that next business case, to do more of the similar work that's not features for our customers. Which meant funding the business case was incredibly important but also a big challenge. We needed that business case if we're going to be successful to help us with some of those other challenges, and illustrating the business benefits of a modern cloud-native architecture is not always easy to quantify.
Operationalizing .NET Modernization at Scale: Tools, People, and Process
So as Generative AI rolled out for our dev teams at Thomson Reuters, I would say over the last 18 months, we really had a goal and a mandate to make the most of Generative AI, to embrace a new way to work and get the most value out of that. And for some of us that was building it into our products like I had talked about, and for some of us it's employee use cases or developer use cases about how can we tackle some of the projects that you just couldn't staff, you just couldn't quite get across the line to get worked on. Now we have a chance to work on some of those migration projects.
So we started seeing individual teams using AI-assisted coding tools to modernize their code bases, and we didn't want to stop that. In fact, we wanted to see if there was a way to scale that at a larger level. In theory, we felt by deploying an agentic service like AWS Transform for .NET and a coding assistant like Amazon Q Developer, we could then assign more resources to feature building, the future of Thomson Reuters, and less maintaining legacy applications. So even though Generative AI is not perfect, and believe me, there's always an issue, there's always an error, there's something to finish up, we felt when we started and we still do feel that those that don't build that into your way of working are going to be left behind.
So we participated in the private preview for AWS Transform for .NET and we gave the service a try. For Thomson Reuters, we tried a number of different tools and the differentiator for us was scale with the web experience and being able to do multiple projects at once. Because we had developers using AI-assisted coding tools on a repo-by-repo basis that accomplished some smaller goals, but in order to scale and building out processes and people to go much wider, that's where AWS Transform for .NET really excelled. What used to take us months now takes us just a couple of sprints to get through.
So we kept working with the Transform team and we're continuing to expand our use of it today. We want to migrate and modernize all of our .NET Framework workloads. We're still migrating millions, about 1.5 million lines of code each month, working through legacy libraries, working through each issue, and iterating on that process until we get rid of all of our old .NET dependencies.
But that tooling is only one part.
So we ask ourselves how do we operationalize this into something that scales. Our goal is to accelerate the modernization of that whole estate, so we have the tools, and we can't forget about people and process. Of course, this whole thing impacts our people. In some of our larger teams, we have upwards of eight developers working on this full-time. With AWS Transform and AI-assisted dev tools, we can cut that number in half and get more modernizations done all at the same time.
In addition to making developers happy because no developers like working on migration projects, it also gives us the even better benefit of opening up more capacity to solve our customer problems and work on features for them. So to do this, we established a central team to operate AWS Transform and get really good at using the technology. That means that our app teams who care about the code and the features and our customers can really optimize their time on these modernization projects. Another big benefit that brings is it makes it easier to maintain a knowledge base of all of the things that you run into, all the problems, and learn from that and get faster each time for each project that we modernize.
All right, so we have the tools and we have the people figured out, but we still have a huge challenge in the process that we're going to go through. So yes, it's faster to modernize the code. However, you still need to use solid engineering practices that get that code reviewed and into production safely. This is where resource contention really gets hard. So if we have the central team that runs the code through AWS Transform, they get it as up to date as they can. There's going to be issues, and ultimately the developer or the development team that owns the code is going to have to come in at the end, likely help with a little bit of the final errors and issues, anything that's certainly domain specific and that kind of thing, and run it through the pipeline to production.
So that means our central team is made up of solutions architects and .NET developers that can get that as far along the process as it can. So if that app developer who owns that code is going to come in, if they're focused on a feature launch, they're going to have a hard time wanting to also do the modernization at the same time, hence the resource contention. So it takes a lot of communication and a lot of coordination to make sure that all of those priorities are lined up and that resources are available to deliver that safely. And that's not a job a developer wants to do, and so the advice here is to build that into your program, into your process, so that you account for that.
And this also means if you don't have a mature testing and deployment pipeline and processes, you're going to have a really hard time scaling a successful modernization program. To help solve the resource constraint, we built a modernization business case, and we primarily funded it based on cost savings. And so we said we can get from .NET Framework 4 to .NET Core, we can get to Linux, we can get to containers. Those are how we built the building blocks to put the case together to get the central team, to get momentum, and to show value. And at the same time, then we get all of the goodness of cloud native architectures and all of the business agility effects, but that's how we were able to fund it and get it going.
Lessons Learned and Looking to the Future: Preventing Technical Debt
So we have a bunch of lessons learned, and I want to just share a few with them today. Some of these are not revolutionary, but they are also easy to forget. And so the number one is start small. We ran into issues as we were trying to select from over 30,000 repos in our GitHub organization. We ran into issues trying to figure that out and get integrations there. We ran into issues with permissions in our cloud landing zones and getting access, all of those little normal things that you learn as you adopt a new service. We ran into all of those, but we went too wide a few times right away, and that slowed us down.
It's easy to get really excited when you see AI work and modernize, and then it's like, oh, I want to do the next one and the next one and make everybody happy. But really starting small to work through end to end right away will ultimately make you go faster. The next one, also a fairly intuitive one, is that the older the code base, the more complex your modernization is going to be. This should come as no surprise, but the point is to build that into how you think about it, right? Don't shy away. Some people have shied away from using the tool because the code is old.
We had a case where we had a desktop Windows application from many, many years ago that was turned into a web service, and so it used some UI libraries. And we ran into that, and we didn't expect to see that, but it didn't mean that the transformation was a failure.
It just means we had additional problems to solve afterwards, but we still got a lot of the way done. So don't give up on those, and plan that if you're looking at a large-scale program, you can kind of tell based on age and complexity what kind of time frame you might need.
The third one, building the central team was key to execute the modernizations and to help us scale. Our product engineers are absolutely the experts at their code base, but if I can get them a mostly completed modernization, that is what I want. If I can get 100%, that's what I want, because then all they need to do is accept the pull request and put that through our pipelines. And then the final and maybe the biggest one is people and process will be more critical to your success than technology. I don't say that to minimize the complexity of some of our applications or the advancement of AWS Transform, but what AWS Transform has done is make the lift for technology easy enough that it is no longer the biggest, largest, most gnarly part of the problem.
So as we look to the future at Thomson Reuters, our oldest apps will take the biggest effort to get from .NET Framework to .NET Core. We know that it'll be white glove service. We'll be engaged with each of those teams to get those through, but we also want to look to the future, and we don't want to get into the same situation again. And so we're building a way to keep our applications up to date in a way that scales and prevents tech debt in the future.
So for us, developers will be able to opt in so that when new versions of libraries are published, a pull request just shows up in their repo, and they can do that code review and send it through their pipelines. We're starting with .NET, but we plan to scale to every library, every language, every framework that we can think of and go from there. Because it's well known that smaller, more frequent changes are easier to test and deploy, so we feel the platform that Thomson Reuters developers use should empower that behavior.
All right, Derek, I'm ready to turn it back over to you. You could use those QR codes to get in touch with us, but we'd be happy to offer my team. I represent Go to Market for AWS Transform for .NET. We'd be happy to offer a white glove pilot to anyone who's here. So just get in touch with us, come up and talk to us after. We'd be happy to help get you guys started. And I think that's it for us today. Thank you guys so much for being here. Appreciate your time.
; This article is entirely auto-generated using Amazon Bedrock.
Top comments (0)