Work / Backend & cloud
In progressAI-assisted Enterprise Modernization
Discovery and validation planning for a move toward .NET 10.
I plan technical discovery and a representative POC for a legacy enterprise system moving toward .NET 10 and ASP.NET Core, with existing business behavior as the starting point.
Discovery & validation planning · In progress
The engineering question
I am responsible for technical discovery and migration POC planning toward .NET 10 and ASP.NET Core. The question guiding this work is how to choose a representative flow when existing business behavior needs to be preserved.
That starts with understanding what the current system does, which dependencies shape its behavior, and which observations would make a migration decision easier to review.
How I approach the planning
I use a bounded scope to turn a broad migration into specific compatibility questions. AI assistance helps with code understanding and specification work; I review those outputs as part of the planning.
- Organize existing behavior and migration dependencies.
- Identify questions that require a representative proof of concept.
- Plan behavior comparison between the current implementation and the proposed target.
- Review AI-assisted explanations against the behavior and dependencies being documented.
What the POC needs to answer
The planning approach is to start from observable behavior: choose a bounded flow, describe its inputs and expected outcomes, and identify the dependencies that could change during migration. A useful POC should make those questions concrete enough to test.
The comparison needs to cover both expected outcomes and failure cases. An explanation or proposed change becomes useful when it can be checked against those expectations.
A representative POC: catalog availability
Independent teaching example · Not executed
Consider a fictional catalog page: a signed-in member looks up an item’s availability at a location. I would choose this small, read-only flow because it crosses routing, authentication, validation, a service boundary, and response rendering in one request.
- Receive the item and location
- Check the session and input
- Read a fixed inventory fixture
- Render availability or an error
The illustrative request is GET /catalog/availability?item=DEMO-42&location=LAB-A. Both versions would use the same synthetic data and equivalent test identities. External inventory access would be replaced with a test adapter so the comparison stays repeatable.
| Scenario & fixture | What to compare |
|---|---|
| Available itemSigned-in member; DEMO-42 at LAB-A; fixture quantity: 7. | Both versions show 7 available units, the same item and location, and the same permission outcome. |
| Invalid requestLeave the item code empty. | Compare field validation and HTTP behavior. The inventory adapter must not be called. |
| Expired sessionRepeat the request without a valid session. | Compare the authentication challenge or redirect and return URL. No inventory data should appear. |
| Dependency timeoutMake the inventory adapter return a controlled timeout. | Compare the user-facing error, HTTP status and retry behavior. Check that internal error details stay out of the response. |
How I would make the comparison reviewable
First capture the legacy response for each fixture, then run the same request against the ASP.NET Core slice. Record the status, redirect, visible business result and adapter calls side by side. Agree on any normalization, such as request IDs, before comparing; a changed business value is a mismatch to investigate, not something to normalize away.
A mismatch would keep that scenario open until its cause and intended behavior are agreed. Passing this slice would support the next POC decision; write transactions, real infrastructure and load would still need their own checks. All names and fixtures here were created for this explanation and contain no employer material.
Related reference: Microsoft’s guide to ASP.NET Core integration tests. The scenario and comparison matrix above are my illustrative design.
Current status and next step
Technical discovery and POC planning are in progress; the broader migration and production deployment are not complete. This public record covers general methods, with verified milestones to be added as the work progresses.