Inside a platform rescue task force
C# / .NETTemporalAWS + KubernetesGitHub ActionsOpenTelemetry
The client's identity, and the technical detail of their platform, are withheld under contract. This writeup describes my role and my reasoning only — not the client's architecture.
The engagement
I was recruited in January 2026 into a small, hand-picked task force assembled to rescue a high-traffic consumer platform that had outgrown its original backend.
The shape of the problem is familiar to anyone who has done rescue engineering: a system that grew faster than anyone had designed it for, and a business that needs it to keep serving traffic while it is replaced. My remit was the backend rewrite — taking business-critical services off the legacy stack and onto .NET, one at a time, without a break in service.
I can’t write about how their platform is built. What I can write about is the judgement the work required.
Why a progressive rewrite
A big-bang rewrite of a live consumer platform is how you lose the business that pays for it. Every incentive pushes the other way — the legacy code is unpleasant, the new design is clean, and a clean-sheet rewrite always looks faster on a whiteboard than it turns out to be. It is almost always the wrong call.
The alternative is slower and much duller: build the foundations first, prove them on something small, then replace the estate service by service with the old and new systems running side by side. It costs more up front and it is harder to sell. It is also the only version that reliably survives contact with production traffic.
Why Temporal
Most of the services I took on were long-running, multi-step processes where a crash mid-flight must never leave the system in a half-finished state — the class of problem people usually solve with a queue, a status column and a pile of reconciliation code that grows forever.
Temporal is a better fit for that shape of work. Workflows are deterministic and resumable: the execution history is the source of truth, a worker can die and another picks up exactly where it left off, and retries and timeouts stop being application code. The cost is a real learning curve and a new piece of infrastructure to operate, which is worth paying when the alternative is hand-rolling the same guarantees badly.
Observability first
The rule I’d carry into any rescue engagement: instrument before you refactor.
Rescue engagements tend to begin with thin telemetry, and the temptation is to start fixing the things that are obviously wrong. The problem is that you then have no way to show that any of it worked, and “the rewrite made things better” becomes a matter of opinion — which is exactly the argument you lose six months in when someone asks what the money bought.
Tracing and structured logging went in ahead of the migration work, so every subsequent change could be measured rather than argued about.
Outcome
By the end of the engagement, half the legacy estate had been replaced with .NET services, and the platform’s stability under production traffic had improved markedly — measured, this time, not asserted.