CH03-08: Hybrid Enterprise Migration Scenario

Goal

This section applies the Chapter 3 networking model to a realistic enterprise migration scenario.

The point is not to produce the only possible network design. The point is to show how virtual networks, subnets, network security groups, route tables, VNet peering, hub-spoke design, VPN, ExpressRoute, private endpoints, and private DNS work together.

By the end of this section, you should be able to explain a hybrid Azure network design in a practical architecture discussion rather than listing networking features one by one.

Scenario

A large enterprise is migrating several internal applications from its data center to Azure.

The migration has these requirements:

• Internal applications should not be exposed directly to the public internet.

• Azure workloads must communicate with some on-premises systems during migration.

• Production and non-production need separation.

• Application tiers need segmentation.

• Sensitive Azure platform services should be reached privately.

• Central networking and security teams need inspection, logging, and operational visibility.

• Workload teams need enough autonomy to deploy and operate applications inside the shared foundation.

• The design should start with a manageable migration path and grow safely.

The design challenge is not simply connecting Azure to the data center. A strong design gives workloads the paths they need without turning Azure into one flat extension of the existing network.

The durable idea is:

A good hybrid migration network gives workloads the paths they need while preserving segmentation, private access, routing control, and operational visibility.

Restating the Architecture Problem

Before choosing controls, translate the scenario into architecture questions:

• Which network services belong in the shared platform hub?

• Which workloads need separate spoke VNets?

• How should production and non-production be separated?

• Which traffic should pass through central inspection?

• Which traffic should remain private?

• How should Azure connect to on-premises systems during migration and after migration?

• Where do private endpoints and private DNS fit?

• How can platform teams own shared connectivity without owning every workload detail?

These questions map directly to the networking concepts from this chapter.

Proposed Network Model

One possible high-level model is:

On-premises data center
        |
        | ExpressRoute or VPN
        v
Hub VNet: shared connectivity and inspection
        |
        +-- Spoke VNet: App 1 Production
        |     +-- Web subnet
        |     +-- App subnet
        |     +-- Private endpoint subnet
        |
        +-- Spoke VNet: App 1 Non-Production
        |
        +-- Spoke VNet: Shared Data or Integration

This is a starting model, not a final enterprise blueprint. A real organization may add more spokes by application, business unit, region, environment, regulatory boundary, or platform model. The value of the diagram is the separation of responsibilities.

The hub contains shared connectivity and inspection. The spokes contain workload environments. Hybrid connectivity enters through the hub. Workload teams deploy into spokes rather than building their own separate hybrid foundations.

Hub Responsibilities

The hub VNet is the shared network foundation.

It may contain:

• VPN Gateway or ExpressRoute gateway.

• Azure Firewall or a network virtual appliance.

• DNS forwarding or resolver components.

• Shared inspection paths.

• Central management or bastion access where appropriate.

• Network monitoring and flow visibility.

The hub should usually be owned by the platform, networking, or cloud foundation team. That team is responsible for keeping shared connectivity available, secure, monitored, and change-controlled.

The hub should not become a dumping ground for random workload resources. Its job is to provide shared paths and controls that many workloads use.

Spoke Responsibilities

Spoke VNets hold workload environments.

A spoke may represent:

• One application environment, such as payments production.

• One business unit's workload boundary.

• One regulated workload group.

• One non-production environment.

• One regional deployment of a workload.

Inside a spoke, subnets can separate application tiers and network functions:

Spoke VNet: claims-prod-vnet
  |
  +-- Subnet: web
  +-- Subnet: app
  +-- Subnet: private-endpoints

The workload team can own application resources inside the spoke. The platform team can still provide guardrails through policy, routing standards, DNS patterns, and approved connectivity paths.

This is the networking version of the Chapter 2 governance model: central teams own shared foundations and guardrails; workload teams own delivery inside them.

Segmentation Model

The migration should avoid flat networking.

For a production application, segmentation may look like this:

NSGs express some of this segmentation at subnet or network interface scope. Firewalls or appliances may enforce additional inspection policies. Identity and application controls still matter.

Routing and Inspection Model

Route tables should make important paths intentional.

For example, a production app subnet may have routes like:

Default outbound traffic -> Azure Firewall in hub
On-premises ranges       -> Hub gateway path
Shared service ranges    -> Hub or approved private path

The point is not the exact route syntax. The point is that traffic does not wander through the environment casually.

Central inspection can help with:

• Logging outbound traffic.

• Controlling internet egress.

• Inspecting traffic to on-premises systems.

• Enforcing shared network policy.

• Giving security teams visibility without making them owners of every workload.

But central inspection also creates dependencies. The firewall, routes, gateways, and DNS paths must be resilient and monitored. A broken hub can affect many spokes.

