AWS re:Invent 2025 - Scale modernization with agentic AI featuring Thomson Reuters (MAM334)

🦄 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 - Scale modernization with agentic AI featuring Thomson Reuters (MAM334)

In this video, AWS and Thomson Reuters demonstrate how agentic AI accelerates .NET modernization at scale. Pradeep Bagchi outlines challenges in migrating legacy .NET Framework applications to .NET Core, including slow manual processes and complex dependencies. Lalit Kumar shares Thomson Reuters' journey modernizing 400+ applications with 500 million lines of code using AWS Transform for .NET, achieving transformations 4x faster while targeting millions in cost savings by moving from Windows to Linux containers. Yogi Barot reveals AWS Transform's tri-state loop architecture (analyze, transform, validate) and announces major updates: support for six new regions including Canada Central, Okta and Microsoft Entra ID authentication, .NET 10 support, and Windows Full Stack modernization that converts both .NET applications and SQL Server databases to Aurora PostgreSQL. Thomson Reuters now modernizes 1.5 million lines of code monthly, demonstrating how AI-powered automation enables developers to build the future rather than maintain the past.

; 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

Welcome to MAM 334: Setting the Stage for Modernization with Agentic AI

Hello everyone. How many of you here are visiting Vegas for the first time? Wow. And how many of you are attending re:Invent for the first time? Amazing. Just one piece of advice: always keep walking shoes handy. Don't wear heels or anything because there's a lot of walking here. I wish you all the best if you're here for the first time, and I'm sure you will learn a lot by the end of the week. Thank you for coming.

Good morning. Welcome to MAM 334. First of all, thank you for attending our session on how to scale modernization with the help of agentic AI capabilities. I plan to start this session with three questions as a little exercise together. Are you all ready? Let's do it. Raise your hand if you're working on or have walked on one or more modernization projects. That's a lot of hands, and that tells me you are in the right session.

Now raise your hand if you have a mandate to increase AI adoption, to reduce total cost of ownership, or increase return on investment for your line of business. Good, thank you for sharing that information with us. Now raise both your hands if you have a goal to do more with less, meaning saving money, reducing operating costs, or reducing total cost of ownership. Keep your hands up. Let's do a little stretching from here. From left to right, from right to left. Let the blood flow. Take a deep breath. Now I think we are ready for the session.

My name is Pradeep Bagchi. I'm an enterprise solution architect with AWS. Today I have with me Lalit Kumar, who is an AI solutions architect with Thomson Reuters, and Yogi Barot, who is a tech leader for Microsoft Workload with AWS. The three of us are going to share how you can supercharge your modernization project with the help of agentic AI capabilities.

Now let's look at our agenda for today. First, I'll start with the challenges, the transformation challenges we are hearing from our customers and the voice of the field. I'll also share what motivations are behind these modernization projects. Then Lalit is going to share his journey on how he is scaling modernization goals for hundreds of applications for his organization. Finally, Yogi is going to wrap up the session with best practices and how you can use AWS services and capabilities to scale your modernization goals.

Now let's start with the transformation challenges. But before I start talking about transformation challenges, I think it makes sense for me to define the term application modernization in the context of today's session. In the context of today's session, we'll be talking about taking your application and infrastructure to a higher value state. We'll be focusing on taking your legacy .NET Framework application to a .NET Core platform, and we'll be doubling down on three outcomes. Number one, unlocking innovation potential for your application. Number two, reducing the time to market of your application. And number three, reducing total cost of ownership.

The Transformation Challenges: Speed, Complexity, and Legacy Technology

Now coming back to the challenges, the first is speed. This process is slow. These legacy .NET Framework applications running on Windows are often monolithic and complex in nature, and that makes the modernization process a challenging endeavor. The traditional labor-intensive approach works, but it takes years before you realize the true value of the cloud and unlock the innovation potential for your application. This process is also sequential.

Your entire team has to wait for all the steps to be completed before they can move to the next step.

