CH13-04: Migration Stages and Data Dependencies

Goal

The previous sections focused on the hybrid path: connectivity, identity, DNS, routing, and inspection. This section explains why that path changes over time.

Migration rarely moves every application, database, file share, identity dependency, and integration at once. Workloads, data, and supporting systems move at different speeds. Hybrid architecture is the shape created during that movement.

The durable idea is:

Hybrid architecture changes as workloads, data, and dependencies move at different speeds.

The Short Version

The tempting migration view is:

Move the server to Azure.

The stronger architecture view is:

Move the workload only after mapping the dependencies it needs to run safely.

Those dependencies may include databases, file shares, APIs, identity providers, DNS zones, batch jobs, message brokers, monitoring tools, backup jobs, support processes, reporting extracts, and security controls.

Migration moves dependencies, not just servers.

Common Migration Stages

A hybrid migration often passes through stages like these:

Stage 1: app and data on-premises
Stage 2: app in Azure, data on-premises
Stage 3: app and data in Azure, integrations remain hybrid
Stage 4: reduced on-premises dependency

Real migrations may be messier, but the model helps reveal which dependencies cross the boundary at each stage.

The stage matters because the right design for a pilot is not always the right design for steady-state production.

Why Data Dependencies Control Migration

Data often moves slower than application code.

Reasons include:

• Several applications share the same database.

• Data is large, sensitive, or regulated.

• Transaction boundaries are hard to split.

• Reporting or batch jobs depend on current data placement.

• Backup, recovery, and audit processes are tied to existing systems.

• Latency between app and database would hurt user experience.

• A legacy system remains the system of record.

If the application moves to Azure but the database stays on-premises, every database call crosses the hybrid path. That can be acceptable for a transition, but it must be tested and operated. A chatty application that made hundreds of low-latency database calls inside a data center may perform poorly when those calls cross a network boundary.

Dependency Mapping

Before moving a workload, map dependencies in practical language:

This map becomes the migration architecture. It tells the team which paths must exist, which dependencies should move first, and which temporary designs need owners.

Example: Claims Application in Transition

An insurance company moves a claims web application to Azure. The app tier can run on managed hosting, but the claims database and mainframe policy integration stay in the data center for now.

The temporary state looks like this:

Users
	-> Azure-hosted claims app
	-> hybrid connectivity
	-> on-premises claims database
	-> mainframe policy integration

This design can work if the team handles:

• Database latency and connection behavior.

• DNS resolution for database and mainframe endpoints.

• Firewall rules and return routes.

• Identity and service account access.

• Monitoring from Azure app to on-premises dependency.

• Rollback if cutover exposes unexpected performance problems.

• A plan for whether the database later moves, is modernized, or remains on-premises.

Without those decisions, the app migration may look successful until production traffic arrives.

Temporary Patterns Need Exit Criteria

Temporary hybrid patterns often become permanent because nobody owns the next decision.

Examples:

• A VPN built for testing remains the production path.

• A firewall exception created for migration remains open.

• DNS forwarding rules grow without documentation.

• A service account created for cutover is never rotated.

• Old batch jobs keep running because no one owns replacement logic.

• Duplicate monitoring systems produce conflicting alerts.

For each temporary path, define:

• Why it exists.

• Who owns it.

• How it is monitored.

• What risk it carries.

• When it will be reviewed.

• What will replace it or confirm it as steady-state.

This turns migration from a one-time move into an operated transition.

Common Mistakes

• Moving compute before understanding data latency and transaction behavior.

• Forgetting batch jobs, file shares, exports, reports, and monitoring agents.

• Treating all dependencies as technical when some are ownership, audit, or process dependencies.

• Assuming temporary hybrid paths will disappear without a retirement plan.

• Ignoring rollback and recovery until cutover weekend.

• Moving one application without checking which other applications share the same database or integration.

If Someone Asks You

How do data dependencies affect Azure migration architecture?

A good answer is:

Data dependencies often control migration order because applications depend on where data lives, how fast it can be reached, who owns it, how it is backed up, and which other systems share it. Moving compute to Azure while data stays on-premises creates a hybrid runtime path that must be tested for latency, routing, DNS, security, monitoring, and recovery. Migration planning should map data, identity, APIs, files, batch jobs, and operations before moving workloads.

What You Should Remember

Migration moves dependencies, not just servers.

Questions to Check Your Understanding

1. Why can data location control migration order?

2. What dependencies are easy to miss?

3. Why should temporary hybrid designs have owners and exit criteria?