Prompt file imported from autocloudarc-digital-services/ghcp-dotnet-calculator (.github/prompts/3.02-migrate-to-azure.prompt.md). Copyright stays with the author.

Migrate to Azure (Assessment Kickoff)

Use the GitHub Copilot App Modernization extension to run an Azure migration readiness assessment and produce a prioritized, execution-ready baseline. Use the previous assessment findings in azure-migration-assessment-3.02.md as the known baseline when refreshing the report.

This prompt is assessment-only. Do not deploy resources in this step.

Known Baseline

The active calculator workspace is post-Blazor and targets .NET 10. Treat earlier .NET 8 references as historical when they appear in pre-upgrade prompts, reports, or staged learning artifacts.

Current migration baseline:

• calculator.web is the primary web-hostable Blazor app target.
• calculator.library contains shared calculator logic and should deploy with the web app build output.
• calculator remains a console sample or operational utility unless a later plan explicitly migrates it as a separate artifact.
• calculator.tests uses xUnit with Testcontainers PostgreSQL for automated test isolation.
• A persistent local PostgreSQL container may exist for manual app/UI iteration, but it is not a migration source.

Prerequisites

1. Ensure the GitHub Copilot App Modernization extension is installed and enabled.
2. Ensure required assessment tools are available and selected.
3. Ensure the target projects are accessible at:
   • $(git rev-parse --show-toplevel)\src\workspace\calculator-xunit-testing
4. Ensure dependencies can be restored and project metadata can be analyzed.
5. Validate current runtime baseline before assessment:
   • Run dotnet --info.
   • Run dotnet build .\calculator.slnx.
   • Run dotnet test .\calculator.slnx --verbosity minimal.
   • Run dotnet list .\calculator.slnx package.
   • Capture local Docker state with docker ps when Docker is available.
6. Before migrating, check for and terminate any local applications or services that may interfere with assessment execution (local apps, local PostgreSQL containers).
7. Preserve unrelated working tree changes. Do not revert user edits or formatter changes outside the assessment report or this prompt.

Extension Invocation (Required)

Use the App Modernization extension workflow to run pre-migration assessment and report generation:

• Run prerequisite checks and technology detection.
• Execute the migration assessment for Azure readiness.
• Collect generated findings, recommendations, and modernization actions.

If tool-level invocation is available, use:

• mcp_github_copilot_appmod-precheck-assessment or the equivalent command exposed in your environment
• mcp_github_copilot_appmod-run-assessment or the equivalent command exposed in your environment
• uploadAssessSummaryReport when an issue/report destination is provided

If command names differ, do not fail the workflow solely on naming mismatch. Use the extension-discovered command equivalents and record which commands were executed.

If direct assessment commands are not exposed, use the available migration assessment report viewer if present, then record partial success with explicit missing artifacts. Do not use a migration execution tool such as mcp__microsoft_gi_appmod-run-task for this prompt, because this step must not modify code for migration or deploy resources.

Task

Assess the project for migration readiness to Azure and produce an actionable migration baseline.

Scope

• Evaluate application architecture, dependencies, and runtime compatibility.
• Identify blockers, warnings, and modernization opportunities.
• Provide recommended Azure target options and migration approach.
• Include Linux-first parity guidance for Codespaces/devcontainers through Azure hosting.
• Map local PostgreSQL development/testing patterns to Azure Database for PostgreSQL strategy.
• Review current workflow and deployment-readiness gaps only as assessment findings. Do not create Infrastructure as Code in this prompt.

Assessment-Derived Focus Areas

When refreshing the report, verify and update these known findings from the previous assessment:

• Whether extension-native precheck and assessment artifacts are available, including raw report IDs or file paths.
• Whether Blazor JavaScript interop disposal handles disconnected circuits without surfacing JSDisconnectedException during shutdown, browser refresh, reconnect, or App Service recycle scenarios.
• Whether test tooling packages are current enough for a .NET 10 migration baseline, especially Microsoft.NET.Test.Sdk, xunit, Npgsql, and Testcontainers.PostgreSql.
• Whether formal PostgreSQL schema migration, seed promotion, and rollback artifacts exist.
• Whether runtime configuration has an environment mapping for local, CI, and Azure App Service settings.
• Whether secrets are planned for Azure App Settings and Key Vault instead of local Docker credentials or host ports.

