Modernizing WWF-heavy .NET Framework applications using AWS Transform

Question

I’m looking for guidance on modernizing .NET Framework applications that rely heavily on Windows Workflow Foundation (WWF), particularly when AWS Transform / Transform Custom is part of the modernization strategy.

Problem context

The application includes:
-ASP.NET (.NET Framework) hosted on IIS
-Extensive use of WWF for long-running, stateful business workflows
-Workflow persistence tied to runtime behavior and SQL-based tracking
-Tight coupling between workflow execution, application state, and deployment lifecycle

While AWS Transform works well for rehost and replatform scenarios, WWF introduces challenges because its execution and persistence model does not have behavioral parity in modern .NET runtimes.

Specific challenges
-Workflow execution semantics that depend on full .NET Framework
-Long-running workflows surviving restarts and deployments
-Difficulty determining whether workflows should be:
    -retained on .NET Framework,
    -isolated as-is,
    -or replaced incrementally

What I’m looking for

I’d appreciate insights on:
-How teams are handling WWF-dependent workloads during modernization
-Whether workflows are typically retained during initial cloud moves
-How AWS Transform Custom is being used to flag WWF as a modernization blocker
-How risk is managed when workflows cannot be modernized immediately
Any experience-based patterns or lessons learned would be extremely helpful.

re:Post Agent · Accepted Answer

AWS Transform for .NET is designed to help modernize .NET applications by converting Windows-based .NET Framework applications to cross-platform .NET. However, Windows Workflow Foundation (WWF) presents specific challenges in the modernization process.

Based on the available information, AWS Transform for .NET has limitations when it comes to certain Windows-specific technologies. While it can successfully transform many aspects of .NET Framework applications, there are components that may require special handling or manual intervention.

For your WWF-heavy application, you might consider a phased approach similar to what The Hartford implemented for their Vendor Management application. They modernized their service and data layers using AWS Transform for .NET while planning a separate initiative for UI modernization. This approach allowed them to make progress while addressing more complex components separately.

When dealing with WWF-dependent workloads, you might need to:

1. Use AWS Transform for .NET to analyze your entire application portfolio to identify which components can be automatically transformed and which require special handling.

2. Consider a strangler pattern approach where you gradually replace WWF components with modern alternatives while keeping the existing workflows operational during the transition.

3. For workflows that cannot be immediately modernized, you might need to retain them on .NET Framework temporarily, possibly in isolated services, while modernizing other parts of the application.

4. Leverage the portfolio assessment capabilities (such as those provided by CAST Highlight when used with AWS Transform) to group your applications into "waves" for transformation, from "ideal" to "complex" candidates.

The modernization process with AWS Transform typically includes analyzing codebases, creating transformation plans, and running transformations by updating NuGet packages and replacing deprecated APIs. For WWF components, you'll likely need additional planning and potentially custom solutions to address the workflow persistence and execution model challenges.

While AWS Transform can help accelerate many aspects of your modernization journey, the WWF components may require specialized strategies and potentially more manual intervention to ensure business continuity during the transition.  
**Sources**  
[Accelerating .NET modernization with AWS Transform for .NET and CAST | Microsoft Workloads on AWS](https://aws.amazon.com/blogs/modernizing-with-aws/accelerating-net-modernization-with-aws-transform-for-net-and-cast/)  
[Modernizing .NET with AWS Transform - AWS Transform](https://docs.aws.amazon.com/transform/latest/userguide/dotnet.html)  
[How The Hartford jumpstarted .NET modernization with AWS Transform | Microsoft Workloads on AWS](https://aws.amazon.com/blogs/modernizing-with-aws/how-the-hartford-jumpstarted-net-modernization-with-aws-transform/)  
[AWS Transform for .NET, the first agentic AI service for modernizing .NET applications at scale | AWS News Blog](https://aws.amazon.com/blogs/aws/aws-transform-for-net-the-first-agentic-ai-service-for-modernizing-net-applications-at-scale/)

Venkata Thej Deep Jakkaraju · Answer

AWS Transform for .NET modernizes APIs and dependencies well, but WWF seems to be the hard stop.
In real systems, the challenge isn’t Windows compatibility. It’s WWF’s reliance on long-running, in-process, SQL-persisted state.
For teams modernizing WWF-heavy apps:
• Are you isolating workflows first, or replacing them directly?
• Step Functions vs. Durable Functions, what drove your choice?
• How are you extracting business intent from workflow definitions without rewriting everything?
Curious how others are handling workflow persistence, correlation, and resumptions during modernization.

Modernizing WWF-heavy .NET Framework applications using AWS Transform

Add your answer

Relevant content