# Documentation and Evidence Path

## Preferred evidence order

1. Microsoft Learn documentation through the user's configured documentation MCP for documented Azure behavior.
2. Sampled read-only Azure evidence, when safely available, for current configured-environment observations.
3. Sanitized user-provided evidence.
4. Clearly labeled inference.

## What each evidence type can prove

- Microsoft Learn documentation can prove documented service behavior, supported concepts, limitations, and recommended patterns.
- Sampled read-only evidence can prove the sampled configured state at the time observed.
- Sanitized user evidence can prove only what the snippet shows.
- None of these alone prove broad regional availability, future success, full account posture, or production readiness.

## Safe usage pattern

- State whether each claim is documentation-based, sampled-current-state, user-provided, or inference.
- Use read-only queries before recommending changes.
- Do not include sensitive internal identifiers, tenant identifiers, subscription identifiers, or secrets in committed docs or final findings.
- If no sampled evidence is available, say the review is documentation-based and list the exact evidence still needed.

# Azure Migration Cutover Operations

Use this reference for current, source-grounded service behavior and the hard review gates that the lean `SKILL.md` intentionally does not carry.

## What people get wrong

- Calling an assessment green and assuming the cutover is ready.
- Grouping servers by owner or convenience while ignoring runtime dependencies.
- Using stale discovery, missing performance data, or incomplete inventory for final go/no-go.
- Cutting over into an unfinished landing zone with weak DNS, routing, monitoring, backup, or identity.
- Treating rollback as “restore from backup” without timing and data-loss proof.

## Officially grounded service shape

Microsoft Learn evidence says Azure Migrate supports decide, plan, and execute phases: discovery, business case, Azure readiness, right-sizing, cost estimation, dependency analysis, replication, migration, and modernization. Wave planning quality depends on complete discovery, accurate inventory, dependency analysis, application grouping, metadata enrichment, and assessments. Planning agents can interpret migration data but execution actions remain in Azure Migrate workflows.

- Azure Migrate discovery collects inventory and performance data used for business cases and assessments.
- Assessments provide readiness, right-sizing, cost estimates, and blockers, but need current data and correct assumptions.
- Dependency analysis helps group workloads and avoid missed application dependencies.
- Landing-zone readiness includes identity, network, governance, security, management, and operations foundations.
- Cutover readiness adds wave sequencing, freeze windows, validation, rollback, and ownership.

## Non-negotiable design rules

- Require current discovery and assessment timestamps before go/no-go.
- Require dependency evidence for every workload group in a wave.
- Require target landing-zone controls before migration execution.
- Require least-privilege migration permissions and named operators.
- Require rollback checkpoints, data-loss boundary, and post-cutover validation owner.

## Minimal safe implementation flow

- Scope migration wave, workloads, source platform, target region/subscription, landing zone, and business owner.
- Collect assessment, dependency, business case, replication/test migration, landing-zone, and runbook evidence.
- Classify blockers by readiness, dependency, permissions, data, network, identity, monitoring, backup, and rollback risk.
- Decide go, no-go, or conditional go with explicit cutover criteria.
- Define post-cutover validation, monitoring, handover, and rollback deadline.

## High-risk assumptions to kill

- Assessment readiness is not cutover readiness; final cutover still needs current dependencies, replication state, freeze controls, validation, and fallback.
- A landing zone that is missing DNS, routing, identity, monitoring, backup, or policy guardrails is not ready because migration tooling can move assets.
- Near-zero downtime is not a slogan; replication lag, final synchronization, write freeze, traffic switch, and post-cutover validation must all be evidenced.
- Rollback that loses unreplicated writes or misses DNS/load-balancer reversion is not a rollback plan.
- Decommission is not safe until source-retention and business validation windows have expired.

## Safe command/code verification targets

- Verify discovery freshness, assessment assumptions, dependency grouping, replication health, and test migration evidence before go/no-go.
- Confirm landing-zone controls: network connectivity, DNS, identity/RBAC, policy, monitoring, backup, and support ownership.
- Check cutover runbook for write freeze, final sync, data-integrity checks, DNS/load-balancer switch, and 24-48 hour monitoring owner.
- Verify fallback decision point, source-environment retention, accepted RPO/RTO, and rollback commands before traffic cutover.
- Label any missing current Azure Migrate or landing-zone evidence as a blocker, not an assumption.

## Safe verification targets

- Discovery covers all in-scope workloads with current data.
- Assessment assumptions, sizing, cost, and readiness blockers are reviewed.
- Dependency groups align to application behavior and outage window.
- Landing zone has connectivity, DNS, identity, policy, monitoring, backup, and support ownership.
- Rollback has tested procedure, decision point, and accepted RPO/RTO impact.

## When to push back

