Migrating Enterprise Applications to Azure

Executive Summary

Contoso business context: Contoso is preparing to migrate business-critical applications from its datacenter to Azure while retaining selected legacy integrations on-premises. Application ownership, shared databases, file transfers and scheduled jobs must be verified before the production cutover sequence can be approved.

Moving applications to Azure involves more than provisioning target infrastructure. Application dependencies, data flows, identity, certificates, batch schedules, and operational responsibilities all affect the migration path and the safety of a production cutover.

This case study sets out Tongtech’s production migration design for Contoso, including workload-level migration decisions, Azure landing-zone readiness, controlled cutover and operational acceptance.

The objective is to move workloads with a controlled risk profile while creating opportunities to modernize where the application and business case support it. A full rewrite is not a prerequisite for moving to Azure.

Client naming: Contoso is a generic name used to protect business identity. The architecture and implementation details below form a realistic production delivery design; customer-specific deployment evidence and measured results are not included.

The Challenge

Enterprise portfolios commonly contain applications with incomplete documentation and dependencies that cross infrastructure and team boundaries:

• Application ownership, runtime versions, and support status are unclear.
• Services depend on shared databases, file shares, identity systems, or scheduled jobs.
• Network flows and external integrations are not fully documented.
• Certificates, DNS records, firewall rules, and service accounts have accumulated over time.
• Some applications require low latency or continuous connectivity to systems that remain on-premises.
• Production data migration and cutover windows have limited tolerance for disruption.
• Target environments do not yet have consistent network, identity, policy, backup, or monitoring controls.
• Teams lack a repeatable way to test migration waves and return safely to the source environment.

The organization needs a migration plan that accounts for the whole workload and its operating model, rather than treating each server as an isolated move.

Objectives

The migration approach is designed to:

1. Establish application ownership, business criticality, dependencies, and technical constraints.
2. Select a migration strategy for each workload based on evidence and target-state needs.
3. Prepare Azure landing-zone controls and hybrid connectivity before application cutovers.
4. Sequence migration waves around dependency boundaries and business calendars.
5. Automate repeatable infrastructure and deployment steps through Infrastructure as Code and pipelines.
6. Validate functionality, security, performance, data integrity, and recovery in a representative target environment.
7. Define cutover, rollback, and operational handover responsibilities before production change windows.

Discovery and Assessment

Assessment combines application knowledge with infrastructure and dependency evidence. The inventory records owners, business function, criticality, service hours, recovery requirements, data classification, runtime, hosting components, and planned disposition.

Discovery reviews:

• inbound and outbound network flows, including DNS names and ports
• application, database, storage, and identity dependencies
• certificates, secrets, service accounts, and authentication flows
• scheduled jobs, queues, file transfers, and external integrations
• data volumes, change rates, retention, and consistency requirements
• performance patterns, peak periods, latency sensitivity, and capacity
• backup, restore, disaster recovery, patching, and monitoring requirements
• licensing, support lifecycle, and application vendor constraints

Automated inventory and dependency tools can help build the picture, but application owners and operators confirm business context and undocumented behaviors. Findings, assumptions, and unresolved dependencies are recorded so that migration waves can account for uncertainty explicitly.

Migration Strategy

The strategy is selected for each application or component. Related components may follow different paths when that reduces risk and supports a practical modernization sequence.

This initial triage view helps teams discuss a suitable disposition. It is not a mandatory sequence, and application components may take different paths.

The classification is revisited as discovery improves. A rehost can be a deliberate first step when it reduces immediate risk, with later modernization handled as a separate, funded change.

Azure Readiness and Target Architecture

Before migration waves enter production, the target environment is prepared through the organization’s Azure landing-zone model. This includes subscription ownership, identity and RBAC, network and DNS design, security policies, diagnostic settings, monitoring, backup requirements, and cost allocation.

Hybrid connectivity is designed around the applications that will coexist across Azure and the source environment. Routes, name resolution, firewall rules, identity paths, and dependencies are validated from the actual target workload context. Temporary migration access is tracked and removed or converted into an approved steady-state path after cutover.

Target hosting is selected according to the application’s runtime and operating needs:

• Azure Virtual Machines support workloads that need operating-system control or cannot yet use a managed runtime.
• Azure App Service can host compatible web applications with less server administration.
• Azure Container Apps or AKS can fit containerized workloads when their scaling, runtime, or platform requirements justify them.
• Azure SQL and other managed data platforms can reduce database administration when compatibility and migration constraints allow.
• Azure Storage provides managed storage patterns selected around access, durability, lifecycle, and network requirements.
• Azure Key Vault and managed identity help avoid embedding credentials in applications and deployment workflows.

