メニュー
Analyze .NET Framework to .NET 10 migration paths. Use when assessing legacy codebases for modernization, identifying breaking changes, and planning incremental migration strategies. Also
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | legacy-migration-analyzer |
| audience | team |
| description | Analyze .NET Framework to .NET 10 migration paths. Use when assessing legacy codebases for modernization, identifying breaking changes, and planning incremental migration strategies. Also |
"The best migrations are the ones you don't notice. Incremental, tested, and invisible to the end user." -- Immo Landwerth, .NET Platform Compatibility Lead
This skill analyzes legacy .NET Framework codebases and produces actionable migration plans to .NET 10. It does NOT perform the migration itself — it assesses, quantifies risk, and creates a phased plan that humans and other skills execute.
Non-negotiable constraints:
The full 10-row domain principle table, AI discipline rules, and the anti-pattern catalog live in
references/migration-decision-matrix.md.
| Query | When to Call |
|---|---|
search_knowledge(".NET Framework to .NET 8 10 migration breaking changes") | At SCAN phase — load authoritative breaking changes catalog |
search_knowledge(".NET Upgrade Assistant compatibility analyzer tool") | During ASSESS phase — confirms tooling commands and output |
search_knowledge("Entity Framework 6 EF Core migration differences lazy loading") | When assessing data access layer |
search_knowledge("ASP.NET MVC to ASP.NET Core migration web.config appsettings") | When analyzing web projects |
search_knowledge("NuGet package compatibility .NET Standard target framework") | During dependency audit |
search_knowledge("strangler fig pattern incremental migration legacy modernization") | During PLAN phase |
Search at the start of SCAN and ASSESS phases. Every risk finding must cite its authoritative source.
Analysis proceeds through four phases: SCAN (codebase inventory) → ASSESS (risk scoring) → PLAN (migration roadmap) → VALIDATE (feasibility confirmation). Do not skip phases or reorder them.
Approach selection: Hard blockers (WCF duplex, COM-heavy, undocumented protocols) that can be isolated → strangler fig; that cannot be isolated → hybrid (keep blocked components on .NET Framework behind API gateway). Single monolith under 50K LOC → in-place upgrade. All NuGet dependencies compatible → project-by-project in-place. Incompatible packages with replacements → replace packages first, then upgrade. No clean path → strangler fig for affected projects.
upgrade-assistant analyze <SolutionPath> --target-tfm net10.0System.Web namespace usages, COM interop, and P/Invoke declarationsweb.config/app.config sections with custom configurationAnalysis commands, upgrade tooling, complexity classification, and the SDK-style .csproj target
are in references/breaking-changes-catalog.md (.NET Framework Upgrade Specifics).
Order projects by dependency graph (leaf nodes first). Group into 2-4 week phases. Assign risk levels and rollback strategies. Define validation criteria per phase.
Standard phase order: Phase 0 (prerequisites: characterization tests, NuGet updates, extract interfaces) → Phase 1 (class libraries with no framework dependencies; multi-target if needed: net48;net10.0) → Phase 2 (data access layer; coordinate with ef-migration-manager) → Phase 3 (business logic layer) → Phase 4 (presentation/API layer; ASP.NET Core, gRPC) → Phase 5 (infrastructure; Worker Services, Kestrel, CI/CD).
When the Upgrade Assistant, a NuGet package, WCF, or System.Web blocks progress, follow the
recovery procedures in references/api-replacement-patterns.md (Error Recovery).
<migration-analysis-state>
step: [SCAN | ASSESS | PLAN | VALIDATE]
source_framework: [e.g., ".NET Framework 4.8"]
target_framework: [e.g., ".NET 10"]
breaking_changes_found: [count]
risk_level: [low | medium | high | critical]
last_action: [what was just done]
next_action: [what should happen next]
blockers: [any issues]
</migration-analysis-state>
A worked example of a populated state block is in references/migration-decision-matrix.md.
The Migration Inventory Report template (metrics, package compatibility, breaking changes by
category, hard blockers, risk score) is in references/migration-decision-matrix.md
(Output Report Template).
ef-migration-manager — When the analysis identifies EF6 usage, coordinate for the EF6→EF Core migration. The database schema migration is often the riskiest part and should be planned and tested independently.dotnet-vertical-slice — When the plan calls for decomposing a monolithic application, use this skill to structure new .NET 10 projects as vertical slices. Especially relevant in strangler fig migrations.nuget-package-scaffold — When shared libraries need to be extracted or multi-targeted (net48;net10.0) during the transition period.Interrogates a plan or codebase using Domain-Driven Design vocabulary. Enforces CONTEXT.md terminology, surfaces code/plan contradictions, and records domain decisions as ADRs sparingly. Use when designing a bounded context, reviewing a domain model, or asked to "apply DDD", "model the domain", or "review the domain model". Creates CONTEXT.md lazily from CONTEXT-FORMAT.md when the first term is resolved. Model-invocable so grill-with-docs, improve-codebase-architecture, codebase-design, and qraspi-architecture can pull it in mid-session. Ported from https://github.com/mattpocock/skills (Matt Pocock).
Shared vocabulary for designing deep modules — a lot of behaviour behind a small interface, placed at a clean seam, testable through that interface. Use when designing or improving a module's interface, finding deepening opportunities, deciding where a seam goes, making code more testable, or when another skill needs the deep-module vocabulary. Pairs with improve-codebase-architecture (which applies it) and domain-model (which supplies the domain nouns). Ported from https://github.com/mattpocock/skills (Matt Pocock).
Deep module refactoring using APOSD vocabulary: eliminates shallow modules, reduces information leakage, resolves temporal coupling, and aligns naming with the ubiquitous language. Use when asked to "improve the architecture", "refactor this module", "apply APOSD", or "clean up the design". Works best after domain-model is established. Ported from https://github.com/mattpocock/skills (Matt Pocock).
Runs a relentless interview to sharpen a plan or design. Use when the user wants to stress-test a plan, get grilled on their design, or says "grill me". Do NOT use when the session should also produce ADRs and a glossary; use grill-with-docs instead.
Runs a relentless interview to sharpen a plan or design, capturing the decisions as ADRs and a glossary along the way. Use when the user wants to be grilled AND wants the session to leave durable domain documentation behind. Do NOT use for a throwaway stress-test with no artifacts; use grill-me instead.
Interviews the user relentlessly about a plan, decision, or idea — one question at a time, each with a recommended answer. Shared engine behind "grill-me" and "grill-with-docs". Use on any "grill" trigger phrase or to stress-test thinking. Do NOT use to build the plan; it ends at shared understanding, not implementation.