- The plan lacks current Azure Migrate evidence.
- Dependency mapping is guessed or incomplete.
- Landing-zone controls are “coming later.”
- Rollback cannot be executed within the business recovery window.

# Official Sources

Use these sources to ground the skill. Microsoft Learn documentation proves documented Azure behavior; it does not prove the user's tenant, subscription, RBAC, quota, migration project, network, telemetry, deployed resources, or production readiness.

## Primary Microsoft Learn sources

- https://learn.microsoft.com/azure/migrate/migrate-services-overview?view=migrate
- https://learn.microsoft.com/azure/migrate/concepts-migration-planning?view=migrate
- https://learn.microsoft.com/azure/migrate/common-questions-discovery-dependency-analysis?view=migrate
- https://learn.microsoft.com/azure/migrate/overview?view=migrate
- https://learn.microsoft.com/azure/migrate/platform-landing-zone?view=migrate
- https://learn.microsoft.com/azure/cloud-adoption-framework/ready/landing-zone/

## Grounding notes

- Documentation-based claim: Microsoft Learn evidence says Azure Migrate supports decide, plan, and execute phases: discovery, business case, Azure readiness, right-sizing, cost estimation, dependency analysis, replication, migration, and modernization. Wave planning quality depends on complete discovery, accurate inventory, dependency analysis, application grouping, metadata enrichment, and assessments. Planning agents can interpret migration data but execution actions remain in Azure Migrate workflows.
- Current-state claim: requires sampled read-only Azure evidence or sanitized user-provided evidence.
- Inference: allowed only when labeled and tied to observed fields or documented behavior.
- Do not include sensitive internal identifiers or secret material in findings.

## Source use rules

- Prefer Microsoft Learn documentation through the user's configured documentation MCP for current Azure service behavior.
- Use sampled read-only Azure evidence only to validate current configured-environment observations.
- If documentation and sampled evidence appear to conflict, report both and stop short of a production-ready verdict.
- Re-check official sources before changing high-risk guidance, because cloud behavior and feature availability can change.

# Safety Checklist

## Evidence labels

- `documentation-based`: grounded in Microsoft Learn or listed official documentation.
- `sampled-current-state`: grounded in read-only Azure observations from the user's configured tools.
- `user-provided`: grounded in sanitized snippets supplied by the user.
- `inference`: reasoned from evidence but not directly proven.

## Mutation boundary

- Default to read-only review.
- Do not perform create, update, delete, activate, approve, cancel, deactivate, migrate, cut over, route, peer, deploy, alert, suppress, or configuration changes unless the user explicitly asks and approval is clear.
- Prefer preview, assessment, status, list, show, query, activity-log, dependency, and diagnostic evidence before any mutation.

## Credential and data boundary

- Never ask users to paste credentials, tokens, tenant IDs, subscription IDs, customer data, private keys, appliance secrets, migration inventory dumps, log payload secrets, or raw environment dumps.
- Summarize sensitive evidence by field presence, control state, and risk; do not reproduce secret material.

## Risk gates

- Stop on ambiguous target, ambiguous principal, missing approval, missing owner, missing rollback, stale assessment, incomplete dependency mapping, unclear routing, or missing telemetry for high-impact assets.
- Separate documented product behavior from sampled configured-environment evidence.

## Asset-specific hard line

Do not equate Azure readiness with cutover readiness. Treat stale assessments, weak dependency mapping, broad migration permissions, missing rollback checkpoints, and incomplete landing-zone connectivity or monitoring as high-risk blockers.

# Workflow and Output Contract

## Execution flow

1. Scope the exact target, environment boundary, owner, requested decision, and evidence available.
2. Load `official-sources.md`, then the component operations guide for service behavior and risk gates.
3. Gather sampled read-only evidence only when available and safe.
4. Compare observed posture against documented behavior, least-privilege expectations, and operational safety rules.
5. Return a verdict with evidence level, blockers, safe next actions, and open questions.

## Required output

- `verdict`: pass, warn, fail, or blocked.
- `evidence_level`: documentation-based, sampled-current-state, user-provided, inference, or mixed.
- `scope`: what was reviewed and what was not reviewed.
- `blockers`: issues that prevent a safe or production-ready conclusion.
- `findings`: severity-labeled risks with source labels.
- `safe_next_actions`: reversible actions first; mutation only with explicit approval.
- `open_questions`: missing facts that would change the verdict.

## Stress checks

- What assumption would make this recommendation unsafe?
- Which identity, migration, network, telemetry, route, or dispatch decision has the largest blast radius?
- What evidence would disprove the claimed readiness?
- Is the answer accidentally treating documentation as configured-environment proof?

## Response discipline

Use Microsoft Learn documentation through the user's configured documentation MCP for documented Azure behavior. Use sampled read-only Azure evidence only for current configured-environment observations and label it as sampled evidence.