Purpose
Turn an application's real profile — its stack, business criticality, change frequency, integration complexity, and team skills — into a defensible modernization recommendation using the 7R framework, complete with weighted scoring, trade-offs, and a runner-up. Ends the "should we just lift-and-shift or refactor?" debate with a decision an architect can put in front of a steering committee.
When to Use
Invoke this skill when the user asks to:
- Decide how to modernize or migrate a specific application
- Choose between rehost, replatform, refactor, or replace for a workload
- Justify a lift-and-shift vs. re-architect decision to stakeholders
- Classify applications in a portfolio into migration waves or dispositions
- Evaluate whether a legacy app should be retired, retained, or replaced with SaaS
- Produce a migration disposition with rationale for a cloud business case
Inputs Required
Before starting, collect:
- Application overview: What the app does and who uses it (2–3 sentences)
- Technology stack: Language/runtime, framework, database, hosting (on-prem, VM, mainframe, etc.)
- Business criticality: Mission-critical / important / low — and any revenue or compliance dependency
- Change frequency: How often the app is modified (weekly, monthly, rarely, frozen)
- Integration complexity: Number and type of upstream/downstream dependencies
- Team skills: Skills of the team that owns it (cloud-native, legacy-only, mixed) and whether the vendor/source is still supported
- Constraints & drivers: Budget ceiling, deadline, data center exit date, licensing costs, or a target platform if one is mandated
If business criticality or change frequency is missing, ask one clarifying question — these two inputs disproportionately drive the recommendation.
Instructions
Step 1: Build the Application Fitness Profile
Summarize the app across five scoring dimensions, each rated 1–5:
- Technical health: modern stack (5) → unsupported/mainframe (1)
- Business value & criticality: mission-critical, growing (5) → low value, declining (1)
- Change velocity: frequent feature change (5) → frozen/no changes (1)
- Integration coupling: standalone (5) → deeply entangled with many systems (1)
- Team readiness: cloud-native skills available (5) → legacy-only, no cloud skills (1)
Note any hard constraints (data center exit date, EOL software, compliance lock-in) — these can override scoring.
Step 2: Evaluate Against All 7 R's
For each pattern, assess fit against the profile. Do not skip any — an architect needs to see why the others were rejected.
Retire — Decommission the app entirely.
- Best when: low business value, redundant functionality, near-zero usage, functionality covered elsewhere.
- Trade-off: requires confirming no hidden dependencies before shutdown.
Retain (Revisit) — Keep as-is, defer the decision.
- Best when: recent investment, no compelling driver, regulatory freeze, or pending business decision.
- Trade-off: technical debt and hosting cost persist; only valid as a deliberate hold.
Rehost (Lift-and-shift) — Move to cloud IaaS with minimal change.
- Best when: aggressive deadline / data center exit, low change frequency, limited cloud skills, mission-critical but stable.
- Trade-off: fastest and lowest-risk migration, but captures little cloud-native benefit; costs may not drop.
Replatform (Lift-tinker-and-shift) — Minor optimizations (managed DB, containers) without changing core code.
- Best when: some cloud benefit desired, moderate change frequency, a clear quick win like moving to a managed database.
- Trade-off: middle path — more value than rehost, more effort; risk of scope creep into refactor.
Refactor — Restructure code for cloud-native fit without changing external behavior.
- Best when: high change velocity, active team with cloud skills, mounting technical debt slowing delivery.
- Trade-off: unlocks agility and scaling but is time- and skill-intensive; needs strong test coverage.
Rearchitect — Fundamentally redesign (e.g., monolith → microservices, event-driven).
- Best when: high business value, high change velocity, current architecture is a hard scaling/cost ceiling, and skills + budget exist.
- Trade-off: highest cost and risk; only justified when the app is strategic and the architecture is genuinely blocking outcomes.
Replace (Repurchase) — Retire custom app in favor of SaaS/COTS.
- Best when: commodity functionality (CRM, HR, ticketing), low differentiation, high maintenance burden.
- Trade-off: reduces maintenance and often TCO, but introduces data migration, integration rework, and process change.
Step 3: Apply Weighted Scoring
Score the top 3 candidate patterns against the drivers, weighting by the stated constraints:
- If a deadline or data center exit dominates → weight speed and risk highest (favors Rehost/Replatform).
- If agility / feature velocity dominates → weight future change enablement highest (favors Refactor/Rearchitect).
- If cost reduction dominates → weight TCO and maintenance burden (favors Replace/Retire/Replatform).
- If the app is commodity → strongly weight Replace.
Present a short scoring table: pattern × (speed, cost, risk, future agility, skills fit), then a total.
Step 4: Select and Justify
Name the recommended pattern and a runner-up. Explain the recommendation in terms of this specific app's profile and constraints — not generic pattern descriptions. Include what would change the recommendation (e.g., "if the DC exit date moves out 12 months, Refactor becomes viable").
Step 5: Flag Migration Risks and Next Actions
List 3–5 concrete risks for the recommended pattern (dependency discovery, data migration, skills gap, licensing, testing coverage) and 3–5 next actions to validate the decision before committing.
Output Format
- Structure: Fitness profile → 7R evaluation → weighted scoring table → recommendation + runner-up → risks & next actions
- Length: 800–1,100 words
- Format: Structured document — bulleted profile, one scoring table, concise prose rationale
- Sections: Application Fitness Profile, 7R Evaluation, Weighted Scoring, Recommendation, Migration Risks & Next Actions
- Tone: Enterprise architect writing for a steering committee — decisive, trade-off-aware, no hedging
Quality Checklist
Before delivering output, verify:
- [ ] All five fitness dimensions are scored 1–5 with a stated reason
- [ ] Every one of the 7 R's is evaluated (count them) — including why rejected patterns don't fit
- [ ] A scoring table is present with the top 3 candidates across at least 5 criteria
- [ ] A single recommended pattern and a distinct runner-up are named — no tie
- [ ] The rationale references this app's actual profile and constraints, not generic definitions
- [ ] At least 3 migration risks and 3 next actions are listed for the recommendation
Notes
- Business criticality and change frequency drive most decisions: stable + critical → Rehost/Replatform; volatile + strategic → Refactor/Rearchitect.
- Rearchitect is over-selected in practice — reserve it for apps where the architecture is provably blocking business outcomes, not for tidiness.
- Hard constraints (EOL software, DC exit dates, compliance) can override scoring entirely; call this out explicitly when it happens.
- For portfolio-scale work, run this per application and group results into migration waves by pattern and risk.
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:
- Drag this file into a new chat, or copy and paste its contents
- 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