.NET development

The Microsoft stack is where most of this team came from and where the majority of our delivered systems run. That matters for two reasons that have nothing to do with preference: enterprises already have the licences, the Active Directory and the SQL Server, and .NET has a support lifecycle you can put in a risk register. We build new systems in ASP.NET Core, keep older ASP.NET MVC estates alive and moving, and — the job nobody advertises — carry .NET Framework applications forward onto a supported runtime without a rewrite. Portside Insurance came off .NET Framework 4.6.2 onto .NET 8 in eleven weeks with no functional change and a 3.4× throughput improvement on their quoting endpoint.

• 01

  A version-support story you can hand to an auditor: we target the current long-term-support release and tell you the month your runtime falls out of support.

• 02

  Fits the estate you already own — Active Directory or Entra ID for identity, SQL Server for data, Azure for hosting — instead of adding a parallel stack to operate.

• 03

  Framework-to-Core upgrades done incrementally behind a routing layer, so the application stays in production throughout rather than going dark for a quarter.

• 04

  APIs designed as products: versioned, documented with OpenAPI, and contract-tested so a consumer finds out at build time rather than in production.

• 05

  Microservices only where the seam is real. Most systems we are asked to split should stay a well-structured single deployment, and we will say so.

1. 01

   Codebase and runtime survey

   For existing estates: target framework, dependency graph, dead packages, test coverage and the specific APIs that block an upgrade. The output names each blocker and what it costs to clear.

2. 02

   Architecture and boundaries

   Project structure, layering, where the transaction boundary sits, and which parts genuinely warrant separate deployment. We write this down as decision records, because the alternative is relitigating it in month six.

3. 03

   Build or migrate

   New systems build in vertical slices. Existing ones move project by project — shared libraries first, then the web layer — with both versions building side by side until the last one crosses.

4. 04

   Performance and hardening

   Load-test against realistic data volumes, fix what the profiler actually finds rather than what looks slow, and close out the security review before release rather than after.

• A .NET solution on a current long-term-support runtime, building in CI on a clean agent.
• OpenAPI specification for every public endpoint, generated from the code so it cannot drift.
• Integration and contract test suites, plus a load-test script and its baseline results.
• Upgrade record for migrations: what moved, in what order, and what was deliberately left behind.
• Deployment pipeline to Azure App Service, container apps or IIS, whichever fits your operations.
• Architecture decision records, in-repo and in plain English.

• 01We are on .NET Framework 4.x. Do we have to rewrite?

  Almost never. Most of these applications move onto a modern runtime incrementally — retarget the class libraries, replace the framework-only dependencies, then move the web layer behind a routing shim so both versions serve traffic during the transition. A rewrite is warranted when the data model is the problem, not the runtime, and that is a different project with a different justification.

• 02Should we break this into microservices?

  Probably not yet. A well-structured single deployment with clear internal boundaries is faster to change and far cheaper to operate than six services with a distributed transaction between them. We split when a component has a genuinely different scaling profile, release cadence or ownership — and we make the internal boundary clean first, because that is the hard part either way.

• 03Can you work alongside our in-house .NET team?

  That is the normal arrangement. We work in your repository, on your branch conventions, in your review process. Where we are brought in for capability rather than capacity, we pair deliberately so the pattern stays after we go.

• CSD

  Custom software development

  Business systems built for how your operation actually runs, when the off-the-shelf product would need bending until it breaks.

  /services/custom-software-development
• CLD

  Cloud and Azure solutions

  Cloud-native applications, migrations and the infrastructure underneath them — with the bill and the recovery plan designed in.

  /services/cloud-azure-solutions
• DBS

  Database solutions

  Design, migration, performance and recovery — mostly SQL Server, and mostly for systems whose data has outgrown its original design.

  /services/database-solutions