Skip to content This library is free, offered as dana. If it helps your work, donate here →
penguin tree ai
← back to libraryDonate here

This is one of 3,622 free prompts in the penguin tree ai library. Sign up once and the whole library opens, with new prompts by email.

open the library →

Cloud readiness scorer

Scores a single application or business unit against a five-dimension cloud readiness rubric — technical debt, data sensitivity, integration complexity, team skills, and regulatory constraints — producing a weighted…

download .md

Purpose

Score an individual application or business unit against a consistent five-dimension cloud readiness rubric and return a weighted readiness score with dimension-level rationale, a recommended migration disposition (the 6 Rs), and a ranked list of blockers — so migration sequencing decisions are defensible, repeatable across a portfolio, and not driven by gut feel or the loudest stakeholder.

When to Use

Invoke this skill when the user asks to:

  • Assess whether a specific application is ready to migrate to the cloud
  • Score or rank multiple applications to sequence a migration backlog
  • Build a consistent readiness baseline across a portfolio or business unit
  • Decide between rehost, replatform, refactor, retain, or retire for a workload
  • Justify a migration go/no-go decision to a steering committee or executive sponsor
  • Identify the specific blockers that must be resolved before a workload can move

Inputs Required

Before starting, collect:

  • Workload identity: Application or business-unit name and what it does in one sentence
  • Target cloud: AWS / Azure / GCP / multi-cloud / undecided
  • Technical profile: Tech stack, age, architecture (monolith/microservices), known technical debt, current hosting
  • Data profile: Data types handled, sensitivity classification (public/internal/confidential/regulated), data volume and residency requirements
  • Integration map: Upstream/downstream dependencies, integration patterns (API/file/DB-level/message queue), number of connected systems
  • Team capability: Cloud experience of the owning team, existing platform/DevOps maturity, available migration support
  • Regulatory context: Applicable frameworks (HIPAA, PCI-DSS, GDPR, SOX, FedRAMP, etc.) and any contractual or sovereignty constraints

If sensitivity classification or regulatory context is missing, score conservatively (assume higher sensitivity) and flag the assumption explicitly.

Instructions

Step 1: Score Each of the Five Dimensions (0–100)

Score each dimension independently using the anchored rubric below. For every dimension, assign a score band, then a precise number within that band, and write 2–3 sentences of rationale citing the specific input evidence.

Dimension 1 — Technical Debt & Architecture (weight 25%) Measures how cloud-friendly the current architecture is.

  • 80–100: Modern stack, containerized or stateless, externalized config, CI/CD in place
  • 60–79: Reasonably modern, some refactoring needed, manageable coupling
  • 40–59: Monolithic but documented, moderate tech debt, mutable state
  • 20–39: Legacy stack, tight coupling, hardcoded infra dependencies, sparse documentation
  • 0–19: Unsupported runtime/OS, no source ownership, undocumented black box

Dimension 2 — Data Sensitivity & Residency (weight 20%) Measures how much friction data classification adds to a cloud move. Higher sensitivity lowers the score.

  • 80–100: Public/internal data only, no residency constraints
  • 60–79: Confidential data, standard encryption sufficient, no residency lock
  • 40–59: Regulated data with clear controls available in target cloud
  • 20–39: Regulated data with residency or sovereignty requirements
  • 0–19: Sovereignty-locked or contractually prohibited from leaving current environment

Dimension 3 — Integration Complexity (weight 20%) Measures dependency drag. More tightly coupled, undocumented integrations lower the score.

  • 80–100: Loosely coupled, ≤3 API-based integrations, well documented
  • 60–79: 4–8 integrations, mostly API/message-based, mappable
  • 40–59: 9–15 integrations or some DB-level coupling
  • 20–39: 15+ integrations, DB-level or file-based coupling, shared databases
  • 0–19: Deeply entangled shared-state dependencies with no clear contract

Dimension 4 — Team Skills & Operating Maturity (weight 20%) Measures whether the owning team can run the workload in the cloud.

  • 80–100: Team has shipped cloud workloads, mature DevOps/IaC, on-call discipline
  • 60–79: Some cloud experience, partial automation, learning curve manageable
  • 40–59: Limited cloud exposure, manual ops, will need enablement
  • 20–39: No cloud experience, no automation, dependent on external help
  • 0–19: No owning team or no operational capacity at all