This also creates collaboration challenges for large organizations with geographically distributed teams and delays the decision-making process as well. The last thing is that these applications are built with old guard technologies. As we discussed before, organizations are seeing increased pressure to do more with less. Customers are facing scaling challenges and looking for ways to accelerate their modernization journey. But what about the motivations? No one does modernization for the sake of doing modernization. I'm going to talk about two motivations first: technology motivation and business motivations. When it comes to technology motivation, the first thing is performance. Performance is the key differentiator for why developers should focus on upgrading their applications to the .NET Core platform. The garbage collection is significantly better, the just-in-time compiler is superior, and according to a case study published by Microsoft, it can be 600 times faster than legacy .NET Framework 4.7. Second is supportability and security, which are far superior in the cross-platform world. The legacy .NET Framework is still supported, but innovations and development are much better in the cross-platform world. The third and biggest reason is cross-platform support. Your developers can start working on Windows PCs and also use macOS. Not only that, you can take those applications and deploy them to Linux containers. You can take your modernization journey further by deploying them to Graviton instances to get superior price-to-performance value. Last but not least, you get access to a large pool of developers. These new team members being onboarded to your team are very likely to be familiar with the new technologies. For technology managers, it is becoming risky to run these applications with old guard technologies.

Technology and Business Motivations: Why Modernize to .NET Core?

Now let's look into business motivation, because as a technology partner, you have to work hand in hand with your business partners to make this modernization goal successful. For business team members, cost is always a conversation. You can tell them that by modernizing this application, you can save up to 40 percent of total operating costs. You can not only eliminate costly commercial licenses but also leverage lightweight containers to reduce storage and compute costs. You can also get the scale and performance of the cloud. As your customer base grows and your organic revenue targets increase, this application has to scale. You can scale using lightweight containers or deploy them to a serverless architecture by leveraging AWS Lambda.

So what about the upgrading and porting process? We started this journey a couple of years back with Thomson Reuters with the tools and capabilities we had at that point in time. The typical process looks like this. It always starts with discovery. After discovery is done, you start analyzing the code. During the analysis process, you find out the compatibilities and incompatibilities before you start porting the code. Once the porting is done, you need to validate the code. If you have unit test cases, you need to convert them to the .NET Core platform. If you do not have them, then you need to write them from scratch. Then you eventually deploy your application. If you find any post-deployment issues, you go back to the discovery and analysis phase again. This entire process is labor intensive because it's a combination of manual and semi-automated work. Because of that, it's error prone as well. For a company like Thomson Reuters with a geographically distributed team, they were also facing collaboration bottlenecks. They wanted a way to turbocharge their modernization project.

They also wanted to establish a synergy between the application team, which is their product engineering team, and the platform engineering team so that they can run this project together. To share their story, let me welcome Lalit, and he's going to share how he scaled modernization projects for hundreds of applications within his organization. Please welcome Lalit.

Thomson Reuters' Bold Commitment: Becoming a Content-Driven AI Technology Company

Thanks, Pradeep. Hello, everyone. Thank you for joining today's session. My name is Lalit. I'm working with the platform engineering enablement team as an AI solutions architect. In today's session, I'm going to share the story of how Thomson Reuters has leveraged Agentic AI to transform legacy .NET applications.

At Thomson Reuters, we have made a bold commitment to become the world's leading content-driven AI technology company. This transformation is most visible in the tools we deliver to our customers, like co-counsel, our agentic AI platform for tax, legal compliance, and advisory professionals. Now we are also transforming internally in how we build, modernize, and scale the very infrastructure that powers everything we do. Behind the scenes, we are evolving our engineering culture, accelerating the development cycles, and embedding AI into the way we work. There's a reason for this because to deliver professional-grade technology externally, we must operate like a modern tech company internally.

That's exactly what we are doing in platform engineering: empowering development and enabling transformation. One of our Thomson Reuters values is act fast, learn fast. Our principle we put into practice when we partnered with AWS as early adopters during the beta phase. Over the next few minutes, I'm going to share our transformation journey powered by Agentic AI.

