India’s Leading Domain & Web Hosting Provider
Support
Domain & Login
Blog
Code-Level Modernization Assessment for 1-5 Critical Applications
A modernization assessment is a code-level technical study of one to five chosen applications that decides how each should be re-architected, in what order and at what cost. NTSPL analyses source code, runtime traces, database coupling and change history, then delivers target patterns, a sequenced backlog and an INR estimate for CTOs who have already shortlisted what to modernize.
Delivered on
In scope
Why portfolio scores are not enough to start re-architecture
Portfolio screening tells you the policy administration system should be refactored. It does not tell you that 41% of its business rules sit in 900 stored procedures, that three batch jobs write to the same tables as the online path, or that session state lives in IIS memory. Teams that start re-architecture without this evidence discover it in sprint six, with half the budget spent. The symptoms are familiar: vendor estimates that differ by 3x, a strangler plan with no first seam, and nobody able to say which module can be extracted without splitting data.
NTSPL runs a 4-6 week assessment per application group. Static analysis (CAST Highlight, SonarQube, NDepend or jdeps) maps dependencies; OpenTelemetry tracing on production-like traffic captures real call paths; SQL traces build a table-to-module CRUD matrix. We mine 24 months of Git and incident history for change hotspots and interview the engineers who actually change the code. Every candidate seam is scored on data independence, change frequency, business value and test coverage. The output is a decision: target pattern per module, the first three extractions, and a backlog estimated in story points and rupees.
Signals that an application needs a code-level assessment
Signals you need Modernization Assessment
- Two vendor estimates for re-architecting the same application differ by more than 2.5x and nobody can explain the gap.
- A one-line change to a core application takes 3+ weeks to release because regression testing must cover the whole monolith.
- More than 30% of business rules live in stored procedures, triggers or batch scripts rather than application code.
- The application is pinned to Windows Server 2012/2012 R2, whose Extended Security Updates ended on 13 October 2026, or to Java 8 and .NET Framework stacks that block containers.
- The board has approved a budget to modernize 1-5 named systems, but nobody has defined the first-year scope.
- A previous microservices attempt stalled as a distributed monolith: services that must still deploy together.
When to choose something else
- You have 50+ applications and have not yet chosen which to modernize: start with portfolio-level screening (Cloud Assessment's Application Modernization Assessment) and return with a shortlist.
- The system is a packaged product such as SAP, Finacle or Oracle E-Business Suite where the vendor owns the code: assess upgrade and extension options against the vendor roadmap instead.
- The only goal is to exit a data centre within six months: rehost or replatform first, and schedule a deep assessment after the move.
What we examine inside each application
Code structure and dependencies
Dependency graphs, complexity and dead-code ratio per module to find natural seams.
Data coupling
Table-to-module CRUD matrix, shared-table writes, procedures, triggers and cross-schema joins that block a data split.
Runtime behaviour
Traced call chains, session state, local file writes and batch windows that documents never mention.
Change and incident history
24 months of commits and Sev-1 tickets mined for hotspots and modules that change together.
Platform blockers
Runtime versions, OS end-of-support dates, licence terms, hard-coded IPs and local storage.
Team and delivery constraints
Test coverage, build time, release cadence and skills of the team that will own the target.
Seam-scoring pipeline from source code to sequenced backlog
Seam-Scoring Assessment Pipeline
Source, database and runtime evidence feeds a coupling model that scores every candidate seam in the application. Scores drive a target-pattern decision per module and a sequenced, costed backlog the delivery team can start sprinting on.
Select any component
Seam-Scoring Assessment Pipeline: click any of its 10 components to see its role and the design choice NTSPL makes for it, or trace the 7-step primary path.
Assessment tooling on AWS, Azure and Google Cloud
On AWS we use AWS Transform for .NET to size .NET Framework porting effort, and DMS Schema Conversion assessment reports to quantify how much Oracle or SQL Server code converts automatically versus by hand.
AppCAT scans Java and .NET code for cloud blockers, and Application Insights captures runtime dependencies on a staging slot. Findings feed Azure Boards directly as epics.
Migration Center data gives the infrastructure baseline, conversion workspaces size database code changes, and Cloud Trace records runtime call paths for applications already on Compute Engine.
Calls the assessment has to make for each module
Which seam to cut first
Score each candidate 1-5 on data independence (does it own its tables?), change frequency, business visibility and test coverage. Choose the first extraction where data independence is 4 or more and change frequency is in the top quartile; a rarely changed module gives no payoff. Do not start with the module behind most Sev-1 incidents: it is usually the most coupled.
Refactor in place or rebuild
Rebuild when more than 60% of modules score high on coupling and the business domain has changed materially since the code was written. Refactor incrementally behind a strangler facade when the domain model still holds and tests cover 40% or more of critical paths. Below 20% coverage, budget characterisation tests first, which typically take 15-20% of total programme effort before any extraction begins.
Stored-procedure logic
If stored procedures hold under 15% of business rules, move them into services during each extraction. Above 40%, plan a dedicated database refactoring stream (see Managed Database Modernization) before splitting services. Otherwise every new service still calls the same procedures, deployments stay coupled through the schema, and the database quietly remains the monolith you set out to remove.
Target runtime per module
Default stateless request-response modules to containers on a managed runtime; event-driven jobs busy for under 5% of the day to serverless; long-running stateful batch to containers or VMs until the data split lands. Record the reason for each choice in the scorecard so the decision survives a change of architect or vendor.
Six-week assessment plan per application group
Access and outcome baseline
Get repository, schema and APM access, build the application locally, and agree the 3-5 business outcomes the assessment will be judged against.
Static and schema analysis
Run code scanners, dependency graphs and stored-procedure inventory, and produce the first table-to-module CRUD matrix.
Runtime tracing
Instrument a performance environment with OpenTelemetry, replay the top 20 transactions by volume, and capture batch interactions.
History mining and engineer interviews
Mine Git and incident history for hotspots and validate every finding with the engineers who own each module.
Seam scoring and validation spike
Score seams, choose target patterns, and prove the first extraction with a three-day spike against real data.
Backlog and estimate sign-off
Write the sequenced epic backlog, effort ranges and INR budget, and present them to the architecture board.
What you receive
How we judge the quality of an assessment
| KPI | Typical target |
|---|---|
| Accuracy of first two extraction estimates against actuals | Within ±20% |
| In-scope modules with a recorded pattern decision and rationale | 100% |
| Hidden dependencies discovered after delivery sprint 1 | Fewer than 3 per application |
| Business rules located by layer (code, database, batch) | 90% or more mapped |
| Assessment duration per application group | 4-6 weeks |
Where modernization assessments go wrong
| Risk | How NTSPL prevents it |
|---|---|
| Assessing from documentation instead of code | Repository and schema access is a week-1 precondition; architecture diagrams are treated as hypotheses until traces confirm them. |
| Test traffic that does not resemble production | We replay sanitised production logs or synthetic load matched to the top 20 transactions by volume before trusting runtime traces. |
| Estimates anchored to one vendor's favourite pattern | Each pattern is chosen against written thresholds, and the spike tests the riskiest assumption before the estimate is signed. |
| Key-person knowledge missed | Interviews include the longest-serving developer and the operations lead who handles batch failures, not only the current architect. |
Modernization assessment or portfolio rationalisation: which do we need first?
If you have not decided which applications to modernize, do portfolio screening first. It sorts 50-500 applications into 6R buckets in a few weeks using questionnaires, inventory and cost data, and its output is a shortlist. A modernization assessment starts where that ends: it takes one to five named applications and reads their code, schemas, traces and change history to decide target patterns, extraction order and cost. Running deep assessments across a whole portfolio wastes money. Skipping one for a high-value system means the programme discovers its real complexity during delivery, when every change costs five to ten times more.
Key facts: Modernization Assessment
Modernization Assessment in Practice
2 Modernization Assessment scenarios, from General insurance and Education software (school ERP vendor), plus related platform case studies.
General insurer finds 58% of policy rules in PL/SQL before re-architecting its PAS
School ERP vendor picks its first three extractions from a PHP monolith for 1,900 schools
EPC company vacates its owned data centre in 7 months and halves run cost
NBFC moves loan-origination Oracle database to Aurora PostgreSQL and drops EE licences
Modernization Assessment: Frequently Asked Questions
How much does a modernization assessment cost?
For one application of 300,000-800,000 lines of code, an assessment typically runs 4-6 weeks with two architects and a data engineer, usually in the INR 12-25 lakh range. Each additional application sharing the same database or team adds 30-50% rather than a full repeat. We offer a fixed price once we have seen the repository size.
Does a deep modernization assessment of our chosen applications need full source-code access?
Yes. A code-level assessment cannot be done from interviews and diagrams. We work read-only inside your environment, through your VDI, your Git server or a workspace in your cloud tenancy, so code never leaves your control. NDA and IP clauses are signed before any access is granted.
How is customer data protected during runtime tracing under the DPDP Act 2023?
We trace in a performance or staging environment with masked data wherever possible. When production traces are needed, OpenTelemetry collectors drop request bodies and redact identifiers such as PAN, Aadhaar and mobile numbers at source, and traces are stored in your own account in an Indian region such as AWS Mumbai or Azure Central India.
Which languages and stacks can you assess?
Java (Struts, Spring, EJB), .NET Framework and modern .NET, PHP, Node.js and Python, plus Oracle Forms, PowerBuilder and VB6 front ends. Mainframe COBOL is scoped separately because the tooling and skills differ, though we assess the distributed tiers around it in the same engagement.
What happens after the modernization assessment backlog is signed off?
You receive a backlog your own team or any vendor can execute. Many clients start NTSPL on the first extraction because the spike is already built, but deliverables are vendor-neutral, with estimates and assumptions transparent enough to support competitive bidding.
Can AI coding assistants replace a modernization assessment?
No, but they shorten it. AWS Transform, GitHub Copilot app modernization and Gemini Code Assist speed up code reading and upgrade sizing. They cannot see runtime call paths, batch jobs writing to shared tables, or which modules cause incidents, and those facts decide the extraction order.