Cloud Modernization Operating Model

Playbook. From two .NET-to-AWS programs across different companies.

Context

I have now been part of two large .NET-to-AWS modernizations, a decade apart and at different companies. The first was a public safety product suite onto AWS GovCloud, working alongside AWS ProServ - I led teams on the early planning and execution phase before leaving for a different role. The second is an on-prem-to-EKS migration of a .NET platform I am leading at my current employer.

The domains differ. The teams differ. The patterns repeat. This page is the operating model I would hand to anyone starting one.

The two programs

AWS GovCloud: public safety suite, 2018-2019. Multi-team program. Public safety customers operate under compliance regimes that are not optional - that is why GovCloud rather than commercial AWS. AWS ProServ partnered with us on the GovCloud-specific architecture: service availability, IAM, audit logging, encryption posture. My teams owned the application and data side. I led the early planning and execution phases before transitioning to my next role.

On-prem to EKS: insurance claims platform, current. Active program. .NET workloads from on-prem environments into containerized services on EKS. Different compliance posture from public safety, but similar appetite for risk: audited, mission-critical, unforgiving of careless changes.

Decisions that mattered, in both programs

What not to move

Every modernization program starts with someone wanting to rewrite something at the same time. Resist this. The point of a migration is to move the system you have. Rewrites come after, on their own schedule, when observability and rollback paths are in place. Doing both at once is the most common way these programs fail.

In the GovCloud program we kept an explicit list of things we were not going to change. The list was uncomfortable - there was code we all wanted to fix - but it kept the program scoped. Same discipline holds on the EKS migration: containers first, redesign later.

Sequencing is the actual work

The architecture diagram is the easy part. The hard part is the path between here and there. Which service moves first? What depends on it? What runs in both places during transition? What is the rollback if it does not work?

A sequence I trust:

1. Inventory dependencies and ownership. Find the modules nobody owns now - those are the ones that surface during cutover at the worst time.
2. Pick a candidate that is important enough to be a real test, but isolated enough that failure is not catastrophic.
3. Build the deployment, observability, and rollback path before migrating it.
4. Migrate. Run both versions. Verify.
5. Use the lessons to refine the path. Move the next candidate.

Observability before cutover

The single biggest mistake I have seen is migrating a service before there is enough observability in the new environment to debug it in production. If you cannot see latency, errors, and traffic in the new place at parity with the old, you cannot migrate. You cannot even tell whether the migration worked.

This is unglamorous work. It pays for itself the first time something goes wrong at 2am.

Deployment loop changes team behavior

The biggest improvement on the current EKS migration has not been Kubernetes itself - it has been getting deployment time from roughly 45 minutes down to under 10. That single change altered what the team is willing to ship on a Friday afternoon. Modernization programs that only think about architecture miss this. The deployment loop is the engineering culture.

Consulting partners are sounding boards, not delivery teams

AWS ProServ was useful in the GovCloud program because they had recent AWS expertise we did not. They were not useful as a substitute for our own application judgment. Teams that waste these engagements treat the partner as a delivery resource. Teams that get value treat them as a technical second opinion. Keep ownership inside.

Customer cutover is engineering work

Especially in regulated industries - public safety, healthcare, claims - the customer migration runbook is as much an engineering artifact as the architecture. Data verification scripts, rollback procedures, on-call coverage during cutover, decision criteria for abort and roll back. Treat these as deliverables, not afterthoughts.

What I would want someone to take away

Modernization is a sequencing problem more than a technology problem. The interesting decisions are about what to leave alone and for how long. Anyone can draw the target architecture; the operating model is in the path between here and there.

Spend more time on the path. Migrate the boring things first. Resist the urge to rewrite. Get observability in place before cutting anything over. Keep a written list of what you are explicitly not doing - it is the most useful document in the program.