Teams should use a crawl, walk, run sequence that first stabilises the current monolith, then extends a distributed network foundation, and only then shifts traffic to new services. That approach reduces migration risk because connectivity, governance, and cutover mechanics are introduced before major application changes. The goal is continuity for users while engineering teams modernise in parallel.
Why a crawl, walk, run sequence fits hybrid migration work
A crawl, walk, run migration works because it separates platform readiness from application change. Teams first reduce fragility in the legacy estate, then establish the network, access, and deployment foundations needed for services to coexist, and only then increase cutover scope. That sequence matters when the business cannot tolerate a hard stop while modernisation is underway.
The practical advantage is that each phase creates a narrower failure surface. If the current monolith remains unstable, microservices will inherit operational noise and unclear dependencies. If the distributed foundation is not in place, service decomposition simply moves risk into routing, governance, and integration problems. The sequence is less about speed than about making the next step measurable and reversible.
For teams using service decomposition alongside a retained legacy core, this is also the point where architecture discipline matters more than feature velocity. A service boundary is only helpful when the surrounding connectivity, observability, and ownership model can support parallel operation. That is why the sequence should be driven by operational readiness, not by a migration calendar alone.
What changes at each stage of the migration
In the crawl stage, the goal is stabilisation. Teams should harden the monolith, map the critical dependencies, and reduce variability in the systems that must stay live during the migration. This is where technical debt is not yet removed, but it is made visible enough that later changes do not break essential paths.
In the walk stage, the goal is to build the shared foundation that new services will depend on. That usually means establishing network segmentation, service-to-service connectivity patterns, deployment pipelines, logging, and governance rules before application ownership is pushed outward. A good NIST SP 800-207 Zero Trust Architecture perspective helps here because the platform should verify traffic and limit implicit trust as the estate becomes more distributed.
In the run stage, teams move real user traffic, narrow fallback paths, and retire the legacy dependency where it is safe to do so. At this point, success depends on whether the new services can operate with clear ownership, stable interfaces, and recovery paths that do not assume the old system will always be available. The migration becomes a controlled handoff, not a leap of faith.
How to avoid common cutover failures
The most common failure is trying to modernise application logic before the operating model is ready. That usually produces brittle services that are technically decomposed but still coupled through hidden network assumptions, shared credentials, or undeclared data flows. Teams also underestimate how often legacy systems remain part of the critical path long after the first service goes live.
A related risk is treating microservices as an automatic improvement rather than a design trade-off. Smaller services can improve delivery and isolation, but they also increase the number of moving parts that must be governed, observed, and recovered. This is why a staged migration should be paired with explicit interface ownership and operational rollback criteria, not just code refactoring.
For teams looking for a control lens on that operating model, NIST SP 800-53 Rev 5 Security and Privacy Controls is useful for thinking about access control, configuration management, and system integrity as migration work expands across environments. The migration plan should make it easy to answer who can change what, where the boundary is, and how rollback is verified.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST Zero Trust (SP 800-207), NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST Zero Trust (SP 800-207) | 5.0 — Zero Trust Architecture | Migration coexistence depends on limiting implicit trust between legacy and new services. |
| Recommendation — Apply zero trust principles to segment service paths and verify each interaction. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Staged cutover needs tight access boundaries while legacy and microservices run together. |
| CM-2 — Baseline Configuration | A crawl walk run migration requires stable baselines before introducing new service layers. | |
| SI-7 — Software, Firmware, and Information Integrity | Cutover safety depends on preserving integrity while systems are changed in parallel. | |
| Recommendation — Restrict migration access to the minimum set of roles and privileges required. Establish and maintain configuration baselines for each migration stage. Verify integrity controls before promoting new services into production traffic. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | Hybrid migration succeeds when legacy and new platforms are configured consistently. |
| Recommendation — Harden and standardise configurations across both legacy and service environments. | ||
Practitioner Guidance
What to prioritise: Stabilise the legacy workflow that users still depend on before expanding the number of new components. If the old system has unclear dependencies or unpredictable release behaviour, treat that as the first migration blocker.
What to verify: Confirm that the network, deployment, and observability layers are ready to support coexistence before shifting material traffic. A service that is functionally correct but operationally opaque is not ready for broad cutover.
Decision rule: If a migration step increases blast radius without improving rollback confidence, it is too early. Move only when the team can explain the failure mode, the fallback, and the owner for each stage.
Practitioner takeaway: The safest migration path is usually the one that creates operational control before architectural ambition, because legacy continuity is what buys teams the time to modernise well.
Related resources from NHI Mgmt Group
- What do teams get wrong about running API gateways as stateful systems?
- How should teams secure non-human identities across cloud and SaaS?
- How should security teams govern privileged access across cloud and legacy systems?
- How should teams modernise identity when cloud and legacy systems must coexist?
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