At Thomson Reuters, we are working across decades of tech evolution: monoliths, microservices, .NET, Java, and more, all of it mission critical. Managing this environment takes time, and for every hour our developers are applying patches, upgrading libraries, or managing the infrastructure, that's the time we are not spending delivering new value to our customers. One of our major accomplishments is that recently we completed 95% of our migrations into the cloud. This move gave us a cleaner and more agile foundation to innovate on. It actually gave our teams the ability to spend more time on AI capabilities.

However, we were still carrying around a lot of legacy .NET code, and that legacy was slowing us down. It wasn't just old; it was competing with innovation. Our developers were stuck maintaining unfamiliar legacy frameworks that couldn't be replaced overnight. So we had to modernize, but we still had to remain fully operational, and that was the tension.

The .NET Application Landscape: 400 Applications and 500 Million Lines of Code

I see you said you have 40% of your workload which are .NET. Like how many lines of code are you talking about, how many applications are you talking about? Yeah, so that brings me to this slide. Let's take a look at our .NET application landscape. Currently we are operating over 400 .NET applications that are running on Windows servers, and that results in substantial costs due to Windows licenses. Based on our 2024 cloud consumption report, we have estimated potential savings of millions of dollars by migrating from Windows to Linux, adopting Graviton servers, and containerization.

These applications are complex and mission critical, comprising over 500 million lines of code that keeps our developers engaged every hour. Now let's take a look at an example of a highly complex web of dependencies between the various .NET components and the package dependencies. On a lighter note, this looks like our walking path this week at Vegas from our hotels to different venues, and this also reminds me of my morning path from all the way to Mandela Bay from the opposite side of the strip. But trust me, this is just a small screenshot of one of our .NET application's package dependencies.

Migrating a legacy .NET application from the legacy .NET Framework to .NET Core is not just a version upgrade. It requires rearchitecting the application to align with modern frameworks and runtime constraints. This image shows an intricate layer of interconnected dependencies, each with its own compatibility considerations. This is another screenshot from a .NET application showing the dependency map between various microservices and package dependencies. Manually analyzing these dependencies is a very challenging task because these dependencies are deeply nested. Most of these legacy APIs are deprecated or behave differently in .NET Core, so manually mapping these dependencies is labor intensive and prone to errors.

We started exploring AI technologies to address these challenges and ended up choosing AWS Transform for .NET. You might be wondering why AWS Transform for .NET. For us, it came down to three things: reliability, intelligence, and velocity. Since the beta phase, we have progressed from transforming a single .NET solution in Visual Studio to now running transformations at scale using the web experience. Before AWS Transform, we explored various .NET porting tools, and it took us a lot of time and effort. Project planning itself used to take a few months, and we faced various hurdles during implementation. However, with AWS Transform, everything changed.

The screenshot you see on the screen is a job plan from the web experience. The AI agent helps us create this end-to-end job plan along with all the background resources using a simple chat experience. The unified web experience provides centralized management and enables cross-team collaboration. I can clearly define the roles and responsibilities of team members working with me on the migration projects. I can assign them appropriate roles like approver, admin, or collaborator. There is also a work log that provides verbose logs with timestamps for future reference, and a dashboard that provides a complete transformation summary including important details like lines of code, number of projects, and transformation status.

You used AWS Transform to transform your code. Do you have any examples showing how it looks before and after the transformation? Sure. What you see on the screen right now is a couple of scenarios. This is scenario number one. Before the transformation, it is legacy .NET code with an XML-based web.config file. In the code, we are configuring authentication settings, for example, the 30-minute timeout XML attribute. AWS Transform for .NET identified the legacy pattern and converted the XML-based web.config file into a code-based Program.cs file. You can notice that the functionality remains the same. You can see the same configuration and timeout session settings, but it has explicitly configured the cookie security.

Let's look at another scenario with a similar XML-based web.config file. Here we are setting the target framework to the legacy 4.7.2. AWS Transform intelligently understood the legacy pattern and did something different. It split the code into two different files. In the legacy pattern, we had everything in just one file called web.config, which is an XML-based file, but here you can see it has moved the configuration into an appsettings.json file and moved the logic into a separate file which is a code-based Program.cs file. The functionality remains the same, but it is now more modern and secure by default.