The target design also defines ingress, private connectivity, data protection, availability zones or regional recovery where required, and the operational teams responsible for each shared service.

Migration Execution

Migration waves group workloads by dependency, business criticality, technical readiness, and change-window constraints. A representative workflow is:

Infrastructure is provisioned through Terraform or Bicep where practical, and repeatable application configuration is managed through controlled deployment pipelines. Data movement is selected for the source platform, data volume, consistency needs, and allowable outage. Rehearsals help expose duration, access, and sequencing issues before the production window.

Each cutover plan identifies decision-makers, validation steps, communication owners, data synchronization points, expected service behavior, rollback triggers, and the actions needed to restore or redirect traffic. Rollback feasibility is confirmed against data writes and configuration changes; it is not assumed to be a simple switch after production data has changed.

Operational Transition

The migrated workload is accepted into operations only after ownership and support procedures are clear. Azure Monitor, Application Insights, and Log Analytics provide workload and platform telemetry appropriate to the service. Alerts are connected to named responders and actionable runbooks.

Operational readiness also covers backup configuration and restore testing, patching responsibility, access review, certificate and secret lifecycle, capacity review, cost visibility, service health, and disaster-recovery objectives. Azure Site Recovery or another recovery method is used only where it fits the workload’s recovery requirements and is validated through exercises.

The handover includes architecture and dependency records, deployment instructions, monitoring dashboards, incident procedures, known limitations, support contacts, and a list of any temporary migration controls that remain to be removed.

Implementation Sequence

1. Portfolio Discovery

Build and validate the application inventory, confirm business and technical ownership, map dependencies, and identify workload constraints, risk, and unknowns.

2. Strategy and Wave Planning

Assign a migration disposition to each workload. Group related components into waves and define sequencing, readiness criteria, change windows, and rollback needs.

3. Landing-Zone and Connectivity Readiness

Confirm subscription, network, DNS, identity, security, policy, monitoring, backup, and hybrid connectivity patterns for the workloads in scope.

4. Target Build and Rehearsal

Provision environments through IaC, configure application and data migration steps, and rehearse validation and cutover in non-production.

5. Production Migration

Execute each approved wave using the documented change plan. Verify application behavior and business acceptance before moving into steady-state support.

6. Stabilization and Handover

Monitor the service, resolve migration issues, complete operational documentation, remove temporary access, and close or re-plan outstanding dependencies.

Delivery Artifacts

The production delivery scope includes:

• application inventory, owner map, and dependency assessment
• migration disposition and wave plan
• Azure landing-zone and hybrid-connectivity readiness assessment
• target architecture and workload decision records
• Infrastructure as Code and environment configuration
• data migration, test, cutover, and rollback plans
• application validation and performance-test approach
• Azure Monitor and Application Insights configuration
• backup and recovery design with validation records
• operations runbooks, support ownership, and handover documentation

Contoso Production Context and Architecture Decision Record

Contoso operates customer and internal business applications in a privately connected datacenter. A typical migration unit contains a web tier, background schedulers, an application database, file exchange, directory authentication, and integrations with systems remaining on-premises. Migration planning groups these dependencies into a business service; moving one virtual machine independently would leave an incomplete service boundary.

Architectural decision: Use an established Azure landing-zone subscription with segmented spokes, centralized routing and DNS, workload-specific least-privilege access, managed services only after compatibility testing, and repeatable Terraform/Bicep deployments. A time-bound hybrid coexistence stage remains part of the production design. The chosen migration method is documented per application rather than applying one hosting target to the entire estate.

Network, Identity, and Subscription Topology

Reference address allocation (to be confirmed against customer IPAM): production spoke 10.42.0.0/16; application subnet 10.42.10.0/24; private-endpoint subnet 10.42.20.0/24; integration subnet 10.42.30.0/24. The address plan must pass overlap checks against Contoso's existing on-premises estate, acquired networks, future spokes and any transit ranges. Avoid a route-table design that accidentally blackholes gateway, DNS or private endpoint traffic; verify effective routes on each relevant network interface.

Private endpoint connectivity requires three independent tests: the endpoint connection is approved, name resolution returns an expected private address from the actual application host, and the TCP/application handshake works along an allowed path. DNS zone links are not a substitute for a tested hybrid forwarding chain. Public network access is disabled only after traffic and operational access paths are confirmed.

Workload Disposition and Migration-Wave Design

