01
Retire
Example: An internal report tool used by two people and duplicated by the ERP
Approach: Archive the data, point users to the replacement and switch it off.
Application Modernization
Application modernization services for legacy code
Old frameworks stop getting security fixes long before the business stops needing the app. Agnotic Technologies modernizes legacy applications at the code level, with tests first and small released steps, so the app keeps working while it moves to supported technology.
End-of-life upgradesTests before changeModule by moduleCutover with rollback
Trusted by global innovators
Modernization
What is application modernization?
Application modernization is changing the code of a working business application so it runs on supported frameworks and runtimes and can change safely again. Agnotic Technologies assesses each application, adds tests that capture today's behavior, upgrades or replaces end-of-life frameworks module by module, and cuts over without freezing feature work for months.
This page is about the code. Moving workloads to a cloud provider is covered by our cloud migration and modernization service, and healthcare systems have their own healthcare software modernization page.
Most modernization is an upgrade path, not a rewrite. A rewrite is right only for modules whose workflow no longer matches how the business runs.
End-of-life table
Which frameworks and runtimes are out of support?
Support status from each owner's lifecycle page, read on 21 October 2026. Your inventory decides which rows apply.
| Platform | Published support status | Risk of staying | Usual upgrade path |
|---|---|---|---|
| AngularJS (1.x) | Support officially ended in January 2022 | No fixes from the project, while browsers and libraries move on | Rebuild screens in a supported framework one route at a time, both running behind one shell |
| .NET Framework 4.6.2 | Support ends January 12, 2027 | Unpatched runtime after that date, and many newer libraries target modern .NET only | Move to .NET Framework 4.8.1 as a short step, or port projects to modern .NET library by library |
| Modern .NET releases | LTS gets three years of free support, STS gets two | Running a version past its end date after a missed upgrade | Plan each upgrade in the backlog and stay on LTS releases unless a feature needs STS |
| Python 2 | Sunset on January 1, 2020, with no fixes even for security problems | Unpatched interpreter and libraries that no longer ship Python 2 builds | Port to Python 3 with tests first, then upgrade dependencies |
| PHP release branches | Two years of active support, then two years of security fixes only | A branch past end of life gets no security fixes | Upgrade one branch at a time with automated tests at each step |
Portfolio assessment
Retire, keep, upgrade or rebuild?
Each application in the inventory gets one of these decisions, with the reason written down.
02
Keep as is
Example: A stable tool on a supported runtime with few changes planned
Approach: Leave the code alone and keep its dependencies patched.
03
Upgrade in place
Example: A .NET Framework web app with sound business logic
Approach: Add tests, then move the framework and libraries forward in small, released steps.
04
Rebuild by module
Example: An AngularJS front end on a healthy API
Approach: Replace screens route by route behind the same URLs, so users never switch apps.
05
Rebuild
Example: A desktop client whose workflow no longer matches how the business runs
Approach: Capture the rules from the old code and its users first, then build the new app and migrate data once.
Method
How do we change old code without breaking it?
Map the code and who knows it
Dependency map, build steps, test coverage and the people who still understand each module, recorded before any change.
Add characterization tests
Tests that record what the code does today, including odd behavior users rely on, so any change in output fails the build.
Create seams
Interfaces around the database, file system and outside calls, so modules can be upgraded or replaced one at a time.
Upgrade or replace module by module
Each step ships on its own. Inside the code we move toward a modular monolith; at the edge we route single URLs or API calls to new code.
Replace the data access layer
New data access code runs beside the old, and schema changes use expand and contract steps so both versions work on the same database.
Cut over with a rollback
Feature flags or routing rules move traffic gradually, and the old path stays available until the new one has run cleanly in production.
Failure points
Where do modernization projects go wrong?
Challenge
A big-bang rewrite freezes features for a long stretch and still misses rules hidden in the old code.
Agnotic approach
Modernize in released steps, and treat the old code as the specification until tests capture it.
Challenge
Refactoring starts before any tests exist.
Agnotic approach
Characterization tests come first, even for code that will be deleted later.
Challenge
Dependency upgrades are bundled into one huge change.
Agnotic approach
Upgrade one framework or library family per release, and fail the build on known vulnerable versions.
Challenge
The schema changes in one step and breaks the old code.
Agnotic approach
Expand and contract migrations keep old and new code working until the switch.
Challenge
The only person who understands a module leaves mid-project.
Agnotic approach
Knowledge capture sessions and written module notes early in the engagement.
Who do we modernize applications for?
Product companies with a legacy core
A revenue-earning product on an old framework that the team is afraid to touch.
Enterprises with line-of-business apps
Internal tools that still run key processes but block security reviews and hiring.
Companies after an acquisition
Inherited code on unfamiliar stacks that must be brought in line with the rest of the estate.
Teams on unsupported desktop clients
Windows desktop software moving to a web app without losing the workflows users depend on.
Startups whose first build has aged
An early version built quickly that now needs upgrading before the next stage of growth.
References
Lifecycle and engineering references
.NET support policyMicrosoft LifecycleAngularJSPythonPHPNIST SP 800-218 PW.4.4
Facts and sources
Facts behind application modernization
Published support dates from each framework's owner. We re-check them at the start of every assessment.
AngularJS support officially ended in January 2022, and the project points users to the actively supported Angular framework.
Source: AngularJS: version support statusMicrosoft's lifecycle page lists the end of support for .NET Framework 4.6.2 as January 12, 2027.
Source: Microsoft Lifecycle: .NET FrameworkModern .NET Long Term Support releases get free support and patches for three years, and Standard Term Support releases for two years.
Source: Microsoft .NET and .NET Core support policyThe Python core team sunset Python 2 on January 1, 2020, and has not improved it since, even when security problems are found.
Source: Python Software Foundation: sunsetting Python 2Each PHP release branch gets two years of active support, then two more years of critical security fixes only, after which it reaches end of life.
Source: PHP: supported versions
Scope and cost
What drives application modernization cost?
We do not publish prices. These factors decide the size of the work.
Size and age of the code
Lines of code matter less than how tangled the modules are.
Test coverage today
Little or no coverage means more characterization tests before any change.
Frameworks to move
One runtime upgrade is smaller than a runtime, a UI framework and an ORM together.
Data and schema changes
Schema changes need expand and contract steps and data checks.
Integrations
Each outside system needs contract tests that stay green through the upgrade.
Feature work in parallel
How much new work your team ships while modernization runs.
Frequently Asked Questions
It depends on the size of the codebase, its test coverage and how many frameworks move. After a short assessment we agree the first released step, so value arrives before the whole plan is done.
Upgrade when the business rules are sound and the problem is the framework. Rewrite a module when its workflow no longer matches the business. We decide per module, not for the whole system at once.
No. Code modernization works on your current hosting. If a cloud move is also planned, our cloud migration and modernization service plans it, and we sequence the two so they do not collide.
Yes. Every integration is listed in the assessment, covered by contract tests and kept working through each step of the upgrade.
Yes. Small released steps and feature flags let your team keep shipping. If a module has to be frozen, it is for a short, agreed period.
IT modernization often means the wider estate, including hosting and networks. Our work is the application code and its data, and we coordinate with whoever runs your infrastructure.
AI tools can speed up reading old code and drafting tests, but every change passes the characterization tests, code review and your release process before it ships.