AI-Powered .NET Application Modernization at Scale

thomson_reuters · Legal · 2024 · source Agentic: yes · promotional bias: med · source-backed · extracted with prompt 0.5.4 (schema v2)

Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.

Problem

Domain: .NET application modernization

Thomson Reuters needed to modernize hundreds of mission-critical legacy .NET Framework applications from Windows-heavy infrastructure toward modern .NET, Linux containers, Graviton, and cloud-native deployment without stopping production systems or overwhelming engineering teams.

Constraints:

• the portfolio contains hundreds of applications and hundreds of millions of lines of code
• legacy .NET dependencies are deeply nested and compatibility-sensitive
• modernization cannot assume a greenfield reset or production shutdown
• transformations are not 100% complete and still require product-engineering follow-up
• human approvals are required for repositories, project selection, and deployment readiness
• ported applications must meet performance and Linux-readiness requirements

Architecture

Thomson Reuters adopted AWS Transform for .NET as an agentic modernization workflow. The service creates an end-to-end job plan through a chat/web experience, performs discovery to identify application type, lines of code, and assessment inputs, analyzes internal and external dependencies, applies predefined code conversion patterns, executes validation including unit tests, and produces transformation assessment and Linux-readiness reports. Humans approve repositories, selected projects, and deployment readiness. Remaining deltas after partial transformations are handled by product engineering teams using reports and AI-assisted tools such as Amazon Q Developer. The target is modern .NET running on Linux containers and potentially Graviton/serverless infrastructure.

Diagram confidence: reconstructed (reconstructed from prose).

flowchart LR
  legacy-dotnet-portfolio["legacy-dotnet-portfolio"] --> aws-transform-job-plan["aws-transform-job-plan"]
  aws-transform-job-plan --> discovery-stage["discovery-stage"]
  aws-transform-job-plan --> human-approval-gates["human-approval-gates"]
  discovery-stage --> dependency-analysis["dependency-analysis"]
  dependency-analysis --> code-conversion-engine["code-conversion-engine"]
  code-conversion-engine --> validation-stage["validation-stage"]
  validation-stage --> assessment-reports["assessment-reports"]
  validation-stage --> human-approval-gates
  validation-stage --> github-pr-branch["github-pr-branch"]
  assessment-reports --> product-engineering-followup["product-engineering-followup"]
  github-pr-branch --> product-engineering-followup
  product-engineering-followup --> linux-container-target["linux-container-target"]

Components

Data flow

A modernization candidate enters AWS Transform. The tool discovers the application type, lines of code, and assessment needs. It analyzes internal and external dependencies and compatibility gaps. It converts code using predefined conversion patterns, then validates transformed code through tests and approval checks. It emits a transformation assessment summary and Linux-readiness report with remediation guidance. AWS Transform commits transformed code to a branch and opens a PR; product engineers pull the code, inspect remaining deltas, and complete fixes before deployment to Linux containers or other modern runtimes.

Why this architecture

The workflow preserves human gates because modernization affects mission-critical production code and partially successful transformations still need engineering judgment. Discovery and dependency analysis are first-class because legacy .NET migration is not just a version bump: nested dependencies, deprecated APIs, Windows-only libraries, Web Forms, Win32 DLLs, and VB.NET can all block porting. Assessment and Linux-readiness reports convert automated transformation into actionable engineering work. PR-based handoff lets product teams review deltas instead of trusting an opaque code rewrite.

Models used: AWS Transform for .NET · Amazon Bedrock LLMs · Amazon Q Developer

Scale

• Thomson Reuters operates over 400 .NET applications on Windows servers.
  “currently we are operating over 400 .NET applications that are running on Windows servers.”transcript, stated
• The portfolio comprises over 500 million lines of code.
  “these applications, they are complex and they are mission critical comprising over 500 million lines of code”transcript, stated
• The team reported modernizing over 1.5 million lines of code per month.
  “Currently we are modernizing over 1.5 million lines of code per month.”transcript, stated
• Planning moved from months to weeks of execution.
  “from months of plannings to weeks of execution, right? So overall you increase the speed of your migration.”transcript, stated
• The migration target promised millions of dollars in savings and up to 40% operating-cost reduction from modernization choices.
  “we have estimated potential savings of millions of dollars by migrating from Windows to Linux, adopting Graviton servers and containerization.”transcript, stated

  “by modernizing this application, you can save up to 40% of total operating cost.”transcript, stated

Alternatives considered (roads not taken)

Manual and semi-automated modernization

Rejected because: It was labor-intensive, error-prone, and created collaboration bottlenecks for distributed teams.

Other .NET porting tools

Rejected because: They took significant time and effort, with months of planning and hurdles during implementation.

Assume AI transformation is fully complete

Rejected because: Transformations can be only 50%, 70%, or 90% successful, and product engineering must address deltas.

Greenfield rewrite or shutdown-based modernization

Rejected because: The company has production systems at millions-of-lines scale and cannot shut down or start over.

Patterns

human-in-the-loop-gate (governance)

Humans approve repositories, selected projects, and whether transformed code is ready to deploy.

tool-use-orchestration (orchestration)

AWS Transform orchestrates discovery, dependency analysis, conversion, validation, reports, branches, and PR handoff as a modernization workflow.

eval-driven-development (evaluation)

The transformation process includes unit tests, performance comparisons, transformation summaries, and Linux-readiness reports before deployment.

batch-offline-processing (orchestration)

The team runs transformations at portfolio scale, processing many applications and millions of lines per month rather than one manual project at a time.

Tradeoffs

Use AWS Transform as the modernization force multiplier.

Chose agentic AI-assisted transformation workflow over slow manual/semi-automated modernization.

Rationale: The team needed velocity, reliability, and intelligence at hundreds-of-applications scale.

Move from Windows servers to Linux containers and Graviton.

Chose Linux, containerization, and Graviton modernization path over continued Windows-server operation.

Rationale: The target reduces Windows licensing and operating costs while improving price/performance.

Keep human approval gates.

Chose approved repositories, project selection, and deployment readiness over fully automated end-to-end code migration.

Rationale: Mission-critical production systems and partial transformations require accountable engineering judgment.

Gotchas (what bit them)

Legacy .NET modernization is not a simple version upgrade.

Root cause: Applications contain deeply nested dependencies, deprecated APIs, runtime differences, and compatibility constraints.

Resolution: Run discovery and dependency analysis before code conversion, then use reports and engineering follow-up for unresolved gaps.

AI transformation does not reach 100% completion automatically.

Root cause: Unsupported libraries, Web Forms/Windows Forms, Win32 DLLs, VB.NET, and non-C# components can remain after conversion.

Resolution: Keep product engineers in the loop and use transformation logs/summaries plus Amazon Q Developer to close the delta.

Partially successful transformations still require disciplined handoff.

Root cause: Automated conversion may leave 10-50% unresolved depending on application complexity.

Resolution: Commit transformed code to a branch, create a PR, and use reports as the guide for product-engineering fixes.

Evaluation

AWS Transform evaluates applications through unit tests, before/after performance metrics, transformation assessment summaries, Linux readiness reports, and PR-based product-engineering review.

Metrics: unit test execution · performance metrics before and after transformation · transformation assessment summary · Linux-readiness report · remaining transformation delta · lines of code modernized per month

Outcomes

• planning moved from months to weeks of execution
• Thomson Reuters reported modernizing over 1.5 million lines of code per month
• developers gained time to build the future rather than maintain legacy systems
• the modernization path targets Linux containers, Graviton, and lower operating cost

The case spans over 400 .NET applications, more than 500 million lines of code, and more than 1.5 million lines modernized per month.