Hybrid Connectivity Choice

The enterprise may use VPN, ExpressRoute, or both.

A practical migration approach might be:

The design should not treat ExpressRoute as automatically correct for everything. It should match business requirements. It should also not leave critical production workloads on a temporary VPN path without reviewing reliability, throughput, and operations.

Hybrid connectivity should land in the hub or connectivity subscription so workload teams consume the shared path instead of building their own one-off data center connections.

Private Endpoint and DNS Model

Sensitive Azure platform services should be reached privately when the design requires it.

For example, a production application may use:

• A private endpoint for Azure Storage.

• A private endpoint for Azure SQL or another database service.

• A private endpoint for Key Vault.

• Private DNS zones linked to the spoke VNet or managed through the platform DNS pattern.

• DNS forwarding so on-premises systems can resolve private endpoint names when needed.

The important path looks like this:

Application subnet
        |
        | service name resolves to private IP
        v
Private endpoint subnet
        |
        v
Azure platform service

If on-premises systems also need private access to Azure services, DNS must work across the hybrid boundary. Otherwise, Azure clients may use the private path while on-premises clients still resolve public addresses, or vice versa.

Private endpoints reduce public network exposure. They do not replace service authorization, managed identities, encryption, logging, backups, or secure configuration.

Requirement-to-Control Map

The table below connects the scenario requirements to networking responses.

The pattern is responsibility placement. Each control has a job.

Trade-Offs

Every network design has trade-offs.

A strong design does not pretend these trade-offs disappear. It chooses intentionally and documents why.

Workload Onboarding Flow

Now imagine the claims application team is ready to migrate its first production workload.

A governed networking onboarding flow might look like this:

1. The platform team assigns a production spoke VNet or creates one from the landing zone pattern.

2. The address space is checked against the enterprise IP plan.

3. Subnets are created for web, app, and private endpoints.

4. VNet peering connects the spoke to the hub.

5. Route tables send selected traffic through central inspection and hybrid gateway paths.

6. NSGs allow only required tier-to-tier and management traffic.

7. VPN or ExpressRoute provides required data center reachability.

8. Private endpoints and private DNS are configured for sensitive Azure services.

9. Logs, flow visibility, firewall logs, and DNS ownership are reviewed before production cutover.

10. The workload team deploys application resources inside the approved network boundary.

This flow gives the workload team a usable place to build. It also gives central teams confidence that connectivity, segmentation, routing, private access, and operations have been considered.

Common Mistakes

• Migrating workloads before designing address spaces and routing. IP overlap and unclear routes can block later connectivity.

• Connecting networks broadly without segmentation. Hybrid reachability should not create one flat enterprise network.

• Treating hub-spoke as only a diagram. It is an operating model for shared services, ownership, routes, DNS, and inspection.

• Choosing ExpressRoute or VPN without matching requirements. Connectivity type should follow business and technical needs.

• Forgetting private DNS for private endpoints. The private endpoint path depends on name resolution.

• Sending all traffic through central inspection without planning resilience and scale. Central controls need production-grade operations.

• Letting platform networking become a bottleneck. Shared foundations should enable workload teams, not freeze delivery.

• Troubleshooting in only one layer. Hybrid network issues often involve routes, NSGs, DNS, firewall rules, and service settings together.

If Someone Asks You

If someone asks, "How would you design Azure networking for a hybrid enterprise migration?" a clear answer is:

I would use a hub-spoke network model. The hub VNet would hold shared hybrid connectivity, routing, inspection, DNS support, and platform-owned network services. Workload applications would run in separate spoke VNets, with production and non-production separated where risk and operations require it. Subnets would separate application tiers and private endpoints. NSGs would allow only required traffic paths, while route tables would send selected traffic through central inspection and hybrid gateways. VPN could support early or smaller connectivity needs, while ExpressRoute would fit private, predictable enterprise connectivity when justified. Private endpoints and private DNS would support private access to Azure platform services.

This answer shows how the controls work together instead of listing them separately.

What You Should Remember

Hybrid migration networking is responsibility placement for communication paths.

The most important idea is this:

Hybrid migration networking should make required paths clear and unnecessary paths hard to create accidentally.

A strong design uses hub-spoke structure, planned address spaces, controlled routing, segmentation, hybrid connectivity, private endpoints, DNS, and clear ownership to help workloads move safely into Azure.

Questions to Check Your Understanding

1. Why is hub-spoke design useful in a hybrid enterprise migration?

2. Which decisions should be made before connecting Azure to on-premises networks?

3. How do NSGs and route tables play different roles in the design?

4. When might VPN be enough, and when might ExpressRoute be justified?

5. Why do private endpoints require DNS planning?

6. How can central networking and workload autonomy coexist?