What this prompt does
This prompt casts the model as a senior .NET architect who has done migrations under load and asks for a specific, phased roadmap from .NET Framework 4.8 to .NET 9. You provide [app_type], [codebase_size], and [deadline], and it returns an Upgrade Assistant assessment, the top 10 likely blocker libraries with replacements, a side-by-side deployment plan, CI/CD changes, configuration migration guidance, and a phased plan with milestones and exit criteria.
The structure works because it surfaces blockers first, where they belong. In framework migrations the syntax is rarely the problem — it's one library with no modern equivalent that stalls a whole phase. By asking for the top 10 suspect libraries (System.Web, WCF, AppDomains) with replacements early, the prompt forces those risks into the open in week one. [deadline] shapes how aggressively the phases are sequenced, [codebase_size] informs the effort estimates, and [app_type] (for example, an ASP.NET MVC monolith) tells the model which framework-specific traps to expect. Pairing the Upgrade Assistant assessment with a side-by-side deployment plan is deliberate: it lets you move incrementally and keep shipping, instead of betting the whole modernisation on one high-risk cutover weekend.
When to use it
- You're planning a .NET Framework 4.8 to .NET 9 move and need a credible roadmap.
- You want blocker libraries surfaced in week one, before they detonate mid-migration.
- You need a side-by-side deployment strategy so old and new run together during cutover.
- You're converting web.config to appsettings.json and want the gotchas listed.
- You have a hard deadline and need phases with real exit criteria.
- You're moving to SDK-style projects and need the CI/CD changes mapped.
Example output
Expect a phased roadmap table with columns for phase, scope, exit criteria, and risk, preceded by the Upgrade Assistant assessment splitting auto-fixes from manual flags, a list of the top 10 suspect blocker libraries with suggested replacements, the side-by-side deployment approach, and the configuration migration notes. Each phase has clear exit criteria so you know when it's actually done.
Pro tips
- Make
[app_type]specific — WCF services, Web Forms, and MVC monoliths each have different blocker profiles. - Use
[codebase_size]honestly so the effort and phasing estimates are grounded in reality. - Set
[deadline]truthfully; "no feature freeze" changes the plan substantially versus a quiet window. - Spike the riskiest dependency the model flags before you commit to the timeline; one unportable library can move every milestone.
- Treat the Upgrade Assistant split as a starting estimate, then run the tool on a branch to confirm.
- Ask it to expand any single phase into a detailed task list once you've validated the overall shape.
- Define exit criteria you can actually test for each phase, so "done" is a passing build and green tests, not a feeling.
- Pay close attention to the web.config to appsettings.json gotchas; configuration mismatches cause runtime failures that compile cleanly and only surface in production.
