Most Sydney and Melbourne engineering teams running on legacy .NET aren't asking for a rewrite. They're asking for a way to stop losing a week every sprint to a codebase built around 2014, without signing off on a $250,000 replacement project that takes eighteen months and might not ship. Claude Code changes that calculation. It reads an existing .NET solution the way a senior engineer would on day one, and it can start doing reviewable, testable work inside that codebase within a week rather than after a quarter of discovery workshops.
Why the full rewrite rarely happens
Every CTO has sat through the pitch for a ground-up rewrite. On paper it's clean: new framework, new patterns, no more workarounds. In practice, Australian mid-market companies rarely approve it, and when they do, the project often stalls somewhere around month nine. The business logic buried in a fifteen-year-old .NET Framework solution turns out to be the actual specification for how the company runs, undocumented, tribal, and expensive to reproduce. Freezing feature work for a year to rebuild it is a hard sell to a board watching cash flow, especially for a business with $8 million to $40 million in revenue where engineering headcount is already tight.
So the system stays. New features get bolted on wherever there's room. Technical debt compounds quietly in the background, invisible on a roadmap slide but very visible in sprint velocity. And every new hire spends their first two months just working out what the code actually does before they can safely change any of it, which is a slow and expensive way to onboard senior engineers on a Melbourne salary.
There's also a quieter cost that rarely makes it into the business case: the opportunity cost of everything the team isn't building because they're afraid to touch the module that handles invoicing or stock reconciliation. Ask most engineering leads which parts of their .NET estate they'd rather not open, and you'll get an instant, specific answer. That fear is usually a documentation problem and a testing problem, not a reason to throw the whole system away.
Where Claude Code actually helps
This is the gap Claude Code is well suited to. Pointed at an existing .NET solution, it can read the full dependency graph, generate tests for behaviour that was never documented, and make targeted changes without requiring an engineer to hold the entire system in their head first. Teams we've worked with have used it for:
Mapping undocumented dependencies across a solution with 40+ projects, before anyone touches a line of code
Writing characterisation tests around a fragile module so a refactor has a safety net
Migrating a project at a time from .NET Framework to .NET 8, rather than the whole solution at once
Drafting migration runbooks and rollback plans for a change advisory board to approve
Refactoring a single service without breaking the six other services that call into it
None of that requires the business to stop shipping features while it happens. The migration work runs alongside the normal backlog, in small, reviewable pull requests, which is a very different risk profile to a big-bang cutover on a fixed date.
A staged plan that doesn't need a rewrite
The staged approach that tends to work starts small and deliberately boring. Pick one module, ideally one that's painful but not mission-critical, such as a reporting service or an internal admin tool. Run a scoped four to six week engagement where Claude Code, working under a developer's review, migrates and tests that module in isolation. A pilot like this typically runs $35,000 to $45,000 depending on scope, a fraction of a full rewrite budget, and it gives the business a real answer to the question that actually matters: does this hold up in our environment, with our data, under our compliance obligations.
If the pilot lands, the same pattern extends module by module. Nobody has to bet the roadmap on a single eighteen-month bet, and the legacy system keeps serving customers the entire time. Finance teams tend to like this shape too, because each stage is a small, bounded spend they can approve on its own merits rather than a single number that needs board sign-off up front.
What to guard against
None of this replaces engineering judgement. An agent working inside a production .NET estate needs the same guardrails you'd put around a new contractor, arguably tighter ones, particularly for businesses with obligations under the Privacy Act or, for regulated clients, APRA-aligned change management requirements.
Keep write access scoped to a feature branch, never directly to main or production config
Require human review on any change touching authentication, payments, or personal data
Run the existing test suite, plus any new characterisation tests, before every merge
Log agent-authored changes the same way you'd log a contractor's, with a name attached and a reason recorded
Treat the first module as a genuine trial, not a formality. Look closely at the pull requests, the test coverage they add, and how the team actually feels reviewing them week to week. If it holds up under that scrutiny on a low-stakes module, it's a reasonable bet on a more important one next.
Legacy .NET doesn't have to mean a frozen roadmap or a rewrite the business can't afford. If you're weighing up what a staged, Claude Code-assisted modernisation would look like for your systems, book a brainstorm and we'll walk through where to start.