We are modernizing for various reasons: speed, security, and cost, but for me, most importantly, we are modernizing for customer impact. We are running around 10 .NET modernizations in parallel.

These are millions of lines of code, not just side projects. AWS Transform is acting as a force multiplier, helping us move safely into production without shutting down or starting over. A company like ours doesn't get a green field reset, and these transformations don't run in isolation.

Post-Transformation Challenges and Bridging the Gap with AI-Assisted Tools

Now let's talk about some challenges. AI is not doing a 100% job for us. There is still a lot to do, and that brings me to this slide about post-transformation challenges. One of the biggest challenges we face with running these transformations at scale is maintaining the compatibility of the C code with external or third-party dependencies.

Let me give you an example. A lot of components have been developed internally which are not written in C. For example, some of our graphical components are written in C++ code. There could be other scenarios like web forms or Windows forms. They could also be unsupported libraries like Windows Win32 DLLs or VB.NET. This is why we need humans to address these challenges.

Being an early adopter gave us an opportunity to act fast and learn fast. It also helped our consumers do better planning to transform their production workloads. These transformations are never 100% success. A partially successful transformation could mean 50%, 70%, or maybe 90%. This is exactly why we work very closely with the product engineering teams to ensure end-to-end successful transformation.

So I have a question for you. How did you bridge the gap? Whenever we complete our transformation and are ready to hand it over to the product engineering teams, AWS Transform commits the transform code into a new branch in the GitHub repository and creates a new PR. We pull that transform code locally, and then in the IDE we use AI-assisted tools like Amazon Q Developer to transform the delta. There's always a delta remaining because of the various factors I was just talking about.

The transformation log and the summary that I mentioned using the web experience acts as a guide for the next set of transformations. Once we address all these issues, we are good to proceed with the next set of transformations and help our product engineering teams. With that, I would like to welcome Yogi to take us through the deep dive.

Deep Dive into AWS Transform: How the Magic Works

Good morning everyone. As Lalit showcased, modern applications with thousands of dependencies make it difficult to do a traditional manual transformation approach. With AWS Transform, we can use AI-powered automation to address that complex dependency. I'm going to showcase how AWS Transform actually works, where that magic is coming from, and what it is doing to help customers modernize legacy applications.

Let's look at the benefits. The first benefit is that it helps accelerate transformation of .NET applications by up to 4 times faster. Whether it's an analysis phase, dependency mapping, compatibility assessment, or refactoring the code, all of these times reduce as Lalit showcased for the Thomson Reuters use case, from months of planning to weeks of execution. Overall, you increase the speed of your migration.

Next is cost savings. Windows licenses cost up to 40% more than Linux servers, as mentioned earlier. Not only licensing with Windows, but it also comes with maintenance, upgrades, and support challenges. You can eliminate all of this. On top of this, if you can also save the transformation cost, let me ask you this question. How much did you pay for using AWS Transform? Absolutely nothing. Exactly, it's free of cost. So you save the cost required for all the modern transformation tools you are using for planning, for resources, for analysis, and for refactoring.

AWS Transform handles conversion, remediation, and refactoring of all these tasks. The third key aspect is quality. You can perform manual transformation, but how do you ensure that your quality is as good as possible? We use generative AI LLMs with deep .NET expertise infused into Amazon Bedrock large language models to handle this transformation. Because of that, you get the best quality of the ported code at the same time.

Let me ask you a question. How many of you have only one application in production? We don't have only one application, right? We have hundreds of applications, and in Thomson Reuters' use case, they had 400 such applications in production. To modernize these hundreds of applications at scale in parallel, that's another benefit of using AWS Transform.

Now let's deep dive into how it works. It comes with two experiences. One of them is the web experience. With the web experience, you have a React-based SPA front end where you can port your repository. If you are using GitHub, Bitbucket, GitLab, or Azure DevOps, you can point your repository to the web experience. Once you point your repository, you can select the projects within it, and once that's finalized, you can give approval to AWS Transform to start the transformation.

