The crawl phase establishes a baseline by onboarding the existing monolith with minimal disruption. The walk phase extends the foundation by deploying cloud infrastructure and distributed mesh capabilities while new services are built. The run phase uses that foundation to redirect traffic, deprecate legacy behaviour, and complete cutover with simpler rollback if needed.
How the three phases change the shape of the migration
The crawl phase is about establishing control with the least possible disruption. Teams keep the existing application path largely intact while they document dependencies, define operating assumptions, and get the first workloads into the target environment.
The walk phase is where the migration becomes more cloud-native in practice. New platform capabilities, network patterns, and deployment workflows are introduced so the organisation can run parts of the estate in a more distributed way without forcing a full cutover yet.
The run phase is the point at which the new operating model carries the production load. Traffic is redirected, legacy behaviour is retired, and the programme focuses on stable operations rather than migration scaffolding.
Why crawl is the stabilisation phase
Crawl is deliberately conservative because its main job is to reduce uncertainty. The team is usually proving that the workload can function in the new environment, that monitoring and access paths work as expected, and that the migration plan reflects real dependency data rather than assumptions.
That makes crawl useful for baseline setting, but it also means the phase is not the right moment for broad architectural change. If the monolith is refactored too aggressively at this stage, the programme can lose the one thing crawl is meant to create: a safe, observable starting point.
For migration teams, crawl often behaves like a controlled rehearsal. The deliverable is not feature parity with the future state, but confidence that the cloud foundation can host the application and support later decomposition without surprises.
What walk adds before full cutover
Walk introduces the platform capabilities that the final operating model depends on, such as cloud infrastructure patterns, service connectivity, and the first distributed components. At this stage, the organisation is no longer just proving that the workload can land in cloud, it is proving that the cloud foundation can support new build activity alongside the existing estate.
This phase matters because it reduces the risk of a hard jump from monolith to fully transformed services. By building the new services while the old path still exists, teams can validate integration, performance, and operating processes in smaller increments.
Walk is therefore a transitional state, not a midpoint for its own sake. If crawl is about landing safely, walk is about proving that the target platform can support repeated delivery without depending on the legacy application for every business function.
What run means operationally
Run is not simply “more cloud”; it is the moment the migration programme stops depending on the old path as the primary operating model. Traffic is shifted to the new services, legacy functions are deprecated, and rollback becomes simpler because the new architecture is now the normal one rather than an exception path.
This phase is where the business value of the migration becomes visible. The organisation should see cleaner release paths, fewer hybrid dependencies, and a lower need to preserve old behaviour for compatibility. At the same time, run usually increases the importance of steady-state operations, incident response, and cost discipline because the platform is now carrying real production demand.
The practical difference is that crawl and walk are migration-led, while run is operations-led. Once a programme reaches run, success is measured less by how much has been moved and more by how reliably the new model can absorb change.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | CM-2 — Baseline Configuration | Crawl and walk depend on establishing and evolving a stable baseline. |
| CM-8 — System Component Inventory | Crawl requires understanding dependencies and the current monolith footprint before cutover. | |
| Recommendation — Define and maintain a migration baseline before introducing higher-change cloud patterns. Inventory application and platform components before moving from crawl to walk. | ||
| NIST CSF 2.0 | GV.PO-01 — Policy, standards, and procedures | Phase gates need clear policy and procedure definitions across the migration programme. |
| RC.RP-01 — Recovery plan executed | Run phase cutover benefits from a tested rollback and recovery posture. | |
| Recommendation — Set explicit phase-entry and phase-exit procedures for crawl, walk, and run. Test rollback and recovery paths before completing run-phase cutover. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | Each phase depends on controlled platform configuration as cloud capability expands. |
| Recommendation — Harden and standardise cloud configurations as the programme moves from crawl to walk. | ||
Practitioner Guidance
What to verify: Make sure each phase has a distinct exit condition. Crawl should prove baseline viability, walk should prove the target platform can support new build and integration patterns, and run should prove the old path can be retired without creating hidden dependency risk.
Decision rule: If the team cannot explain what would be decommissioned, simplified, or operationally shifted between phases, the programme is probably treating crawl, walk, and run as labels rather than real delivery gates.
What good looks like: A good migration programme uses crawl to reduce unknowns, walk to expand capability with measured complexity, and run to normalise the cloud operating model so the legacy path stops shaping future change.
Practitioner takeaway: The phases are not just levels of cloud adoption, they are different risk positions, so the migration should only advance when the next phase removes uncertainty rather than simply adding more technology.
Related resources from NHI Mgmt Group
- What is the difference between privilege reduction and secret rotation?
- What is the difference between a rules-based secret scanner and a hybrid scanner?
- What is the difference between code scanning and runtime identity monitoring?
- What is the difference between zero trust for users and zero trust for NHIs?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 24, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