A wave contains an application manifest: service ID, executive/business owner, technical owner, dependencies, change ticket, RTO/RPO target, data synchronization plan, acceptance scripts, rollback point of no return, and post-cutover support coverage. Migration waves are dependency graphs, not simply server counts.

Low-Level Implementation Blueprint

Discovery Artifacts and Dependency Evidence

1. Collect supported inventory with Azure Migrate and cross-check CPU/memory utilization, storage IOPS, operating-system version, SQL features and network dependencies against monitoring and configuration records.
2. Interview application owners about scheduled business events, certificates, service accounts, external APIs, batch jobs and hard-coded IP/DNS references that infrastructure discovery may miss.
3. Capture flow-level dependencies with source/destination, protocol/port, DNS name, direction, owner and migration disposition. Document unknown flows for investigation, not implicit firewall allow rules.
4. Record a bill of materials for each target workload, including expected region, SKU, zones if applicable, storage class, backup policy, monitoring destinations and the estimated network egress profile.
5. Establish application-level pass/fail tests: login, core transaction, report generation, scheduled job, upstream/downstream integration, database consistency and end-user access.

Environment Build and Data Cutover

A platform pipeline first applies resource groups, subnets, route tables, security groups, identities, Key Vault, monitoring resources and required private endpoints. An application pipeline then deploys the application runtime and releases configuration from approved stores. Terraform state is separated by environment and lifecycle boundary, stored in protected Azure Storage with Azure AD authorization, soft delete/version protection where supported, controlled backend network access and audited administrative recovery.

For VM rehosting, validate replication and failover prerequisites, source disk consistency, guest health and Azure VM post-failover configuration before assigning a production window. For databases, establish schema compatibility, use the supported online/offline migration technique, rehearse catch-up and synchronization, and explicitly measure whether replication lag fits the allowed outage. A source/database write-freeze or controlled dual-write strategy must be selected; a DNS switch alone does not solve divergent data writes.

DNS TTL reduction is scheduled sufficiently ahead of the change window, and client caching behavior is included in the plan. The cutover log records UTC timestamps, operator, command/change reference, observed result and rollback decision. Rollback remains possible only while its data-consistency assumptions hold; after new production writes, recovery may require forward remediation or separately rehearsed data reconciliation.

Operational Resilience and Security

• Configure workload-appropriate backup, retention, soft-delete/protection and restore access; demonstrate file and database restoration rather than equating backup configuration with recoverability.
• Validate RTO/RPO against recovery exercises. Zone deployment, secondary-region replication and Azure Site Recovery are workload-specific options, not universal guarantees.
• Enable required Azure Activity Logs, resource diagnostics, guest telemetry and application dependency tracing, with retention and cost budgets set by data class and operating requirements.
• Remove temporary firewall openings, agent permissions, migration principals and staging secrets during stabilization; compare the post-cutover network rule inventory against the approved steady state.
• Verify application identity, service principals or managed identity, certificate rollover, Key Vault access, data encryption and production RBAC with negative-permission tests.

Cutover Go/No-Go and Acceptance Evidence

Acceptance uses actual evidence attached to the release record; merely provisioning a target VM or PaaS service does not satisfy production migration.

Outcome

The result is a migration process that gives application owners a clearer view of scope, dependencies, target choices, and operational responsibilities. Workloads can move in controlled waves, with Azure foundations and cutover procedures prepared around their actual needs.

This production architecture is intended to reduce avoidable migration risk and establish a supportable Azure operating model. Customer-specific numerical improvements must be supported by operational evidence.

Before and After Implementation: Migration and Operating Outcomes

The table contrasts the documented baseline challenges with the specified target operating state. It is not a set of independently measured customer outcomes.

Evidence to collect: percentage of workloads with owner/dependency manifest, cutover duration against planned window, number of unresolved integration defects, rollback invocation rate, restoration test results and 30-day post-cutover incident trend. Populate values only from actual release and operating records.

Why This Migration Approach Works

Discovery identifies the dependencies behind each application.

Migration strategy follows workload needs and constraints.

Landing-zone readiness is handled before production cutover.

Rehearsal, validation, and rollback planning are part of each wave.

Operational ownership is established before the project hands over.

The result is a practical path from current hosting to Azure that supports immediate migration needs and deliberate modernization over time.

Technologies

Microsoft Azure · Azure Migrate · Azure Virtual Machines · Azure App Service · Azure Container Apps · Azure Kubernetes Service · Azure SQL · Azure Storage · Azure Key Vault · Microsoft Entra ID · Azure Monitor · Application Insights · Log Analytics · Terraform / Bicep · Azure Site Recovery

Related Patterns

• Workload migration guide
• Multi-cloud operating patterns