.NET 현대화이 목록의 모든 스택을 프로덕션에 출시해 왔습니다
레거시 .NET은 하나의 문제가 아닙니다. WebForms 앱, WCF 서비스 계층, WinForms 클라이언트는 각기 완전히 다른 이유로 발목을 잡으며, 견적의 정확도는 그 스택을 실제로 겪어 본 사람의 경험에 달려 있습니다. 저희는 아무도 열어 보고 싶어 하지 않는 VB.NET을 포함해 이 모든 기술로 프로덕션 코드를 작성해 왔습니다. 그래서 진단은 비용을 들여야 하는 조사 단계가 아니라 이미 가진 경험을 꺼내는 일입니다.
2002 – 2012ASP.NET WebForms↳Razor Pages 또는 Blazor 기반 ASP.NET Core
페이지 수명 주기, ViewState, 서버 컨트롤에는 대응되는 것이 없으므로 마크업은 실제로 다시 작성해야 합니다. 하지만 그 아래의 비즈니스 로직은 대개 그렇지 않으며, 둘을 분리하는 것이 작업의 대부분입니다.
2003 – 2010ASMX 및 WCF 서비스↳ASP.NET Core API, gRPC 또는 CoreWCF
바인딩, 동작(behavior), SOAP 계약은 그대로 이식되지 않습니다. 변경할 수 없는 외부 호출자가 있는 경우, CoreWCF로 계약을 유지하면서 그 뒤의 모든 것을 이전합니다.
2007 – 2015Silverlight 및 브라우저 플러그인 클라이언트↳웹 프런트엔드 또는 모바일 앱
이전할 대상 자체가 없습니다 — 런타임이 모든 브라우저에서 사라졌습니다. 이런 경우 애플리케이션이 실제로 무엇을 해야 했는지 범위를 정의하는 대화부터 시작합니다.
2008 – 2019DataSet, EF6 및 직접 작성한 ADO.NET↳EF Core, 필요한 곳에는 Dapper
단순해 보이던 이전 작업이 비싸지는 곳이 데이터 계층입니다. 쿼리 변환, 트랜잭션, 지연 로딩이 모두 다르게 동작하며, 문제는 컴파일 시점이 아니라 프로덕션에서 드러납니다.
2009 – 2016ASP.NET MVC 5 및 Web API 2↳ASP.NET Core MVC
이 목록에서 기계적인 이식에 가장 가까운 경우입니다. 실제 작업은 컨트롤러가 아니라 호스팅, 구성, 의존성 주입, 미들웨어 파이프라인입니다.
2002 – 현재WinForms 및 WPF↳최신 .NET 데스크톱, 또는 모바일에 적합하다면 MAUI
둘 다 최신 .NET에서 여전히 실행되므로 전면 재작성은 드뭅니다. 걸림돌은 지원이 끊긴 서드파티 컨트롤 제품군과 COM 상호 운용이며, 저희가 가장 먼저 확인하는 부분입니다.
모든 버전.NET Framework 클래스 라이브러리↳최신 .NET, 이전 기간 동안 멀티 타기팅
공유 라이브러리는 기존 시스템과 새 시스템을 나란히 운영할 수 있게 해 줍니다. 먼저 이를 멀티 타기팅으로 전환하는 것이 대개 이 목록의 나머지 모든 작업을 여는 열쇠입니다.
상시packages.config, 레거시 csproj, Windows Server 기반 IIS↳SDK 스타일 프로젝트, 컨테이너, 자동으로 돌아가는 CI
화려하지는 않지만 나머지 작업을 반복 가능하게 만드는 기반입니다. 마이그레이션이 끝나기 훨씬 전부터 효과가 나타나기 때문에 가장 먼저 하는 것이 맞는 경우가 많습니다.
한 번에 전부 갈아엎지 않습니다
이 목록의 어떤 것도 한 번에 교체하지 않습니다. 효과적인 방식은 스트랭글러(strangler) 패턴입니다. 기존 스택 옆에 새 스택을 세우고, 같은 URL 뒤에서 한 조각씩 옮기며, 기존 쪽에 남은 것이 없을 때까지 둘을 함께 운영합니다. 서류상으로는 느려 보이지만, 저희가 본 것 중 끝까지 완료된 방식은 이것뿐입니다.