India’s Leading Domain & Web Hosting Provider
Cloud Readiness Assessment: Go/No-Go Gates Before Wave One
A cloud readiness assessment tests whether an organisation's foundations, identity, connectivity, landing zone, security tooling, operations, skills and regulatory approvals, are in place to run production workloads in cloud before migration starts. NTSPL scores each foundation against explicit go/no-go gates and returns a dated remediation backlog, so CIOs commit a first-wave date they can actually keep.
Delivered on
In scope
Why Migrations Stall After the First Workload Lands
Migrations rarely fail on the first server move. They fail when the first production workload lands and there is no MFA on the cloud console, no tested route back to the data centre, no backup policy in the target account and no board-approved outsourcing policy the auditor can see. Each gap surfaces as a two-week delay, and four of them turn a confident Q2 start into Q4.
NTSPL assesses seven foundations against 42 binary gates drawn from the AWS, Microsoft and Google cloud adoption frameworks plus Indian regulatory requirements. Every gate is pass, partial or fail with evidence, not opinion. Failures become backlog items sized in days with an owner, and the sum of the critical path sets the earliest credible wave-one date, which we put in front of the steering committee in week four.
When to Run a Readiness Gate Review
Signals you need Cloud Readiness Assessment
- A migration start date has been announced but no landing zone, identity integration or cloud network exists yet
- Fewer than five staff hold any current AWS, Azure or Google Cloud certification
- A regulated entity under RBI, SEBI or IRDAI has not yet taken cloud outsourcing through its board or risk committee
- A pilot workload went live in cloud but nobody has tested restore, patching or on-call for it
When to choose something else
- Foundations already passed a Well-Architected or CAF review in the last six months: move to workload placement or wave planning.
- The real question is organisation design, roles and a CCoE charter: that is the Cloud Operating Model Assessment.
The Seven Foundations We Test
Identity and access
Directory sync, SSO, MFA coverage, privileged access, break-glass accounts and joiner-mover-leaver flows for cloud roles.
Connectivity
Path from data centre and branches to the target region, DNS resolution design, IP plan overlaps and firewall ownership.
Landing zone and security tooling
Account or subscription hierarchy, guardrail policies, logging destination, key management and vulnerability scanning in the target.
Operations
Backup, patching, monitoring, ITSM integration and on-call cover for cloud-hosted workloads from day one.
Skills, finance and regulation
Certified headcount, budget owner and tagging rules, plus board approvals, outsourcing registers and data-localisation positions.
Gate-Based Readiness Scoring Model
42-Gate Cloud Readiness Scoring Model
Evidence from workshops, tenancy reviews and document checks is scored gate by gate across seven foundations. Failed gates become sized backlog items, and the critical path through them sets the earliest defensible wave-one date.
Select any component
42-Gate Cloud Readiness Scoring Model: 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.
Adoption-Framework Tooling on AWS, Azure and Google Cloud
We align gates to the six AWS CAF perspectives and test landing-zone readiness against a Control Tower baseline in Mumbai, with Hyderabad as the second region.
Gates follow the CAF Ready methodology; identity gates are tested directly in Entra ID, and landing-zone gates against the Azure landing zone reference design.
Readiness is scored on the Adoption Framework's learn, lead, scale and secure themes, and foundations are checked against the enterprise foundations blueprint's resource hierarchy.
Calls That Decide the First Wave Date
Which gates are critical
Fourteen gates block wave one regardless of scores elsewhere: MFA on all privileged cloud access, break-glass accounts tested, central log destination, backup policy in the target, an approved network path, a named budget owner, and for regulated entities, board approval of cloud outsourcing. Everything else can run in parallel with early waves if a dated owner exists.
Build or adopt a landing zone
If fewer than 200 workloads and no unusual segregation needs, adopt the provider's reference landing zone and customise policies; it is ready in two to three weeks. Build bespoke only when multiple legal entities, regulator-separated environments or strict network inspection require it, and budget six to ten weeks for it.
Skills threshold before go-live
Have at least two certified administrators per target cloud and one person who has operated production there before wave one. Below that, contract a managed partner for the first 90 days rather than delay; skills grow faster running real workloads than in classroom training alone.
Scoring partial evidence
A policy that exists but is not enforced scores partial, never pass. Partial on a critical gate counts as fail for the date model. This feels strict, but it stops the common pattern of a green scorecard followed by an audit observation in the first quarter after go-live.
Four-Week Readiness Review
Evidence requests and tenancy scan
Document checklist issued and any existing cloud tenancies reviewed read-only.
Foundation workshops
Seven workshops with identity, network, security, operations, finance, HR and compliance owners.
Gate scoring and regulatory overlay
All 42 gates scored with evidence; sector gates checked with compliance.
Backlog and date model
Failed gates sized, sequenced and turned into a wave-one date for the steering committee.
What you receive
Readiness Scores We Report
| KPI | Typical target |
|---|---|
| Critical gates passed before wave one | 14 of 14 |
| Overall gates passed at re-score after 30 days | 80 percent or higher |
| Wave-one date slippage versus model | Under two weeks |
| Audit observations on cloud foundations in first two quarters | Zero high-severity |
How Readiness Reviews Mislead
| Risk | How NTSPL prevents it |
|---|---|
| Scores inflated by optimistic self-assessment | Every pass needs a screenshot, policy export or approval minute; verbal answers score partial. |
| Regulatory approvals treated as an IT task | Sector gates are walked through with the compliance head and company secretary, with board calendar dates in the plan. |
| Backlog drifts after the readout | A 30-day re-score is part of the engagement, reported to the same steering committee. |
Cloud readiness assessment or Well-Architected review: what is the difference?
A Well-Architected review examines a workload, or a designed architecture, against pillars such as reliability, security and cost. A readiness assessment examines the organisation's foundations before any workload moves: identity, connectivity, landing zone, operations, skills, budget ownership and regulatory approvals. Readiness comes first because a perfectly designed workload still cannot go live without MFA, a network path and an approved outsourcing policy. Once foundations pass, run Well-Architected reviews on each major workload during design. If you already have production workloads in cloud and want to know whether they are built well, a Well-Architected review is the right tool.
Key facts: Cloud Readiness Assessment
Cloud Readiness Assessment in Practice
2 Cloud Readiness Assessment scenarios, from Cooperative banking and Media and publishing, plus related platform case studies.
Multi-state cooperative bank moves its AWS start date only once, with every gate dated
Regional media house closes 17 readiness gaps before moving editorial systems to GCP
Health-tech SaaS moves patient data behind KMS and Identity Center ahead of DPDP
IT services firm brings 43 Azure subscriptions under one policy hierarchy
Cloud Readiness Assessment: Frequently Asked Questions
How long does a cloud readiness assessment take?
Four weeks for most mid-sized organisations: one week of evidence collection, two weeks of workshops and scoring, and a week to build the backlog and date model. A 30-day re-score follows to check remediation progress. Organisations with several legal entities may need a fifth week.
What does a readiness assessment cost?
Typically 15-22 consultant days, depending on how many clouds and legal entities are in scope. Single-cloud, single-entity reviews sit at the lower end. The re-score is included, and the backlog can be executed by NTSPL or your own team. Most evidence is reviewed remotely, so multi-site travel is rarely needed.
What do RBI-regulated entities need in place before migrating?
Board-approved IT outsourcing policy covering cloud, a risk assessment of the provider, contractual audit and inspection rights, data stored and processed in line with RBI directions, and exit planning, as set out in RBI's 2023 Master Direction on Outsourcing of IT Services. We test each of these as a gate.
Do we need a landing zone before the assessment?
No. The assessment decides whether to adopt a reference landing zone or build a bespoke one and sizes the effort. If shadow accounts or subscriptions already exist, we review them read-only and fold findings into the scorecard. Findings from shadow tenancies often become the first critical gates.
Can we start migrating while some gates are still red?
Yes, if only non-critical gates are red and each has a dated owner. The 14 critical gates, covering privileged MFA, logging, backup, network path, budget ownership and regulatory approval, must be green first. Each non-critical red gate stays in the backlog with a date until it closes.
Does the assessment favour a particular cloud?
No. Gates are provider-neutral and mapped to AWS, Microsoft and Google adoption frameworks. Where a choice of cloud is still open, readiness scores often differ by provider because of existing identity or skills, and we report that difference. Readiness is then scored separately for each candidate provider.