AWS Transform uses 300 different customized parameters that you can adjust to customize your transformation. If you have custom NuGet packages that you are using, you can even upload those and ask AWS Transform to use them. It generates a real-time transformation summary on the dashboard. If you have multiple projects, it uses a batch of 50 applications in each batch and performs the transformation using that batch approach.

Another important piece is that if you have multiple projects and multiple teams, we are releasing great news. We are going to have multi-user collaboration including your partners as well. Before, you could only have a workspace with a job that only one person worked on. Now you can have multiple teams, whether you are an IT administrator, a developer, a DBA, or a program manager. You can now collaborate together on the same AWS Transform workspace. Not only that, if you are a partner working on modernization with a customer, you can also collaborate on the same workspace. That's all available from now, 11 a.m. today. That's another great and exciting feature that just got released.

That's about the web experience. Next is the IDE experience. How many of you are developers? Lots of developers here. If you are a developer, you are used to working with Visual Studio IDE, right? We give you the same experience using Visual Studio IDE so that you can open your solution file and port it to a newer version using AWS Transform.

With the developer experience, there is a side-by-side comparison. The intelligent code differential highlights the difference between the two versions, one which is .NET Framework and another which is .NET Core. Now you can see what's been changed so you can easily understand the transformation. With the IDE version, another thing is you can also generate documentation. It will point to the .NET documentation as well so that you can learn as you are doing the transformation.

Which experience is good and which one is bad? There is no good or bad experience. It depends on your personality. Let me ask you this question: which one did you start with for the Thomson Reuters use case? We started with the IDE experience because we started small and then we started scaling out using the web experience. So if you are a developer and you just want to do a POC for one application, you start with the IDE experience. If you are a DevOps personality, you can start with the web experience. I have seen customers start with the web experience and then decide to do something different. You know what, we don't even know how many applications are .NET Framework because you have hundreds of applications in a repository.

If you want to do a full scan to find out how many of them are .NET Framework applications, you can see what the overall transformation summary looks like for all the projects and create a business case. You can take it to your management and showcase what you have, how much cost savings opportunity exists, and why you should modernize these applications. This will help you make a decision and then take one application, go to the IDE version, and try to port and transform it using AWS Transform. If there are any failures, you can go back and forth as well.

Let me show you how it works. On the left here is your .NET Framework application with a solution file containing multiple projects, the traditional .NET web.config file, business logic, and unit tests. When you feed that into AWS Transform, it goes into a tri-state loop: analyze, transform, validate, analyze, transform, validate. We call it a tri-state loop because it has to continue the porting until it finds the best fit. It converts your .NET Framework application's web.config to program.cs. The business logic is converted using thousands of predefined code conversion patterns that we have. It goes through that and performs the conversion, and in the validate phase it does the validation as well. Your unit tests are executed, and one more thing is to check for approval. There is always a human in the loop because you want to make sure that before you get started, you need a human to approve the repository, approve how many projects you are selecting, and approve that your transformation is ready to deploy.

Now let me walk you through the deep transformation stages. The first stage is the discovery stage. This is where AWS Transform determines the number of lines of code, what type of application it is—whether it is a Windows Forms application, Web Forms application, WPF application, or MVC application—and what is in your portfolio. It identifies the number of lines of code as well as what is required for doing an overall assessment.

The next phase is the analysis phase. This is where dependency mapping happens. It identifies whether you have internal dependencies or external dependencies. Your solution can depend on multiple projects within it, or you can have one solution file that depends on other solutions, or you can even have external dependencies with another repository. Everything is identified at this stage. AWS Transform supports 250 NuGet packages, so it does third-party library assessment, identifies the DLLs, identifies the API calls, and performs all analysis and generates a detailed assessment report at the end of this stage.

The next stage is the planning phase. In this stage, AWS Transform creates an actual transformation strategy. It determines what timeline is required and how many resources are needed. The project management work is done in this planning phase by AWS Transform, and at the end you get an AWS Transform administrator approval.

The fourth phase is the execution phase. This is where the actual magic happens. This is where the automatic code conversion occurs. We have thousands of pre-trained different .NET transformation code patterns. It goes through them until it finds the best solution, and at the same time, if you have any unit tests supplied with your project, it executes those unit tests as well.

