Engage
Frame mission context, stakeholders, decision authority, and target impact level.
Internal enablement
A technical orientation for delivery teams explaining the canonical Engage -> Discover -> Assess -> Verify -> Synthesize -> Plan -> Deliver flow, standards imprint, migration foundation readiness, and transition roadmap logic.
cMAP does not prescribe an application migration treatment, perform execution, or make authorization decisions. It identifies the foundation services, governance decisions, evidence quality, and operating capabilities that must exist before a sponsor releases material for approved partner follow-on work.
Functional Flow
The internal team should understand cMAP as a flow from evidence intake to client-facing recommendations, not as a spreadsheet of scores.
Frame mission context, stakeholders, decision authority, and target impact level.
Register artifact intake, sensitivity, ownership, and evidence availability.
Score the 51 artifacts on a 0โ4 evidence scale across People, Process, and Technology.
Confirm scores with SMEs and capture follow-ups before release language is used.
Apply rule sets, standards imprint, and 6R readiness logic to expose decisions.
Sequence transition and transformation actions across 0โ48+ month horizons.
Package the readout, reports, roadmap, traceability, and evidence caveats for sponsor-controlled release.
Decision Logic
The value is not the score alone. The value is the interpretation of what the score means for mission cloud operations.
Relationship Areas
These mock-ups show high-level relationship areas across the 10 cMAP domains without claiming compliance, authorization, or CSP service approval.
Migration Foundation Readiness
cMAP maps artifact gaps to minimum viable foundation services before a client selects migration treatments for specific applications.
Baseline landing zone, identity, network, logging, monitoring, wave planning, and environment controls needed before lift-and-shift is responsible.
Consumption, service catalog, FinOps, integration, data governance, acquisition, and IL alignment needed before managed cloud services become practical.
Automated toolchains, platform engineering, DevSecOps, CaC/IaC, telemetry, and cloud-native operating patterns needed before deeper modernization.
Legacy, latency-sensitive, RISC/Unix, coupled, or boundary-constrained systems may need isolation, surround controls, or delayed migration treatment.
People Capacity Reference
This reference supports internal interpretation of team structure, platform skills, support tiers, hiring zones, and impact-level considerations. It does not alter evidence scores or create an engagement finding.
Roadmap Logic
The time horizons explain why some work can begin immediately while other work needs architecture, acquisition, staffing, integration, or platform decisions.
Close no-regret blockers and evidence gaps the existing team can begin without waiting for major acquisition.
Stand up platform foundations, operating model depth, governance, integrations, and initial migration capability.
Move beyond baseline migration into managed services, automation, continuous monitoring, and repeatable delivery.
Scale cloud-native capability, automated evidence, portfolio rationalization, FinOps, and sustained mission operations.
Consultant Use
This page is intentionally plain-language enough for pursuit teams and precise enough for technical delivery leads.
Where readiness is real, where evidence is thin, which decisions are blocked, and what foundation services must exist before migration velocity is credible.
Recommendations come from scored artifacts, domain readiness, standards/citation context, 6R foundation thresholds, and transition/transformation timing rules.
It does not replace RMF assessment, AO decisions, control inheritance validation, CSP authorization status, procurement authority, execution authority, or application-level migration disposition analysis. Phase 2 follow-on material can support WWT or approved partners only after sponsor release.
Release Roadmap
Future production work is sequenced as minor feature releases, major feature releases, or deferred options while preserving the static/local default path.