Legacy Application Modernization to Azure
Legacy Application Modernization to Azure takes an aging .NET or Java line-of-business application — typically running on Windows Server or SQL Server versions at or past end of support — and moves it to current, supported Azure platforms: Azure App Service or containers, with Azure SQL for data. The engagement covers assessment, a per-application modernization plan you approve, the refactoring work itself — accelerated with GitHub Copilot app modernization tooling, with every change engineer-reviewed and tested — and cutover with a rollback plan. Projects are quoted from $9,500 per application and typically run about 8 weeks, managed by Alex Nikulin.
What this engagement is
Most companies do not have a legacy-application problem in the abstract — they have one specific application: the one on the old server, on a framework nobody wants to touch, that the business still runs on. The support clock makes it concrete: SQL Server 2016 reached end of support on July 14, 2026, and Windows Server 2016 extended support ends January 12, 2027 — past those dates Microsoft ships no security updates without paid Extended Security Updates. There are two honest exits. Lift-and-shift moves the old stack into Azure VMs — fast, and we offer it as separate Windows Server and SQL Server migration services — but you still own an OS and an aging runtime. Modernization, this service, re-platforms the application itself: code upgraded to a supported framework, hosting moved to Azure App Service or containers where Microsoft manages the OS and runtime, data moved to Azure SQL where the version-upgrade treadmill largely disappears. The assessment decides, component by component, which treatment fits and what each costs — before you commit. We use Microsoft's GitHub Copilot app modernization tooling, generally available for .NET and Java, to accelerate assessment, dependency analysis, and framework upgrades; the tooling proposes changes, and our engineers review, build, and test every one against agreed regression cases, so the application you get back behaves the way the business expects, on a platform Microsoft supports.
Success criteria
What you receive
How the work unfolds
Inventory of the application, Copilot-assisted code and dependency analysis, end-of-support exposure, and data estate review. Output: a disposition for every component — refactor, replatform, retain, or retire.
Target architecture, framework upgrade path, data migration approach, test strategy, and a fixed written quote for the modernization phase — approved before the work begins.
The Azure target environment stood up: App Service or Container Apps, Azure SQL, networking and identity integration, and the CI/CD pipeline.
Framework and dependency upgrades — Copilot-assisted, engineer-reviewed — data layer moved to Azure SQL, configuration and secrets externalized, and authentication modernized to Microsoft Entra ID where in scope.
Regression suite executed against the agreed cases, data migration rehearsed and reconciled, and performance compared to the legacy baseline.
Final data synchronization and connection switch inside the agreed window, rollback plan armed, and hypercare immediately after.
Post-cutover monitoring and punch list, documentation, a recorded handover session, and the decommission plan for the legacy environment.
Prerequisites
Who does what
IT Partner
- Run the assessment and produce the per-component plan and the fixed written quote.
- Build the Azure target environment and the CI/CD pipeline.
- Perform the code modernization, reviewing and testing every tool-assisted change before it ships.
- Migrate the data and run the reconciliation checks.
- Execute the cutover with the rollback plan armed, and run hypercare immediately after.
- Deliver documentation, test evidence, the decommission plan, and a recorded handover.
Your team
- Provide source code, environment access, and subject-matter experts for assessment and testing.
- Approve the disposition plan and the modernization quote before work begins.
- Validate regression and acceptance test results with us.
- Schedule the cutover window and communicate it to the business.
- Own Azure consumption, licensing, and any Extended Security Update decisions for systems staying behind.
- Decommission legacy hardware after the agreed soak period.
What's not included
Limitations & technical notes
Frequently asked questions
What is included in Legacy Application Modernization to Azure?
An assessment of the application and its dependencies, a per-component modernization plan with a fixed written quote, the modernization work itself — framework upgrades, re-platforming to Azure App Service or containers, data migration to Azure SQL — regression testing against agreed cases, cutover with a rollback plan, and documentation with handover. The upgraded code lands in your repository and the application runs in your Azure subscription.
What counts as a legacy application?
Typically a .NET Framework or older Java line-of-business application running on Windows Server or SQL Server versions at or near end of support. The badge is not age — it is risk: an OS that will stop receiving security updates, a runtime the vendor no longer supports, and code nobody wants to change because there is no safe way to test it.
How is this different from lift-and-shift migration to Azure VMs?
Lift-and-shift moves your servers into Azure VMs largely as they are — fast, and we offer it as separate Windows Server and SQL Server migration services — but you still own an OS and an aging runtime. Modernization upgrades the application itself onto managed platforms, so the OS and runtime patching burden goes to Microsoft. The assessment frequently recommends a mix: modernize the app tier, replatform the database, retire what nobody uses.
How does GitHub Copilot app modernization fit in?
Microsoft's GitHub Copilot app modernization tooling — generally available for .NET and Java — assesses codebases, plans upgrades, automates framework and dependency changes, and helps generate deployment assets. It materially cuts the cost of the mechanical upgrade work. Our engineers review, build, and test every proposed change against the agreed regression cases: the tooling accelerates, people stay accountable.
Will the modernized application behave exactly like the old one?
Feature parity is defined by regression test cases agreed during assessment and validated by your subject-matter experts — for most legacy applications, observed behavior is the only reliable specification. Undocumented quirks discovered during testing are triaged with you openly rather than silently reproduced or dropped.
Why is pricing "from $9,500"?
Because modernization is scoped per application: codebase size, dependency health, data volume, and test coverage drive the effort. $9,500 is the realistic floor for a moderate single application; the assessment phase produces a fixed written quote for your specific application before the modernization work begins, and you pay after you approve delivery.
How long does modernization take?
About 8 weeks is typical for one application of moderate size: two weeks of assessment and planning, three to four weeks of modernization work, then testing, cutover, and stabilization. Portfolios, large data volumes, or thin test coverage extend it — the assessment gives you the real schedule before you commit.
Which Azure services do you modernize to?
Azure App Service for web applications and APIs, Azure Container Apps where the workload needs containers, and Azure SQL Database or SQL Managed Instance for data. The choice is made per component in the assessment plan — including the honest cases where a component has to stay on a VM for now.
What happens to our database?
It moves to Azure SQL Database or SQL Managed Instance, with schema compatibility assessed up front and the migration rehearsed before cutover; row counts and agreed reconciliation checks verify integrity. Where an older SQL Server version must persist temporarily, VM-based paths exist through our separate SQL Server migration services.
Our Windows Server or SQL Server is already out of support — how urgent is this?
SQL Server 2016 reached end of support on July 14, 2026, and Windows Server 2016 extended support ends January 12, 2027; past end of support, Microsoft ships no security updates unless you buy Extended Security Updates. Running exposed line-of-business systems on unpatched platforms is a risk decision only you can make — what we can do is get you an assessment quickly, so the decision comes with a real exit cost attached.
What if we no longer have the source code?
Refactoring needs source. Without it, the choices narrow to replatforming the compiled application as-is or rebuilding it, and both are quoted separately from this service. The assessment can still be worth running — it maps exactly what you have and what each path costs.
Is there downtime at cutover?
A planned window, agreed with the business, covering the final data synchronization and the connection switch — with a tested rollback plan armed in case it is needed. Because the modernized environment is built and regression-tested in parallel while the old system keeps running, the window is usually far shorter than people fear.
Do you modernize Java applications, or only .NET?
Both. The GitHub Copilot app modernization tooling covers Java upgrades and Azure migration patterns as well as .NET, and the Azure targets are the same — App Service or containers with Azure SQL or another managed database. Mainframe and midrange platforms (IBM i / AS/400, COBOL) are outside this service.
What happens after cutover?
A stabilization period with monitoring and a punch list, then documentation, a recorded handover session, and a decommission plan for the legacy environment. Ongoing operations and new feature development are available separately — and because the upgraded code and the Azure environment are yours, you are free to take either anywhere.