CODE PATH
Reduce avoidable allocation
Use StringBuilder where repeated concatenation creates unnecessary string objects.
PROFESSIONAL CASE STUDY / AZURE MODERNIZATION
Six applications.
Modernized for Azure.
Moving a monolithic application into Azure does not make it modern. It makes it a monolith running somewhere else. This engagement treated infrastructure, application behavior and operational readiness as one connected system.
Read the key decisions Download case study brief PDF · 1 page- My contribution
- Architecture through operation. Application migration, pipelines, monitoring, disaster recovery, auditing and cross-team coordination.
- Inherited environment
- Hybrid on-premises, cloud and legacy hosting · IIS · ASP.NET · application-services tier · SQL database tier
- Delivery scope
- 6 applications across approximately 18–21 services and 4–6 environments, meeting target release dates.
01 / THE INHERITED ESTATE
A hybrid environment.
A tightly coupled application.
Three hosting worlds
The starting point combined on-premises infrastructure, cloud resources and legacy hosting. Each application depended on an IIS-hosted ASP.NET web tier, a separate application-services tier, SQL database servers, established deployment processes and application-specific configuration.
The applications shared a recognizable pattern, but they were not six identical workloads. Each carried its own dependencies, performance characteristics and migration risks.
The hardest constraint lived inside the software
The application architecture was heavily monolithic and had accumulated performance debt. Tight coupling made individual capabilities harder to deploy, scale and recover independently, while inefficient code and caching patterns consumed more resources than necessary.
Adding compute could mask some symptoms. It could not remove their causes.
The modernization path
The migration moved through four connected layers. Application diagnosis and operational design were part of the path—not activities deferred until after infrastructure delivery.
INHERITED ESTATE
On-premisesCloudLegacy hosting
MONOLITHIC IIS / ASP.NET APPLICATIONS
Web tierIIS-hosted ASP.NETApplication-services tierTightly coupled business capabilitiesData tierSQL database servers
CONNECTED MODERNIZATION WORK
ArchitecturePipelinesMonitoringDRAuditCoordination
AZURE OPERATING MODEL
6 applicationsMigrated and modernizedTargeted code changesMemory and cache behaviorRepeatable deliveryPipelines and environment consistencyOperational readinessMonitoring, recovery and audit
02 / CONSTRAINTS & DECISIONS
Treat the migration
as one system.
| Constraint | My response | Why it mattered |
|---|---|---|
| Dependencies crossed on-premises, cloud and legacy hosting. | Audit applications and dependencies before sequencing the move. | Architecture and timing reflected the system that actually existed, not only its documentation. |
| The IIS applications were monolithic and unoptimized. | Diagnose application behavior and apply focused code and caching improvements alongside platform work. | Infrastructure did not become the automatic answer to application-level performance problems. |
| Six applications spanned many services and environments. | Own target architecture, application migration and delivery pipelines as a connected program. | Application and platform changes remained aligned across each release. |
| A successful cutover still needed to be operable. | Include monitoring, audit and RTO/RPO-aligned disaster recovery in the migration scope. | Visibility and recoverability became design concerns rather than post-migration paperwork. |
| Knowledge was distributed across technical teams. | Coordinate architecture, dependencies, readiness and migration timing across the people who owned each layer. | Decisions stayed connected when responsibility crossed application, infrastructure and data boundaries. |
03 / PLATFORM ARCHITECTURE
Build around
how the applications operate.
Architecture beyond the hosting target
I worked across Azure architecture, application migration and environment consistency rather than treating each as a separate handoff. The wider program involved services such as App Services, virtual machines, virtual networks, Key Vault, Storage Accounts, Azure SQL, SQL Managed Instance, Private Endpoints, Azure Functions, Azure AD, Logic Apps, gateways and Log Analytics.
Not every application used every service. The point was to choose the right boundary for each workload while keeping identity, networking, configuration and operations visible.
Delivery as part of the platform
I implemented Azure DevOps and Jenkins-based CI/CD workflows that connected source control, automated testing, code scanning, release automation and GitOps practices. For a complex legacy estate, repeatability in the delivery path reduced uncertainty the applications already had enough of.
A migration is not complete because an application starts once. It needs a path for the next safe change.
- Application hosting
- Identity and secrets
- Private networking
- Data services
- Infrastructure automation
- Delivery pipelines
- Application monitoring
- Recovery planning
04 / APPLICATION MODERNIZATION
Diagnose before
adding capacity.
Targeted changes, not a fictional rewrite
This was not a complete cloud-native rewrite, and I would not describe it as one. The practical objective was to move business applications safely while making focused improvements that increased performance and stability without introducing the cost and delivery risk of rebuilding everything at once.
Common patterns with real operational consequences
I traced behavior across code, caching and the surrounding platform. That work included using StringBuilder where repeated string manipulation created avoidable allocations, tuning application caching and implementing Redis for shared cache use cases.
Three places to look before scaling compute
This is a qualitative engineering map, not a benchmark chart. No latency or memory-reduction percentages are claimed for the engagement.
CACHE BEHAVIOR
Keep hot data intentional
Tune cache use and introduce Redis where shared application access benefits from it.
PLATFORM SIGNALS
Diagnose the whole path
Use monitoring to separate application symptoms from hosting, network and data-tier causes.
Combined effect Better application performance and stability through targeted diagnosis and modernization.
05 / OPERATING THE PLATFORM
Visibility and recovery
belong in the design.
MONITORING
Understand application behavior
Monitoring supported both migration readiness and diagnosis. The work included a self-hosted Dynatrace Managed Cluster in Azure, network security and traffic controls, synthetic transactions, dashboards, alerting and APM integration.
DISASTER RECOVERY
Design the recovery path
I designed, tested, documented and implemented disaster recovery procedures aligned with recovery-time and data-loss objectives. Dependencies and recovery sequence changed with the target architecture, so DR stayed inside the migration plan.
AUDIT + COORDINATION
Keep the system connected
Application and dependency auditing established what needed to move. Ongoing coordination kept architecture, data, delivery, operations and release timing aligned across the teams responsible for them.
06 / OUTCOME
Applications moved.
Operations strengthened.
6
Applications
Migration and modernization work spanned six enterprise applications.
18–21
Services
Planning and execution coordinated approximately 18–21 supporting services.
4–6
Environments
The program managed application delivery across approximately 4–6 environments.
100%
Target release dates
The application migrations met their target release dates.
The technical outcome extended beyond relocation: application performance and stability improved through diagnosis, targeted code changes, cache tuning and Redis, while pipelines, monitoring, audit and disaster recovery strengthened the operating model. Performance gains are described qualitatively because no benchmark percentage is claimed here.
07 / WHAT I WOULD CHANGE
Create more room
for application change.
If I approached the same environment again, I would allocate more time to modernization inside the codebase before and during migration.
I would evaluate suitable capabilities for extraction into Azure Functions so discrete, event-driven or independently executable work could be deployed and scaled with clearer boundaries. I would not move every method into a function merely to claim a serverless architecture; the boundary would need to make architectural and operational sense.
I would also audit, remove and deliberately upgrade NuGet packages, then update the surrounding application code and tests. Carrying fewer unnecessary or outdated dependencies into the target environment would reduce technical debt and create a cleaner foundation for later decomposition.
THE LARGER LESSON
Cloud migration and application modernization are different activities.
They can happen together, but one does not guarantee the other. Changing the hosting platform without examining the application can simply relocate the same limitations.
The best result came from treating infrastructure, software and operations as one system: diagnose before adding capacity, make targeted improvements where they matter, and include delivery, visibility and recovery in the architecture from the beginning.
Next: Designing Azure Platform Boundaries with TerraformLET’S TALK
Bring me the
interesting problems.
I’m looking for Senior DevOps and Platform Engineering opportunities where I can modernize Azure delivery, improve reliability and help teams operate complex systems with confidence.
APPLY THE APPROACH TO YOUR ENVIRONMENT
Infrastructure Alchemy
Start with a scoped review of Azure infrastructure and Terraform architecture.
Separate consulting assessment. The evidence and limitations above remain specific to the original project or demonstration.
Email WitchOps Explore the assessment ↗