Expertise
.NET migration and modernization
Modernizing a production application is not a version-number exercise. The real job is reducing risk while evolving architecture, delivery and operations.
Start with risk, not the target version
A .NET migration starts by identifying what can break: dependencies, API contracts, data access, pipelines, hosting and undocumented behaviors. On critical systems, the non-regression strategy matters as much as the porting work.
.NET Framework to modern .NET
My work spans historical .NET Framework applications and recent platforms on .NET 8 and .NET 10. At Aon, modernization combined Angular, .NET Core APIs and Azure migration. At ENGIE GEMS, microservices moved from .NET 6 to .NET 10 with unit tests and a full non-regression campaign.
Modernize delivery too
A modern codebase with an old delivery path is still difficult to operate. Modernization can therefore include CI/CD, quality gates, build security, observability and documentation. Recent repository and pipeline migration from Azure DevOps to GitHub fits that pattern.
Frontend and architecture
Legacy is not only backend. I have also worked on moving historical frontends to Angular. The boundary between UI, API and business services should allow independent evolution without adding layers just for the sake of layering.
Success is not “the solution compiles on .NET 10”. It is “the new version behaves as expected, deploys reliably and remains operable in production”.