Then lastly, the validation phase. How many of you have a performance problem in your legacy .NET Framework application? You want to make sure the ported code also meets the performance requirement—that it is at least the same or better. With performance metrics evaluation before and after, it ensures proper checking before you do the transformation. Then it creates the transformation assessment summary report and lastly creates the Linux readiness report. Now let me ask you this question, Lalit. What is your end state goal for deploying this application which you modernized? We definitely want to run these on Linux containers.

So the question is, how do you know if your application is Linux ready? AWS Transform will give you a Linux readiness report. It makes sure that the ported code is now ready to run on Linux, and if there are any gaps, it will list them out and provide remediation steps so you can address those issues.

Security, New Features, and Windows Full Stack Modernization Announcement

Now let's talk about the security of this service. Security is job zero at AWS. Many customers ask me about regional availability. I'm from Canada, so when AWS Transform for .NET first started, it was only available in US East and Frankfurt regions. Customers asked me when it would come to Canada Central because some government standards require keeping code within your region. I'm happy to announce that as of today, we have started supporting six more regions, including Canada Central, so all our Canadian customers can take advantage of it right now.

Let's look at this from a security perspective and how this service works. Only an authenticated user with proper identity management credentials can access AWS Transform. When the request goes to AWS Transform, it passes through an API Gateway, and this connection itself is encrypted with TLS 1.3. The API Gateway is where AWS Web Application Firewall handles rate limiting and request filtering.

When the request goes further, it uses temporary processing to perform the transformation. If you are using the IDE experience, the work is done locally in your environment. If you are using the web experience, it creates a temporary EC2 instance in your VPC, and this instance is destroyed after the transformation is complete, so all data is purged and we don't keep this data permanently. It's all temporary processing. For any temporary storage needed during this process, we use Amazon S3, and that storage is encrypted with AWS Key Management Service, or AWS KMS. If you want to use your own custom keys, you can also do custom key encryption on top of AWS Key Management Service.

Another important aspect is authentication. Until now, AWS Transform only supported IAM authentication through Identity Center, but as of today, AWS Transform also supports Okta and Microsoft Entra ID as authentication methods. This allows for broader collaboration between different authentication identity providers using AWS Transform. All API calls and audit activities are logged through AWS CloudTrail, and you also have Amazon CloudWatch available for detailed monitoring.

For those who tried AWS Transform when it was released in May, you may remember that it did not allow you to continue from a failed job—you had to redo the entire process. I'm happy to share that starting today, you can restart your failed jobs and continue from where they stopped. You can also collaborate with multiple teams and multiple roles, such as administrator, contributor, and read-only roles within AWS Transform. Everything is stored in AWS CloudWatch, which you now have access to. Previously, the data was still being stored, but you didn't have access to it. We listened to your feedback and customer requirements and made this information available so you can understand what the service is actually doing. CloudWatch monitoring is now available for you as well.

Every customer I speak with about AWS Transform asks me the same question: if my application is in Windows, if it's an MVC application, if it's a WCF application, is it supported? What is supported and what is not? Looking at the supported source .NET versions, if you have .NET Framework 3.5 and up, .NET Core 3.1, .NET 5.x and beyond are all supported.

We started supporting .NET Standard 2 at 11 a.m. as well. The destination is .NET 8. We are happy to announce today that if you are looking forward, we can also put your application on .NET 10 now because that's the newest long-term support version Microsoft released earlier this month, and we are now supporting that as a destination as well.

One of the things you mentioned in your presentation as a post-transformation limitation that you had in web forms, right? Now we can have those converted into Blazor as well. So you can also plan that for your future project to convert those ASP.NET web forms into ASP.NET Core Blazor. If you have MVC Razor or ASP.NET pages, those can also be converted into ASP.NET Core.

Here comes the excitement. Before I click on the next slide, I just want to make sure I got the permission from my team. Good. All right, so tell me about what database you are using, Lalit, for your .NET application. Mostly SQL Server. OK, so we are happy to announce today that we will be starting the Windows Full Stack modernization, which includes your .NET as well as SQL Server database. So now if your application has SQL and .NET together, your SQL will be modernized to Amazon Aurora for PostgreSQL. AWS Transform will help you do a Windows full stack end-to-end modernization.

