Migration from Public Azure Cloud to Private Azure Cloud

Project Overview

Client Industry: Financial Services (Digital Payments Platform) Existing Environment: Microsoft Azure Public Cloud Target Environment: Azure Private Cloud using Azure Stack HCI

The client initially hosted its infrastructure on Microsoft Azure Public Cloud for rapid scalability and global access. However, due to regulatory requirements and data sovereignty concerns, the organization decided to migrate critical workloads to a private Azure-based cloud environment running inside their own datacenters.

The goal was to maintain Azure-compatible services while keeping sensitive workloads within private infrastructure. The migration involved:

• 85 Virtual Machines
• 12 business-critical applications
• 4 SQL Server clusters
• 30 TB of application and database data

Business Drivers for Migration

1. Regulatory Compliance

Financial regulatory bodies required:

• Sensitive payment data to remain within controlled infrastructure
• Strict auditability and internal network isolation

Public cloud multi-tenant environments were considered higher risk for regulatory audits.

2. Data Sovereignty

Customer financial data needed to remain within specific geographic boundaries.

3. Predictable Cost Model

The public cloud usage model resulted in:

• Unpredictable monthly bills
• High egress costs
• Expensive compute scaling

A private cloud enabled fixed infrastructure costs.

4. Security and Control

The organization wanted:

• Full control over networking
• Internal security monitoring
• Custom firewall and network segmentation

5. Legacy Application Constraints

Some internal banking systems required:

• Low latency connections
• Dedicated hardware
• Custom compliance configurations

These were easier to manage in private infrastructure.

Why Hybrid Cloud Was Not Selected

Although hybrid architecture was evaluated, the client rejected it for the following reasons: | Reason | Explanation | | ———————- | ————————————————————— | | Compliance risk | Hybrid architectures still involve data flowing to public cloud | | Operational complexity | Managing two environments increased operational overhead | | Security policy | Internal governance mandated full internal control | | Network latency | Payment processing required predictable latency |

Therefore, the architecture chosen was private Azure cloud only.

Existing Architecture (Before Migration)

Public Cloud Architecture:

Components included:

• Azure Virtual Machines
• Azure Virtual Network
• Azure SQL Database
• Azure Storage Accounts
• Azure Load Balancers
• Azure Active Directory

Architecture Challenges:

• Public endpoints exposed to internet
• Limited network isolation
• Expensive compute costs during peak traffic
• Compliance audit difficulties

Target Architecture (Private Azure Cloud)

The target environment used Azure Stack HCI deployed in two private datacenters.

Key Components:

• Hyperconverged infrastructure cluster
• Private software-defined networking
• Local storage pools
• Private Active Directory integration
• Disaster recovery replication between datacenters

Architecture Layers:

Infrastructure Layer

• 8-node Azure Stack HCI cluster
• NVMe-based storage
• 25Gb network backbone

Compute Layer

• Private cloud VMs running Windows Server
• Kubernetes workloads for microservices

Network Layer

• Segmented VLAN architecture
• Internal load balancing
• Private API gateways

Security Layer

• Zero-trust network policies
• Internal SIEM monitoring
• Endpoint security scanning

Migration Strategy

A phased migration approach was used to minimize risk.

Phase 1 – Discovery & Assessment

Tools used:

• Azure Migrate
• Dependency Mapping
• Performance monitoring tools

Key tasks:

• Inventory of all workloads
• Application dependency analysis
• Performance baseline capture
• Migration wave planning

Phase 2 – Private Cloud Deployment

Infrastructure setup included:

• Installation of Azure Stack HCI cluster
• Network segmentation design
• Storage configuration
• Security hardening

This environment was designed to replicate Azure architecture patterns.

Phase 3 – Workload Migration

Migration techniques used:

Workload Type	Migration Method
Virtual Machines	Lift-and-shift replication
Databases	Backup & restore migration
Applications	Containerization where possible

Migration waves:

• Wave 1: Non-production systems
• Wave 2: Internal applications
• Wave 3: Customer-facing payment systems

Downtime was minimized using replication and staged cutover.

Key Challenges

1. Application Dependencies

Several applications had undocumented dependencies.

Solution:

• Used dependency mapping tools
• Created migration dependency groups.

2. Data Synchronization

30 TB of data required migration.

Solution:

• Incremental data replication
• Final cutover synchronization window.

3. Network Reconfiguration

Public cloud networking had to be redesigned.

Solution:

• Created private subnet architecture
• Implemented micro-segmentation.

4. Security Hardening

Private cloud required internal security monitoring.

Solution:

• Implemented SIEM logging
• Created security policies and firewall rules.

Results and Outcomes

After migration, the organization achieved:

Performance Improvements

• 25% lower latency for internal systems
• Faster database response times

Security Improvements

• Sensitive data remained within controlled infrastructure
• Improved compliance audit results

Cost Optimization

• 30% reduction in infrastructure cost after 12 months
• Eliminated unpredictable cloud billing

Operational Control

• Full infrastructure visibility
• Internal network monitoring and logging

Lessons Learned

• Migration assessment is critical to avoid dependency issues.
• Phased migrations reduce downtime risk.
• Private cloud requires strong internal monitoring tools.
• Cost modeling should include hardware lifecycle planning.