Senior .NET Architecture, Rescue & Modernization
Most enterprise .NET systems don't need a rewrite. They need someone who can find the actual problem, stabilize the system, and modernize it in controllable steps.

Most enterprise .NET systems don't fail because the team chose the wrong framework. They fail because the system accumulated years of decisions that were correct at the time and are now expensive to change.
I work on those systems.
I'm an enterprise .NET architect and hands-on engineer with 28+ years of experience building, integrating, and repairing business-critical applications. I work with software vendors, consultancies, and engineering teams that need senior delivery capacity without adding a permanent hire.
What I get called for
Production rescue. An application fails under load, a background process stops draining, an integration silently drops messages, or a release introduces a defect that nobody can reproduce. The immediate goal is to restore service. The second goal is to understand why it happened so it does not happen again.
Legacy modernization. ASP.NET Web Forms, older .NET Framework applications, WCF services, and data layers that have outgrown their original design. The work is usually incremental: understand the system, stabilize it, then move the highest-value workflows to a modern stack without a big-bang rewrite.
Enterprise integration. C# and ASP.NET APIs, third-party systems, webhooks, data synchronization, and the unglamorous edge cases that decide whether an integration is reliable: retries, idempotency, ordering, timeouts, and failure visibility.
GenAI integration. Adding LLM capabilities to an existing .NET application where they solve a real problem, such as document extraction, classification, search, or controlled tool calling, rather than adding AI for its own sake.
How I approach a rescue
First, establish the actual symptom. "The system is slow" is not a symptom. "P95 latency on this endpoint rose from 180 ms to 4 seconds at 10:14, and the queue depth is climbing" is a symptom.
Second, preserve evidence before changing anything. Logs, metrics, traces, thread dumps, memory dumps, SQL Server wait statistics, execution plans, and the timeline of recent deployments and configuration changes. A restart can restore service and erase the evidence at the same time.
Third, form one falsifiable hypothesis and test it. "The thread pool is starved by blocking calls" can be proven or disproven. "It's probably the database" cannot.
Fourth, stabilize before fixing. A rollback, feature flag, scale-out, queue drain, or circuit breaker is not the fix. It buys the time needed to fix the cause without compounding the outage.
Finally, leave evidence behind: a regression test, an alert on the leading indicator, and a short written explanation of the failure mode.
How I approach modernization
I start with the workflows that actually carry revenue, not the parts of the codebase that are most unpleasant to read.
Then I put a boundary around one workflow, move that boundary to the new stack, and keep the old path running until the new path is boring. That sequence is slower on a slide and faster in production. It avoids the rewrite trap: eighteen months of work, a new UI, a new data model, and a long list of business rules that only existed in the old code.
Sometimes a rewrite is the right decision. But "the code is ugly" is not a business case. "This workflow costs us X and we can move it in a controlled sequence" is.
What an engagement looks like
- A paid diagnostic to establish the cause, the risk, and the smallest useful next step.
- A fixed-scope rescue with a defined outcome.
- An incremental modernization workstream inside an existing team.
- Additional senior capacity for a consultancy or software vendor that has more delivery work than bench.
I work remotely with overlap for US Eastern and UK hours. I'm comfortable operating inside an existing team, codebase, and release process.
What I need from you
Tell me the system, the symptom, the outcome you need, and the constraint you are working under. I'll tell you whether I can help and what a focused first engagement would look like.
If you are dealing with a .NET problem that has resisted a clean fix, send me a message.
This was published first as Dispatches from the Workshop.
Subscribe on LinkedIn