01 / 06
ASP.NET Core APIs
Typed, versioned HTTP APIs with generated OpenAPI descriptions, validation at the boundary, structured errors, and authentication that fits the identity system you already run.
SERVICE · .NET
.NET Engineering
A great deal of the business logic that actually runs companies is written in .NET, and a great deal of it was written a long time ago. We build new ASP.NET Core services, and we do the migration work that lets the existing ones keep earning while they move — incrementally, with the old and new paths running side by side until the last caller has switched.
THE PROBLEM
The system still works. That is exactly why nobody has touched it.
A .NET Framework application that has been running for a decade is usually running because it is load-bearing, and it has not been modernised because the risk of change is concentrated and the benefit is spread out. Meanwhile the cost accumulates in places that do not appear on any invoice: a Windows Server estate that must be patched, a deployment that needs a person and a printed checklist, business rules that exist only inside stored procedures, and a hiring problem that gets slightly worse each year. None of this is an argument for a rewrite. It is an argument for moving in slices, starting with the parts where the cost is highest and the risk is lowest.
Signals you might recognize
A .NET Framework application that nobody is willing to touch without a change window.
Business logic that exists only in stored procedures, with no test that describes it.
Deployments that require a named person, a checklist, and an evening.
A rewrite has been proposed at least once and cancelled at least once.
WHAT WE DELIVER
What this actually includes.
Concrete engineering capabilities deployed as part of this service practice.
02 / 06
Framework to Core migration
Incremental migration behind a routing layer, moving endpoints across a few at a time with both paths live. No cutover weekend, and a rollback that is one routing change rather than a restore.
03 / 06
Domain modelling
Pulling business rules out of stored procedures and controllers into a tested domain layer, so the behaviour is described somewhere a person can read and a test can check.
04 / 06
Microsoft SQL Server integration
Entity Framework Core or Dapper chosen per workload, migrations that run in the pipeline, and query work where the object-relational mapper is generating something expensive.
05 / 06
Background and scheduled processing
Hosted services, queues, and scheduled jobs with idempotent handlers, retry policy, dead-letter handling, and enough logging to tell what a failed run actually did before it failed.
06 / 06
Containerization and delivery
Building for Linux containers where it is possible, automated pipelines, health and readiness endpoints, and configuration through environment rather than machine-specific files.
HOW WE WORK
How we approach .NET Engineering.
Milestone-driven delivery, so integration problems surface in week two rather than in week ten.
01
Assess before proposing
We read the code, run it, and map what calls what. The output names the parts that are worth moving first, the parts that should be left alone, and the parts that should be deleted, with reasoning for each.
Stage 01 activities
- Dependency and framework-compatibility analysis
- Traffic and usage mapping against the endpoints that exist
- Data access inventory, including stored procedure logic
- A sequenced plan with the risk of each step stated
02
Put a boundary in front
A routing layer between callers and the application so traffic can be moved endpoint by endpoint. This is the change that turns a migration from one large risk into a series of small reversible ones.
Stage 02 activities
- Reverse proxy or gateway routing by path
- Shared authentication across old and new paths
- Request and response parity logging between implementations
- A rollback that is a routing change, tested before it is needed
03
Characterize before you change
Where behaviour is undocumented, we write tests that capture what the system currently does — including the parts that look like bugs. You cannot safely preserve behaviour you have not written down.
Stage 03 activities
- Characterization tests against current production behaviour
- Extraction of stored procedure logic into readable, tested code
- Explicit decisions about which existing quirks to keep
- Comparison runs against production traffic where feasible
04
Move in slices
Endpoints move a few at a time, each with its tests, monitoring, and a period running in parallel. The old implementation stays available until the new one has been quiet for long enough to trust.
Stage 04 activities
- Per-slice migration with parallel running
- Shadow traffic comparison before switching
- Metrics and alerting on each migrated path
- Decommissioning only once traffic is genuinely zero
05
Modernize the operations
Once the code has moved, the operational cost is next: containers, automated deployment, configuration through environment, and health endpoints that mean something. This is usually where the saving actually appears.
Stage 05 activities
- Linux container builds where the dependencies allow
- Automated deployment pipelines replacing manual checklists
- Structured logging and metrics wired to a real destination
- Runbooks for the operational tasks that remain
TECHNOLOGY DEPTH
Technologies behind .NET Engineering.
The libraries, runtimes, and services we standardise on for this work, and keep patched.
Frontend
- TypeScript
Backend
- .NET
Data
- Microsoft SQL Server
- PostgreSQL
- Redis
Cloud
- Docker
- Azure
- Kubernetes
DELIVERABLES & OUTCOMES
What you receive, and what actually changes.
We measure success by durable working software in your possession, not presentation slides.
What you get
An assessment naming what to migrate, what to leave, and what to delete
A routing boundary allowing endpoint-by-endpoint migration and rollback
Characterization tests describing current behaviour before it changes
ASP.NET Core services with generated OpenAPI descriptions
Container builds and automated deployment replacing manual release steps
Structured logging, metrics, and health endpoints on every migrated path
What changes
Migration as a sequence of reversible steps rather than one irreversible weekend
Business rules described in tested code instead of only in stored procedures
A release that does not need a named person and an evening
A supported runtime, and a hiring position that improves rather than worsens
QUESTIONS & ANSWERS
Questions about .NET Engineering.
Direct answers to common technical and engagement questions.
No, and usually you should not. Some components are stable, low-change, and cost almost nothing to leave where they are. The assessment separates those from the ones where the operational cost or the change friction is genuinely expensive, and the plan starts with the second group.
It depends almost entirely on how much of the logic sits in the data layer and how well the dependencies are supported, which is what the assessment measures. What we can say before that is the shape: value arrives from the first migrated slice, not at the end, because the routing boundary lets each slice go live on its own.
We extract it into a tested domain layer, in pieces, with the procedure left in place until the replacement has been running in parallel. Sometimes a procedure is genuinely the right place for set-based work, in which case it stays — but it gets tests and a comment explaining why.
Yes, and it is usually the more practical split: we take the migration mechanics and the unglamorous groundwork while your team continues feature work. Dividing it the other way tends to stall both, because the migration keeps being deprioritised against whatever shipped that week.
For most workloads, comfortably. Where it is not, the answer is usually a specific query rather than the mapper, and the fix is Dapper or raw SQL for that path while the rest stays where it is. We measure before replacing anything, because the intuition about which query is expensive is wrong more often than not.
Have something ambitious to build?
Tell us what you're working on. We'll tell you honestly whether we're the right team for it.