AWS has turned agentic AI loose on enterprise modernization again, expanding its AWS Transform suite at re:Invent 2025 to include
full‑stack Windows modernization (now covering .NET applications plus Microsoft SQL Server), enhanced VMware migration agents, and new mainframe “reimagine” and automated testing capabilities — a clear push to use AI as a strategic lever for moving customers off rival platforms and into AWS services.
Background
Enterprise modernization has long been a battleground for cloud providers. Migrating business‑critical workloads — whether .NET apps tied to SQL Server, VMware virtual machines, or decades‑old mainframe systems — is expensive, risky, and politically fraught. AWS Transform, first previewed in various forms during 2024 and expanded through 2025, is AWS’s agentic‑AI answer: a set of specialized agents that
analyze,
plan,
transform, and in many cases
deploy modernized outputs into AWS. The pitch is speed, scale, and reduced manual effort: analyze large codebases and infrastructure inventories, create wave plans, convert code and schemas, and produce deployable artifacts and IaC templates. This release matters because it moves beyond single‑layer conversions (for example, porting .NET code) into
coordinated, cross‑layer modernization: database, app, UI, networking, and deployment. That changes the migration proposition — and raises new technical, cost, compliance, and vendor‑lock‑in questions that IT leaders must weigh carefully.
What’s new at a glance
- Full‑stack Windows modernization: Transform now supports coordinated modernization of .NET applications and their SQL Server databases, converting SQL Server schemas and stored procedures and refactoring dependent .NET code to target Amazon Aurora PostgreSQL (Aurora PostgreSQL‑compatible edition). The workflow includes discovery, schema conversion, data migration (via DMS), application refactoring (Entity Framework / ADO.NET), and deployment targets such as Amazon ECS or EC2 Linux.
- Transform for VMware – upgraded agentic discovery and network conversion: new agentic tools speed inventory, dependency mapping, network translation and IaC generation (CloudFormation, CDK, Terraform), and integrate with Landing Zone Accelerator templates for automated network provisioning.
- Mainframe “Reimagine” + automated tests: Transform for mainframe adds a reimagine modernization pattern — AI‑driven architecture redesign recommendations (e.g., monolith → microservices) — and automated test plan generation, test data collection scripts, and test automation scripts to reduce what historically has been >50% of modernization project timelines.
- Custom agent capabilities: customers and partners can extend Transform with custom transformation tasks and agents; there is an additional charge model for agent work on a per‑minute basis for custom agents. (Pricing and regional availability vary by feature.
Deep dive: .NET + SQL Server → Aurora PostgreSQL
What AWS now automates
The full‑stack Windows modernization agent inspects code repositories and SQL Server instances, generates wave plans, converts schemas and stored procedures, migrates data using AWS Database Migration Service (DMS), and updates .NET code (Entity Framework, ADO.NET, embedded SQL). It can also adjust connection strings and produce transformed code committed to a new repository branch. The current public availability at launch is US East (N. Virginia). Key automated steps include:
- Schema conversion: tables, indexes, constraints, identity columns, computed columns mapped to Aurora PostgreSQL equivalents.
- Stored procedure conversion: T‑SQL → PL/pgSQL with AI‑assisted rewriting and human‑in‑the‑loop review for complex logic.
- Application refactor: update ORM (Entity Framework) and ADO.NET providers, refactor inline SQL, and adjust connection management.
- Orchestration: wave planning for dependencies and CI commits for transformed artifacts.
Important constraints and classed limitations
The documentation and blog posts make explicit several constraints that materially affect applicability:
- SQL Server must be hosted on AWS (RDS for SQL Server or SQL Server on EC2) in the same region as the Transform job. On‑prem or other‑cloud hosts are not supported for automated transformation without cloning to AWS first.
- Feature classification: the Transform agent classifies objects into categories — standard SQL (high automation success), advanced T‑SQL (needs human review), and unsupported constructs (CLR assemblies, complex full‑text search, some SQL Server‑specific features) that will require manual refactor or replacement.
- SQL Server Integration Services (SSIS) and certain ETL/BI artifacts are not migrated automatically. These dependencies often need separate treatment.
Those constraints matter because many real‑world .NET applications rely on advanced T‑SQL features, CLR assemblies, or SSIS pipelines. The agent reduces effort for a good fraction of artifacts, but it is not a magical one‑click fix for all SQL Server dependencies.
Target database: Aurora PostgreSQL‑compatible edition
AWS targets
Amazon Aurora PostgreSQL‑compatible edition as the destination. Aurora is described by AWS and third‑party analysts as
PostgreSQL‑compatible rather than identical to community PostgreSQL — it uses a distributed, cloud‑native storage layer and engine optimizations that can deliver materially higher throughput in many workloads (AWS claims up to 3× throughput vs standard PostgreSQL in comparable configurations). That performance comes with cost trade‑offs: Aurora’s unique storage and I/O pricing model can be more expensive for general‑purpose workloads, but it can be more cost‑effective for I/O‑heavy workloads where provisioned IOPS would be costly on traditional RDS. IT teams must model expected I/O patterns and cost profiles before choosing Aurora by default.
VMware: discovery, network translation, and IaC generation
Agentic discovery and network translation
AWS Transform for VMware uses agentic AI to crawl VMware inventories, generate dependency maps, and translate networking constructs (VLANs, firewall rules, load balancers, ACLs) into AWS equivalents. The release highlights rapid generation of migration wave plans and network translations, plus the ability to output IaC in CloudFormation, CDK, and Terraform formats for easier pipeline integration. The tool can also generate Landing Zone Accelerator YAML to bootstrap secure multi‑account setups.
Why this is consequential
VMware footprints are large, and manual network re‑creation is error‑prone. Automating network translation and IaC generation reduces human error and speeds handoffs to cloud teams. However, automated translations can misinterpret bespoke firewall rules, third‑party virtual network appliances, or vendor‑specific features; human validation remains essential.
Mainframe: reimagine + automated test plans
Mainframe modernization has the highest potential complexity and risk. AWS Transform’s new “reimagine” pattern attempts to go beyond lift‑and‑shift or line‑by‑line translation by producing higher‑level architecture recommendations (microservices, event‑driven redesign, data lineage diagrams) based on extracted business logic and data lineage analysis. Automated test plan generation and test data collection aim to tame the testing burden that typically consumes a huge fraction of modernization effort. This is one of the most interesting and risk‑heavy uses of agentic AI: reimagining requires accurate extraction of decades of business rules, and then sensible design tradeoffs — something that still benefits from deep domain expertise and staged validation. The new test automation aids adoption, but teams should treat AI outputs as starting points to accelerate, not replace, traditional engineering rigor.
Pricing, custom agents, and the economics of migration
AWS describes many Transform features as free to try (you pay for the AWS resources created and consumed), but there are paid components and cautionary notes:
- Custom Transform agents: customers can add bespoke agent tasks and plugins; AWS has indicated these custom orchestration tasks incur extra charges measured by agent activity time (per‑minute pricing for agent work).
- Resource costs: transformed workloads often land on Aurora, ECS, or EC2 Linux. Those services bring their own compute, storage, networking, and I/O pricing, which can be higher or lower than Windows + SQL Server depending on workload. Modeling is essential.
- Licensing shifts: moving from SQL Server and Windows Server can save on license fees, but those savings must be compared against the cost of Aurora I/O, EC2 instance types, storage, and any partner or AWS professional services used to validate and run the migration.
A notable moment earlier in the Transform rollout: a controversial clause (reported by multiple observers) briefly appeared in AWS’s service terms that would have required transformed workloads to run on AWS for a minimum of 24 months. That clause was widely criticized and then removed; the incident is a reminder to read the fine print and confirm contractual terms directly with AWS before large migration projects. Treat any such restrictive language as a red flag and get formal legal and commercial clarification.
Risks, limitations, and where AI struggles
Technical limits of automated conversion
- Proprietary SQL Server features: CLR (.NET) assemblies, SQL Server Agent jobs, SSIS packages, and complicated full‑text search or indexed views may not translate cleanly and often require manual redesign.
- Advanced T‑SQL logic: complex procedural code, dynamic SQL, or code that depends on undocumented behaviors will need human review and refactor.
- Data semantics and scale: migrating schemas is one task; preserving performance‑sensitive indexing strategies, ensuring correct query plans, and tuning PostgreSQL parameters for equivalence are non‑trivial and often iterative.
AI uncertainty and non‑determinism
Agentic AI agents can take creative, non‑deterministic approaches to refactor code — sometimes beneficial, sometimes dangerous. Non‑determinism means reproducibility and traceability matter: track the exact agent inputs, configuration, and outputs; require human‑in‑the‑loop reviews; and maintain immutable artifacts for auditability. Repeated runs may yield different transformations; make sure CI/CD and git histories capture what was changed and why.
Operational and security risk
- Over‑provisioning and cost bloat: an AI that “chooses the technically superior option” may recommend Aurora clusters or instance sizes that are costlier than strictly necessary. Vet suggested topologies against real usage metrics.
- Compliance and data residency: the Transform agent’s requirement that resources be in the same region, and that SQL Server be hosted on AWS, has implications for data residency and regulatory compliance. Ensure the workflow meets audit and jurisdiction requirements.
Practical checklist for teams considering AWS Transform
- Inventory and classification: identify apps, DBs, and infra that are candidates; mark dependencies like SSIS, CLR assemblies, or external systems.
- Proof‑of‑concept: run Transform on a small, non‑critical app to evaluate automation accuracy and outputs (schema, converted code, IaC).
- Legal & commercial review: confirm current service terms and any restrictive clauses; document commitments in writing.
- Cost model: run a total cost of ownership model comparing Windows + SQL Server licensing vs target AWS architecture (Aurora I/O, EC2/ECS, data transfer).
- Testing plan: require human validation cycles, automated integration and performance test suites, and rollback plans.
- Security & compliance: validate that transformed artifacts comply with internal security baselines, encryption, and audit requirements.
- Vendor neutrality assessment: assess whether transformed artifacts lock you into proprietary AWS features (e.g., Aurora‑specific extensions) and whether that tradeoff is acceptable.
A pragmatic migration playbook (step‑by‑step)
- Prepare a sandbox AWS account in the target region and ensure secured access and IAM roles.
- Clone a representative SQL Server database into the supported AWS environment (RDS/EC2) if necessary.
- Connect code repositories to AWS Transform (GitHub, GitLab, Bitbucket, Azure Repos, CodeCommit supported).
- Run discovery and generate the SQL Modernization Assessment Report; review wave plans and identify advanced/unsupported objects.
- Execute a single wave: convert schema, transform stored procedures, run DMS for a sample dataset, and commit transformed code to a branch.
- Perform functional verification and run generated automated tests (supplement with custom tests).
- Iterate on refactor for advanced items flagged by the agent; apply human fixes where needed.
- Validate performance, tune database parameters and queries, and benchmark against the old platform.
- Deploy to a staging environment using the generated IaC templates; run full acceptance tests.
- Cut over with a data migration strategy (blue/green, rolling, or near‑zero downtime depending on business needs), and maintain a rollback plan.
Strategic analysis: strengths and red flags
Strengths
- Speed and scale: agentic AI speeds discovery and can automate large portions of tedious conversion work, which is valuable for enterprises with many legacy systems.
- End‑to‑end orchestration: coordinating app, UI, and DB transformation reduces integration friction and avoids the piecemeal “lift‑and‑shift then fix” approach.
- Ecosystem integration: the ability to output CloudFormation, CDK, and Terraform, and to deploy to ECS/EC2, helps teams align with existing cloud toolchains.
Red flags and caveats
- Partial automation: non‑automatable features are common; expect significant human work for edge cases.
- Cost traps: default recommendations may favor AWS services that increase long‑term spend or vendor dependency; budget and architecture reviews are required.
- Contractual risk: the short‑lived 24‑month clause episode shows the importance of legal diligence and asking AWS for written clarifications on commercial terms.
- AI governance: agentic AI introduces governance needs (change provenance, reproducibility, approvals) that many organizations are only beginning to implement.
Final assessment and guidance for WindowsForum readers
AWS Transform’s 2025 revamp is a bold, logical next step in using AI to automate migration work that traditionally consumes months or years. For organizations weighed down by SQL Server licensing, Windows Server costs, or monolithic mainframe architectures, these tools offer a compelling acceleration path — provided teams approach them with discipline.
- Treat Transform as a force multiplier, not a replacement for architects, DBAs, and security teams.
- Pilot early and invest in automated testing and observability to catch translation errors before they reach production.
- Build cost and vendor‑lock‑in models early; don’t accept technical superiority as justification for a one‑size‑fits‑all migration target.
- Insist on contractual clarity and retain the right to run transformed workloads where it makes commercial sense; confirm there are no implicit lock‑in clauses in current terms.
Agentic AI promises real productivity gains in modernization, but it also amplifies the consequences of mistakes. Use it to accelerate low‑risk, high‑value waves first, learn from those projects, and only then scale to mission‑critical systems. The smartest modernizations will pair AI speed with human judgement, governance, and a pragmatic view on cost and portability.
Conclusion: AWS Transform 2025 is a watershed moment in cloud‑led modernization — technically impressive and potentially transformative, but not a substitute for careful planning, legal and cost diligence, and human oversight. Organizations that treat the outputs as draft assets requiring validation will capture the upside while managing the risks inherent in agentic AI‑driven migrations.
Source: devclass
AWS Transform revamp uses AI to shift applications from Microsoft’s SQL Server • DEVCLASS