- The target architecture exists on a slide, but nobody can say what gets migrated first.
- Kubernetes, infrastructure as code and the pipelines work, but ownership is spread across teams and changes are slow or frightening.
- A migration is already in flight and the delivery dates have stopped being believable.
- Platform, security and delivery decisions are made late, then re-litigated in every team that has to live with them.
Service
Platform and cloud modernization
I help you settle the target architecture, the migration path and the delivery guardrails, then build the part where the risk actually sits.
When teams call
The situation this fits
Most engagements start with one of these, usually two of them at once.
How the work runs
Three phases, overlapping
The phases overlap. Decisions get revisited when the implementation disagrees with them.
-
01
Frame the situation
I spend the first two weeks reading code, pipelines, infrastructure and runbooks, and talking to the people who operate them. You get a short written picture of what is there, what is decaying, and what is blocking delivery.
-
02
Make the decisions
We settle the one or two decisions everything else hangs on and write them up as architecture decision records, with the trade-offs and the cost of being wrong. There are usually fewer of them than expected.
-
03
Deliver the risky part
I build the part where implementation risk is highest: the provider, the operator, the reconciliation job, the cutover. Close enough to production that code, not opinion, tests the architecture.
Deliverables
What you are left with
Written down and committed, in the repository the team already works in.
- A target architecture with a migration sequence, not a catalogue of options.
- Decision records the team can keep writing after the engagement ends.
- Infrastructure as code for the migration path, in Pulumi or Terraform, in the shape your team already maintains.
- A delivered first slice: provisioning, reconciliation, cutover or the platform component that unblocks the rest.
- Guardrails wired into the delivery path: policy checks, secret handling, supply-chain checks, observability.
- Knowledge transfer by pairing and short sessions, so the patterns survive the engagement.
Engagement shapes
Three ways to bring it in
The same work at different depths. Most engagements start with the first and continue into one of the others.
Short assessment
Two to three weeks. I deliver a written picture of the platform, the decisions in front of it, and a sequenced plan the team can execute.
Architecture lead
Part-time over three to six months. I hold the technical direction during a migration or restructure, including decision records and stakeholder alignment.
Hands-on delivery
Full-time through a delivery-critical phase. I do the architecture and the implementation while the risky part is built and shipped.
Evidence
What it looks like in practice
One anonymized reference from recent work.
Case study
Enterprise retail: a 600,000-user Microsoft-to-Google migration
Questions
Before a first conversation
The three questions I get asked first.
Is this a strategy engagement or a delivery engagement?
Usually neither in the pure form. I start with a small, concrete piece of the migration that has to work, and settle the architecture alongside it rather than before it.
Who writes the implementation?
I do, working with your engineers. The architecture gets tested by code, with the people who will maintain it in the room.
How does an engagement usually start?
Send a short note with the team context, the problem and the timing. I reply with the most sensible next step, which may be a short assessment, an architecture session or a scoped implementation engagement.
Start the conversation
Describe the platform and what is stuck
A short note with the context, the constraint and the timing is enough for me to say whether this is the right engagement.