This is big news for me because I have been a DBA my whole life, and I know how difficult it is to convert from SQL Server to Aurora PostgreSQL because both of them are different engines. The schema conversion itself is challenging. T-SQL to PL/pgSQL conversion, transaction semantics are different. Even the optimization, the optimizer, query tuning, everything works differently. Indexes are also working differently, as well as the security. Trust me, AWS Transform for Windows Full Stack modernization handles everything in the backend. It removes all manual intervention and does the schema conversion to Amazon Aurora PostgreSQL.

Now you may ask, how about my data? You can also convert your data to Amazon Aurora PostgreSQL. As the first step, it converts the schema. As the second step, it does the data migration. You will ask me a question: Hey Yogi, how about my application? It also modernizes the application which has SQL Server code written within the application, converting that to Amazon Aurora PostgreSQL code. So it's a full stack end-to-end modernization, and we are proud to announce today that it will be available for all of you to start using in all eight regions that we are supporting AWS Transform.

Outcomes, Best Practices, and Call to Action: Your Turn to Transform

That's big news. You can hear more in the keynote tomorrow about more details as well. If you want to learn more about it, we have many sessions. Embargo sessions will be available for you in your catalog. Check out the re:Invent catalog for this topic and mark that in your calendar as well. There are more resources to learn more about it, but before I go to that stage, I would like to ask Lalit to say, can you tell about what's the overall outcome of your modernization? Sure, I'm happy to talk about it. We have come down from running transformations for a few months to just a few sprints. Currently we are modernizing over 1.5 million lines of code per month. This is possible because we are working closely in synergy with the product engineering teams, and all the initial POCs that we did helped a lot to do proper planning and ensure our consumers do a complete end-to-end transformation using AWS Transform for .NET.

One important thing I would like to say here is that it gives our developers the time to build the future and not maintain the past. That's exactly what you said. Since, as I understand, you are still transforming, right? Yes, it's just the beginning. It's something that is still running for the Thomson Reuters workspace right now. They are still transforming the code, so they have started. Now it's ongoing.

Now it's your turn. The message I would like to give is free of cost. Identify your sample application and understand and experience it yourself. Try it out firsthand for your sample application and see how it looks for you. If you need more help, do a POC. Reach out to your account team, and then reach out to us and we can help you do the POC and find out the cost savings you can get.

Estimate the savings and then present a business case to your management to see how much it can help you save on costs. Lastly, AWS Transform will help your modernization take to the next level. Instead of running a slow, steady, and manual modernization, now you can have a fast, AI-based, and parallel modernization for your application. We have created a case study working with Thomson Reuters. Here is a QR code to link to that case study.

There are more resources for AWS Transform and we have more sessions and hands-on workshops. Please check out this QR code because it has the workshop for this new Windows full stack modernization if you want to see how it works. There are builder session workshops and also workshops on using AWS Transform for .NET as well. Check out all the resources that you have available.

Looking at the time, I'm going to ask Lalit a question before I hand it over to you for questions and answers. Can you tell me the best tips that you have for this audience? I can think of a couple of them right now. I think the first one would be to start small and then you can scale out using the web experience, so you don't have to worry even if you want to start with a POC. Most importantly, be ready to face some challenges. There will be failures for sure because these transformations are never 100% successful. You can use AI-assisted tools to transform the data, and there's always a human in the loop.

Thank you very much for sharing those tips. We are here, so if you have any questions we can answer. We purposely kept some time for question and answers because we know that you might have a lot of questions. How about ADO.NET support? It's supported right now. How about NTT framework support? It is supported from NTT framework to NTT framework core. How about VB.NET? That's coming up. So any other questions that you might have, we are here to help.

Having said that, we're going to wrap up this session. Thank you everyone for joining. You can ask any question that you have for us. We'll be here to answer the questions and please don't forget to fill out the session survey. It's very important for us to get the survey results. Thank you.

---

; This article is entirely auto-generated using Amazon Bedrock.