Dimension 5 — Regulatory & Compliance Constraints (weight 15%) Measures compliance friction beyond data residency. More frameworks and stricter controls lower the score.

  • 80–100: No applicable regulatory frameworks
  • 60–79: One framework, controls natively supported in target cloud
  • 40–59: Multiple frameworks, achievable with documented compensating controls
  • 20–39: Strict frameworks (FedRAMP High, PCI Level 1) requiring significant attestation work
  • 0–19: Conflicting or unmet regulatory requirements with no current path to compliance

Step 2: Calculate the Weighted Readiness Score

Compute the overall score: Score = (D1×0.25) + (D2×0.20) + (D3×0.20) + (D4×0.20) + (D5×0.15)

Map the result to a readiness tier:

  • 80–100 — Ready: Migrate in the near-term wave
  • 60–79 — Conditionally Ready: Migrate after addressing specific blockers
  • 40–59 — Not Yet: Requires remediation investment before scheduling
  • 0–39 — High Risk / Defer: Do not migrate without restructuring, or retain/retire

Step 3: Recommend a Migration Disposition (6 Rs)

Based on the dimension pattern, recommend one primary disposition with one-line rationale:

  • Rehost (lift-and-shift): High team/data scores but minimal modernization appetite
  • Replatform: Solid architecture score, modest debt, worth small optimizations
  • Refactor: Low technical debt score but high business value — invest to modernize
  • Repurchase (SaaS swap): Commodity capability, low integration lock-in
  • Retain: Low overall score with low business urgency — leave on-prem for now
  • Retire: Low score and low/declining business value — decommission instead

Step 4: Rank the Blockers

List the top 3–5 blockers in priority order. For each: the blocker, which dimension it sits in, the remediation action, and a rough effort estimate (Low / Medium / High). Rank by what would most raise the score per unit of effort.

Step 5: State the Verdict

Give a one-paragraph go/no-go verdict with the score, tier, disposition, and the single most important thing to resolve first. Be decisive — do not hedge.

Output Format

  • Structure: Dimension scorecard (table) → weighted score and tier → disposition recommendation → ranked blockers (table) → verdict paragraph
  • Length: 700–1,000 words
  • Format: Two tables (dimension scores, blockers) plus structured prose for disposition and verdict
  • Sections: Dimension Scorecard → Weighted Readiness Score → Migration Disposition → Top Blockers → Verdict
  • Tone: Enterprise architect to steering committee — analytical, evidence-anchored, decisive; quantified rather than qualitative

Quality Checklist

Before delivering output, verify:

  • [ ] All five dimensions are scored 0–100 with a precise number, not just a band
  • [ ] Every dimension score has rationale citing the specific input provided
  • [ ] The weighted score is arithmetically correct against the stated weights
  • [ ] The score maps to the correct readiness tier
  • [ ] A single primary disposition (one of the 6 Rs) is recommended with rationale
  • [ ] Blockers are ranked by score-impact-per-effort, each with a remediation action and effort estimate
  • [ ] Any missing input (especially data/regulatory) is flagged with the conservative assumption used

Notes

  • Scores are only comparable across a portfolio when the same rubric and weights are applied to every workload — keep the weights fixed unless the program explicitly recalibrates them.
  • The data sensitivity and regulatory dimensions are inverted: more sensitive/regulated workloads score lower because they add migration friction, not because they are less valuable.
  • A high-value workload with a low score is a refactor candidate, not a retire candidate — separate the readiness score from the business-value judgment when advising sequencing.
  • When scoring a business unit rather than a single app, score the constraining (lowest-readiness) critical application unless the unit is being assessed for an all-or-nothing move.

How to use this skill

This file is a Claude Code skill in Anthropic's standard format — markdown with YAML frontmatter at the top.

Installing in Claude Code:

  • ~/.claude/skills/<folder-name>/SKILL.md — auto-loads in every session anywhere on your machine (recommended for skills you'll use across multiple projects)
  • <your-project>/.claude/skills/<folder-name>/SKILL.md — auto-loads only when working in that project (recommended for project-specific skills)

Restart Claude Code or open a new session to register.

Using in Claude.ai, ChatGPT, Gemini, or other AI tools:

  1. Drag this file into a new chat, or copy and paste its contents
  2. Send your task or request as your next message — the AI will apply the skill where it fits

For Claude Code skill details: https://docs.anthropic.com/en/docs/claude-code/skills