Reliability Requirements

1. Fail fast on prerequisite failures and include actionable remediation.
2. If assessment partially succeeds, return partial findings plus explicit missing artifacts.
3. Capture exact execution context in the report:
   • Dotnet SDK/runtime versions
   • Assessment command path used
   • Report file paths generated
4. Keep recommendations environment-specific, not generic.
5. Distinguish assessment blockers from implementation work. Do not fix application code, create infra/, or run deployment commands during this prompt.
6. Record any existing local services that might affect reproducibility, including persistent PostgreSQL containers and local Blazor app processes.

Recommended Target Architecture

Use this target architecture as the default recommendation unless the refreshed assessment disproves it:

• Preferred app host: Azure App Service Linux for calculator.web.
• Shared logic: calculator.library included in the web app build output.
• Data tier: Azure Database for PostgreSQL Flexible Server for persisted calculator history, shared test-case catalog, or future runtime data.
• Configuration: Azure App Settings for non-secret environment values.
• Secrets: Azure Key Vault for secrets, with managed identity where feasible.
• Test posture: Keep Testcontainers in automated tests and CI where Docker is available. Do not treat Testcontainers databases as migration sources.
• Deployment preparation: Recommend future Infrastructure as Code under infra/, validated with azd provision --preview or Azure deployment what-if before provisioning.

Required Phase Plan

The report must include a phase-based plan with these minimum actions.

Phase A: Close blockers

• Execute the official App Modernization extension assessment workflow and capture generated artifact paths.
• Harden Blazor disposal behavior so expected JavaScript disconnections during circuit teardown do not fail the app.
• Decide whether the first Azure migration hosts only calculator.web or also packages calculator as a separate sample or utility artifact.

Phase B: Implement migration prerequisites

• Define and validate PostgreSQL schema migration, seed promotion, and rollback scripts.
• Review and update test/tooling dependencies to supported .NET 10 baselines.
• Add an environment mapping matrix for local, CI, and Azure App Service settings.
• Plan Key Vault, managed identity, and RBAC scope before any resource creation.
• Create infra/ deployment assets only after assessment artifacts and target topology are confirmed.

Phase C: Validate pre-deployment readiness

• Add Azure-targeted smoke tests.
• Validate Linux parity in CI/CD and runtime configuration.
• Run azd provision --preview or Azure deployment what-if during the later deployment-preparation step.
• Finalize cutover and rollback guidance for PostgreSQL schema changes.

Required Outputs

1. Assessment execution status (success/failure).
2. Assessment artifact/report location.
3. Prioritized findings:
   • Critical blockers
   • Major issues
   • Informational recommendations
4. Migration readiness summary with clear next steps.
5. Recommended Azure target architecture for this repo, including:
   • Preferred app host option (for example, App Service Linux)
   • Data tier mapping (Azure Database for PostgreSQL)
   • Configuration/secrets approach for transition from local development
6. Phase-based next-step plan:
   • Phase A: close blockers
   • Phase B: implement migration prerequisites
   • Phase C: validate pre-deployment readiness
7. Missing artifact log for unavailable App Modernization commands, report IDs, or raw report files.
8. Updated local report at docs/azure-migration-assessment-3.02.md.

Success Criteria

• Assessment is executed through the App Modernization extension when the command path is available.
• If only partial extension access is available, the report records the attempted path, available viewer/report access, and exact missing artifacts.
• A migration assessment report is generated or refreshed at docs/azure-migration-assessment-3.02.md.
• Findings are categorized and actionable.
• Phase A, Phase B, and Phase C are populated with assessment-specific actions.
• Output explicitly covers Linux-first development parity and PostgreSQL migration mapping.
• No Azure resources are deployed and no migration execution tool is run.