Skip to content
Artrilogic
Pillar 02 · .NET modernisation

Modernisation works as a series of bridges, not a bonfire.

Specifically the .NET estate. Most legacy .NET workloads have more life in them than vendor upgrade messaging implies. We help Australian businesses decide what to keep, what to wrap, and what to retire. Then we ship the smallest useful uplift.

The feeling

Your stack is being labelled legacy by people who do not run it.

Vendors push upgrades. Auditors flag end-of-life timelines. The team that maintains it knows the truth, but is too busy keeping it running to argue.

The cost of doing nothing

Compliance, not capability, eventually forces the call.

And by then the budget is reactive, the timeline is fixed, and the project starts on the back foot. Earlier conversations cost less.

The calm offer

A phased plan, honest budget ranges, “wait” on the list.

We start with the smallest useful uplift. Most engagements preserve more of the existing estate than the customer expected.

What we do

.NET modernisation, delivered in slices the original platform survives.

We work end to end on .NET estates. Discovery, target architecture, phased delivery, and the operational handover that lets your team carry the codebase forward after we leave. Our default is to keep the original platform live throughout, modernise in slices, and preserve the parts of the system that are quietly earning their keep.

The pillar is deliberately .NET-focused. Microsoft Dynamics now sits in its own pillar at /microsoft-dynamics. AWS, Azure and cloud remediation work sits under /infrastructure. Most engagements touch one or both, and we hold them as one engagement when that is the right shape.

Our approach to delivery

Four phases. Honest checkpoints. The same posture across every pillar.

  1. Assessment

    A fixed-scope diagnostic. Two to three weeks. We read the estate, name the constraints, and surface the decisions you actually need to make. The deliverable is a written recommendation you could hand to another firm and they could execute against it.

  2. Scoping

    Once a path is chosen, we scope the first vertical slice tightly. Time-boxed phases, named exits, and a clear answer to "what does the smallest useful uplift look like." You can stop after phase one if the value is not there.

  3. Build

    Senior engineers who have shipped this work before. We work to your existing change processes, your security posture, and your operational posture. The architects you meet in scoping are the architects who deliver.

  4. DevOps practice, on GitHub

    Every engagement ships on a modern DevOps practice grounded in GitHub: branch protection, PR review, GitHub Actions for CI/CD, environment promotion, and audit trails your compliance team can defend. We do not run cowboy releases and we do not hand over a codebase your team cannot maintain.

Who would do the work

Sanjeev, Architect lead, Modernisation.

Senior architect with two decades on Australian .NET estates. Hands-on across legacy ASP.NET, WCF, WinForms, and current .NET. Specialises in phased modernisation that keeps the original platform live throughout. The architect you meet in scoping is the architect who delivers.

Common questions

What .NET leaders usually ask first.

We are on .NET Framework. Do we have to rebuild?

Almost never the right first move. Most .NET Framework estates have more life in them than vendor upgrade messaging implies. We start by reading what is actually carrying load and decide path-by-path whether to lift to current .NET, wrap with a modern facade, or retire entirely. The rebuild option exists, but it is rarely where we end up.

How long does a modernisation assessment take?

Two to three weeks of senior architect time. The deliverable is a written, dependency-mapped recommendation with cost ranges, a phased plan, and an honest 'wait' option where that is the right call. You can hand it to another firm and they could execute against it.

Can the platform stay live during the work?

Yes, and almost always should. Our default is phased delivery where the original platform stays in service throughout. Big-bang cutover is reserved for the rare cases where it is genuinely the safer call. We are explicit on the assessment about which one fits.

What about Microsoft Dynamics or our cloud estate?

Dynamics is now its own pillar at /microsoft-dynamics. Cloud remediation, AWS and Azure work sit under /infrastructure. Most modernisation engagements touch one or both. We hold them as one engagement when that is the right shape.

Honest second opinion

Already got a modernisation quote? Let us pressure-test it before you commit.

We will tell you what holds up, what does not, and where the smallest useful uplift is. No retainer required.