India’s Leading Domain & Web Hosting Provider
Support
Domain & Login
Blog
Application Assessment for Cloud Migration: Owners, Windows, Risk
An application assessment profiles every business application before migration: who owns it, which servers and databases it runs on, how much downtime it can take, whether its vendor supports cloud hosting and how many interfaces it has. NTSPL turns that into a migration complexity score and a wave slot for each application, for CIOs who know their servers but not their portfolio.
Delivered on
In scope
Why Server Lists Do Not Tell You What to Move First
Infrastructure teams can list servers; few can say which of 80 applications run on them, who signs off a cutover or when the business tolerates eight hours of downtime. Migrations stall on exactly these questions: a vendor that voids support on cloud hosting, a quarter-end freeze nobody mentioned, an interface owned by a partner. Programmes that skip this step re-plan their waves two or three times.
NTSPL runs structured 45-minute owner interviews alongside discovery data. Each application gets a one-page card: servers, databases, interfaces, users, RPO/RTO, downtime window, compliance tags, ISV position and licence terms. A weighted complexity score of 1-5 then places it in an early, middle or late wave, with blockers named and owned, so wave planning starts from facts rather than goodwill.
When an Application-Level Assessment Pays Off
Signals you need Application Assessment
- 40 or more business applications with no single register linking each to servers, databases and an accountable owner
- Two or more ISV-supplied systems whose cloud support position has never been confirmed in writing
- Business units cannot agree which month-end, audit or seasonal freezes block cutovers
- A previous migration wave was rolled back because an undocumented interface broke
When to choose something else
- The question is which applications deserve re-architecture investment: that is portfolio screening in the Application Modernization Assessment.
- Fewer than 10 applications, all owned by one team: a half-day workshop produces the same answers.
What Each Application Card Records
Application-to-infrastructure map
Every application linked to its servers, databases, file shares and load balancers using discovery data confirmed by the owner.
Business profile
Owner, user count, revenue or regulatory impact, RPO/RTO, permitted downtime window and blackout calendar.
Vendor and licence position
ISV support statement for AWS, Azure or Google Cloud, licence portability and any hardware-bound dongles or MAC-locked keys.
Integration inventory
Inbound and outbound interfaces with protocol, partner, frequency and hard-coded IPs or hostnames.
Compliance tags
Personal data under DPDP Act 2023, RBI/SEBI/IRDAI-regulated data and CERT-In logging needs per application.
Interview-and-Telemetry Scoring Pipeline
Application Card and Complexity Scoring Pipeline
Discovery telemetry pre-fills each application card, owner interviews complete it, and a weighted scoring model converts it into complexity and wave placement. Blockers flow to a tracked register with named owners.
Select any component
Application Card and Complexity Scoring Pipeline: click any of its 7 components to see its role and the design choice NTSPL makes for it, or trace the 7-step primary path.
Application Profiling Tools by Cloud Provider
AWS Transform for .NET flags Windows-bound .NET Framework code during profiling, and AWS Marketplace listings help confirm whether an ISV ships a supported AWS build.
Azure Migrate's software inventory and web app and SQL assessments pre-fill most card fields, leaving owner interviews for business questions.
Migration Center groups hold one application's servers together for reporting, and the fit assessment shows which Linux workloads could containerise later.
Scoring Rules That Keep Waves Realistic
What the complexity score weighs
Weight downtime tolerance and integration count highest, around 25 percent each, then data volume, ISV status and compliance at about 15-20 percent each. An application with more than 10 interfaces or under two hours of permitted downtime never scores below 3, whatever its size. Agree weights before interviews so scores cannot be negotiated afterwards.
Handling unconfirmed ISV support
Treat silence as 'not supported'. Send a written query naming the target cloud, region and instance family; allow 15 working days. If no answer arrives, place the application in a late wave and plan a supported-vendor test environment first, rather than discovering a support refusal during a production incident.
Choosing pilot applications
Pick two or three applications scoring 1-2 that still touch real shared services such as AD, backup and monitoring. A pilot with no dependencies proves nothing about the landing zone; one with 15 interfaces risks the programme's credibility in week one. Internal tools with 50-300 users are usually ideal.
Interview depth versus speed
Cap interviews at 45 minutes with telemetry pre-filled, and interview owners of the top 20 percent of applications by criticality in person. Remaining owners can complete a guided form with a 15-minute follow-up call. This keeps a 100-application portfolio inside three weeks of interviewing.
Five-Week Portfolio Profiling Plan
Register seeding
Application list built from CMDB, finance licence records and discovery software inventory.
Owner interviews
Scripted interviews for critical apps, guided forms for the rest, cards pre-filled from telemetry.
ISV and licence verification
Written support queries to vendors and licence portability checks with procurement.
Scoring and wave candidacy
Complexity scores calculated, pilot apps named and blockers assigned with dates.
What you receive
Measures of a Usable Application Register
| KPI | Typical target |
|---|---|
| Applications with owner-signed cards | 100 percent of in-scope portfolio |
| Servers mapped to at least one application | 95 percent or higher |
| ISV positions confirmed in writing | 90 percent within 15 working days |
| Wave re-plans caused by unknown blockers | Zero in the first three waves |
Pitfalls in Application Profiling
| Risk | How NTSPL prevents it |
|---|---|
| Owners overstate criticality to avoid early waves | Criticality is cross-checked with incident history, user counts and revenue impact before scoring. |
| Interfaces known only to a vendor or partner | Firewall and connection logs are compared with interview answers and gaps raised with the partner. |
| Cards go stale before migration starts | Each card carries a review date and is re-confirmed 30 days before its wave. |
Application assessment or application modernization assessment: which comes first?
Application assessment comes first when the goal is to migrate. It answers operational questions for every application: owner, servers, interfaces, downtime window, vendor support and migration complexity, so waves can be scheduled. A modernization assessment answers an investment question: which applications are worth re-architecting, retiring or replacing, scored on business value against effort. Many portfolios need both, but in that order: profiling 80 applications takes about five weeks and feeds the modernization screen with data it would otherwise have to collect again. If no migration is planned and the question is purely where to invest, start with modernization screening.
Key facts: Application Assessment
Application Assessment in Practice
2 Application Assessment scenarios, from Insurance broking and Edtech (test preparation), plus related platform case studies.
Insurance broker profiles 64 applications and avoids an unsupported claims-system move
Test-prep edtech fits 38 application moves into a 9-week off-season window
EPC company vacates its owned data centre in 7 months and halves run cost
D2C fashion brand absorbs 14x festive flash-sale traffic with zero checkout outages
Application Assessment: Frequently Asked Questions
How many applications can be assessed in five weeks?
Up to about 120 with one lead consultant and one analyst, provided owners are available. Larger portfolios add a second interviewer rather than more weeks. Owner availability, not analysis, is usually the limiting factor. Portfolios spread across many business units benefit from a nominated coordinator per unit to book interviews.
What does an application assessment cost?
Typical effort is 0.3-0.5 consultant days per application, so an 80-application portfolio runs to roughly 25-40 days. Pricing is fixed per tranche of applications, and portfolios already covered by our infrastructure discovery cost less because cards arrive pre-filled. ISV verification effort is included in the per-application rate.
How much time do application owners need to give?
About an hour each: a 45-minute interview and a short sign-off review. Owners of lower-criticality applications fill a guided form with a 15-minute follow-up call. Their IT counterparts spend roughly the same time again confirming server and interface details, mostly in writing.
How are DPDP Act and sector rules reflected in the assessment?
Each card tags personal data, sensitive regulated data and logging needs. Applications holding RBI-, SEBI- or IRDAI-regulated data are flagged for Indian-region hosting and outsourcing-notification checks, and CERT-In log retention needs are recorded so the target design carries them. Those tags travel into the placement and security assessments.
What if a vendor refuses to support cloud hosting?
The application moves to a late wave and we list options: negotiate support on a specific instance family, move to the vendor's SaaS edition, rehost on a dedicated host, or retain on-premises. The decision sits with the owner, with costs attached.
Can the register be maintained after the assessment?
Yes. Cards are delivered in a spreadsheet or your ITSM tool's CMDB application class, with review dates, so the register becomes the portfolio record rather than a one-off report. After handover, ownership of the register usually sits with the IT portfolio or architecture lead.