Cloud Migration Begins with Dependency Mapping

Cloud migration begins with dependency mapping. Moving a server is not the same as moving a service. Applications depend on identities, databases, queues, DNS, certificates, vendors, jobs, and people. A migration plan that ignores those links creates surprises at cutover.

The shared-responsibility model changes by service and provider, but customer ownership of architecture, data, access, configuration, and recovery does not disappear.

On this page

• What a dependency map should show
• Why ownership is part of the architecture
• How to classify migration risk
• What to test before cutover
• How service models change the work
• Why identity and secrets deserve early attention
• How to plan recovery in the new environment
• What does not matter as much as a dependency map
• Turn the design into an operating control
• Test the failure path
• Measure the result without false precision
• Review change and ownership
• Keep the handoff explicit

What a dependency map should show

Map the request path from user or device to application, service, data store, external provider, and operator. Include synchronous calls, background jobs, secrets, certificates, queues, and scheduled processes.

The map need not be beautiful. It must be accurate enough to answer what breaks when one component changes, becomes unavailable, or moves to another environment.

• Application and data dependencies.
• Identity, network, DNS, and certificate links.
• Batch jobs, queues, vendors, and operators.

Why ownership is part of the architecture

A diagram without owners becomes a museum piece. For each dependency, name the technical owner, business owner, support path, and evidence that the dependency is healthy.

Ownership also exposes hidden assumptions. A service may be critical even when nobody has listed it as a production dependency because an analyst runs a manual step every morning.

• Name service and business owners.
• Record support and escalation paths.
• Include manual and human dependencies.

How to classify migration risk

Risk rises when a dependency is unknown, stateful, hard to test, externally controlled, or difficult to restore. Classify those factors before choosing a migration wave.

Do not rank a workload by compute size alone. A small authentication service or certificate authority can block many larger applications.

• Unknown and undocumented links.
• State, data loss, and recovery risk.
• External and hard-to-test dependencies.

What to test before cutover

Test the full user journey, not only whether a virtual machine starts. Verify identity, data access, integrations, scheduled work, observability, backups, and rollback or failback steps.

Use production-like data handling and permissions. A test that works only with administrator access can hide the failure that real users will experience.

• Critical user and service paths.
• Read, write, queue, and job behaviour.
• Monitoring, backup, and rollback.

How service models change the work

Infrastructure, platform, and software services place different tasks with the provider. Managed services can reduce infrastructure operations while adding configuration, identity, data, and supplier-review duties.

Record the exact service boundary for each workload. “In the cloud” is not a control description and does not tell an operator who must fix a failure.

• Service model and provider scope.
• Customer-configured controls.
• Evidence and review frequency.

Why identity and secrets deserve early attention

Migration often creates temporary accounts, copied secrets, broad roles, and duplicated integrations. These shortcuts can remain after the application is declared stable.

Use central identity where practical, separate administrative access, rotate secrets, and remove migration credentials when the cutover is complete.

• Human and machine identities.
• Least privilege and separation.
• Secret rotation and removal evidence.

How to plan recovery in the new environment

Recovery is part of migration acceptance. Define what must be restored, in what order, by whom, and within which objective. Test restoration rather than relying on a successful backup message.

Include provider failure, identity failure, region or site loss, corrupted data, and an unavailable dependency. The correct recovery path may not be the same as the deployment path.

• Recovery sequence and owner.
• Backup protection and restoration test.
• Failure scenarios and communications.

What does not matter as much as a dependency map

A cloud provider label, a modern landing zone, or a low migration cost does not prove that a service is ready. Readiness is visible when the path, owner, evidence, and recovery action are known.

Keep the map current after migration. Architecture drifts when teams add integrations faster than they update diagrams.

• Do not equate migration with modernisation.
• Do not call an untested backup recovery.
• Do not retire the map at go-live.

Turn the design into an operating control

A design becomes an operating control when a named person can perform it, another person can review it, and the organisation can show evidence that it happened. Write the trigger, the action, the expected result, and the exception path in language an operator can use during a busy day.

Keep the control close to the workflow. If staff must leave one system, search an unrelated document, and ask another team before acting, the control will be skipped when pressure rises. Reduce that friction without hiding the decision.

• Name the trigger and operator.
• State the expected result.
• Record the exception and escalation.

Test the failure path

Happy-path demonstrations are useful for learning, but they do not prove resilience or security. Test incomplete data, unavailable dependencies, expired credentials, unexpected volume, delayed input, and a human decision that disagrees with the system output.

A failed test is useful when it produces an owner, a correction, a retest date, and a decision about whether the remaining risk is acceptable. Do not quietly convert a failed test into a passing narrative.

• Choose realistic failure cases.
• Record evidence and observed impact.
• Assign correction and retest dates.

Measure the result without false precision

Choose a small set of measures that show whether the control or workflow is working. Define the denominator, time period, data source, owner, and action that follows a meaningful change.

Use estimates and scenarios honestly. A precise-looking number built on incomplete data is less useful than a range with a clear boundary and a plan to improve measurement.

• Keep definitions stable.
• Separate measured, estimated, and projected results.
• Connect each measure to a decision.

Review change and ownership

Technology environments change through releases, suppliers, data, policies, identities, and user behaviour. A control that was adequate at launch may not remain adequate after a material change.

Set a review trigger as well as a calendar review. When the owner, dependency, data, exposure, or failure mode changes, revisit the design and keep the decision record with the evidence. Keep the next review date visible.

• Record version and change.
• Review after material events.
• Keep owner, date, and decision visible.

Keep the handoff explicit

Most operational failures occur between teams, systems, or stages of work. State what one owner must provide, what the next owner checks, and what happens when the handoff is late, incomplete, or rejected.

This simple contract improves incident response and day-to-day work. It also makes automation safer because the input, output, and exception are visible rather than implied.

• Name the sender and receiver.
• Define the input and acceptance check.
• Record rejection, retry, and escalation.

Operating rule: Name the owner, the evidence, and the action before calling a technology control complete.

Comparison table

FAQ

Is dependency mapping only for complex migrations?

No. Even a small application may depend on identity, DNS, certificates, a database, a vendor API, or a manual process.

Should every dependency block migration?

No. It should be classified, owned, tested, or explicitly accepted as a risk before the migration wave proceeds.

Who owns a managed cloud service?

The provider owns controls within its service scope. The customer still owns its configuration, identities, data, use, monitoring choices, and recovery responsibilities.

When should the map be updated?

Update it after architecture, integration, identity, data, or operational changes. Treat it as a living operational record.

How can a team start without rebuilding everything?

Start with one important workflow, define the owner and evidence, test the failure path, and expand only after the operating result is understood.

What should be recorded after a review?

Record the scope, date, evidence, decision, owner, unresolved risk, and next review or correction. A short honest record is more useful than an impressive but untraceable claim.

When should the design change?

Change it when the workflow, data, identity, dependency, supplier, exposure, user group, or failure mode changes materially. A calendar review alone may miss the event that changed the risk.

What is a useful first metric?

Choose a measure close to an operating decision, define its denominator and time period, and state what action follows when it crosses the agreed threshold.

Conclusion

The useful technology decision is the one that can be tested. Define the operating problem, record the evidence, assign ownership, and review the result after launch. Clear scope beats a large claim, and a measured workflow beats a polished demo.

Sources

• CISA Cloud Security Technical Reference Architecture
• NIST Cloud Computing Definition