.NET development
Three things bring people to this page: a new system that has to still be right in ten years, a .NET Framework estate pinned to a runtime nobody wants to patch, and a service or desktop workload that no one inside the company will take on.
01Capabilities
What we build with .NET
.NET is the platform: the runtime, the base libraries and the hosting model your code actually runs on. This page covers platform-level decisions and the systems we build on them, and it feeds our custom software development work. Web application specifics sit on our ASP.NET page, and language-level questions on our C# page.
- Platforms
Business platforms built from the ground up
Order management, dispatch, service and back-office platforms, the shape of system behind our logistics and transportation work and our automotive builds. Long-lived transactional systems where a wrong state transition costs real money and the domain rules outlive whoever wrote them. We build them under an ISO 27001:2022 certified information-security management system.
- Workers
Services, workers and scheduled processing
The .NET workloads that never render a page: queue consumers, import and reconciliation jobs, integration daemons, Windows services and console processing. Hosting model, cancellation and restart behaviour matter far more here than anything a user sees, and they are where inherited systems tend to be quietly broken.
- Integration
Integration layers between systems never designed to talk
ERPs, warehouse systems, payment providers, monitoring hardware in healthcare, and whatever the business bought last year, joined behind one contract. Idempotency, retries and reconciliation are the actual engineering, not the happy path. This is our platforms and integration work.
- Migration
Moving .NET Framework estates onto current .NET
Platform-level migration: retargeting the solution, replacing the Windows-only dependencies that have no modern equivalent, and getting off a runtime that no longer gets attention. Route-by-route web migration lives on our ASP.NET page; this is the estate around it, and it sits inside legacy modernization.
02Case studies
.NET in production
Six systems in production, across modernization, logistics, healthcare, automotive, sport and knowledge work.
See all case studies
LogisticsCustom software for USA moving companyAn end-to-end SaaS platform for managing household moves and every business operation of a logistics company.Built from scratchAn end-to-end SaaS for household moves and the operations behind them- ModernizationRewriting and migrating a legacy platform onto .NET Core (Global On Media)unicrew rewrote Global On Media's legacy code and migrated its servers onto .NET Core, React, and Stencil.js in one engagement.
Knowledge ManagementSaaS for Digital ResearchesA SaaS solution that helps knowledge workers streamline research work involving a substantial amount of information.
AutomotiveService Intelligence: App for vehicle maintenanceunicrew helped eAutoClub launch Service Intelligence, an app that works out what service a vehicle needs from how it is actually used.
SportSports app development for Triathlon associationunicrew engineers modernized the sports website and built a mobile app for better membership management and race planning.- HealthcareStabilizing and Scaling a Home Health Monitoring PlatformA U.S. consumer health tech company needed system stability and an experienced partner. unicrew stabilized the platform, optimized infrastructure costs, and delivered new features, becoming a long-term technology partner.
03Fit
How we decide .NET is the right call
.NET is a strong default for rule-heavy business systems inside a Microsoft estate, and the wrong tool for several problems it still gets used for. Before that, there is a routing question, because a good share of what arrives labelled a .NET decision turns out to be a web framework decision or a language decision.
| Your situation | What we recommend |
|---|---|
| Rule-heavy transactional system, Microsoft estate, expected to outlive the team that builds it | Use .NETActive Directory, SQL Server and Windows operations all line up, and the tooling makes large refactors survivable rather than heroic.Tell us what the system doesOr book a meeting |
| The real question is a web application: routes, authentication, a Web Forms estate | Different pageOur ASP.NET page. There the web framework decision dominates the platform one.Go to the ASP.NET pageOr book a meeting |
| The real question is the code itself: language version, async correctness, a large refactor | Different pageOur C# page. That is a language exercise, and it is usually far cheaper than a platform migration.Go to the C# pageOr book a meeting |
| The product is really a data or machine-learning pipeline | We argue againstThe library gap is not close, and Python owns that ground.Talk it through with an engineerOr book a meeting |
| Existing JVM estate, JVM operations, JVM people | We argue againstJava will be cheaper to staff and run, and switching platform to fix a working estate almost never pays.Talk it through with an engineerOr book a meeting |
| A .NET Framework application that is stable, patched, and that nobody needs to change | Leave it aloneA migration with no blocked change behind it is spending with no return, and we would rather say that than quote it.Sanity-check that with usOr book a meeting |
Scope
What we own when we work on .NET is the platform decision and everything downstream of it: the runtime and hosting choice, the failure modes, the upgrade path, and whether your own developers can keep changing the system after we stop. That holds whether the domain is fintech, logistics or something we have not worked in yet. Where the honest answer is a smaller piece of work than the one you came for, you get that answer, including when the larger piece would have been ours.
The .NET systems that surprise people are almost never the web tier. It is the workers: queue consumers and overnight jobs with no user to complain when they stop, so a process that has been failing quietly for months looks like a data problem rather than an outage. Before we change how one runs, we make its failures visible and its restarts survivable. Often that turns out to be the whole engagement, and the migration somebody asked us to quote was never the thing that was broken.
Oleksandr TrofimovChief Technology Officer, unicrew04Delivery
How a .NET Framework migration actually runs
Platform migrations fail at the discovery step, not the coding step. This is the order we run it in, and step two decides whether you are buying an upgrade or a redesign.
- Establish what the platform actually isTarget frameworks across every project in the solution, the hosting model, the third-party packages and their licence positions, and where the build is pinned. Solutions of this age usually have three or four different answers living inside one repository.
- Find the Windows-shaped dependencies firstServer-side WCF hosting, System.Web, Web Forms, COM interop, GDI drawing, MSMQ, anything reaching into the registry. None of these has a direct equivalent on current .NET, so they are what turns a retarget into a redesign. Discovering them in month four is the expensive version of this step.
- Move the libraries before the executablesShared domain and data libraries retargeted first, multi-targeting where both runtimes need them during the transition. Working bottom up keeps the application shippable instead of producing a long-lived branch nobody wants to merge.
- Run both runtimes in production at the same timeOld and new hosts live together, workload by workload, with a tested way back for each one. Cutover stops being a night you rehearse and becomes a setting you change. Each step is verified through the same QA and test automation practice we use on our own builds.
05Client voices
What these clients said
Site was migrated and re-written, the new system is much more stable, and performance highly improved. Excellent technological level. highly responsive and communicative. They are highly committed to the project and business goals.
Our website’s overall functionality has been improved both in frontend possibilities and user experience as well as backend aspects of website management and financial monitoring. These are not easily qualitfiable but there has been a net gain in available staff hours for alternative projects as a result of improved website abilities reducing workload.
We’re one of unicrew’s smaller clients, but they’re always incredibly quick to respond. When we have issues, they treat them as if they’re extremely important. We feel like we have a partner, and that’s been incredible. That’s why we’ll keep them on for as long as we can.
I’ve been impressed by their work ethic and how they put me as the customer first. They’re always ready to jump in and go the extra mile. They put great effort into communicating to ensure that tasks are updated in a timely manner. The team keeps us apprised of exactly what they’re working on.
Up until a year and a half ago, I handled all the development and support of our application myself and I needed help. I brought in Artelogic, and it was one of the best business decisions I’ve ever made.
06Stack
What we run alongside .NET
The technologies that show up in the same solutions, each with its own page if that is the decision you are actually making.
07Questions
Questions we get about .NET work
Answered the way we would answer them on the call. If yours is not here, it is a good first message.
You can bring our engineers onto your team, and on a platform migration that is often the right shape, because your people know why the system was built this way and ours know what breaks on the way across. What we will not do is supply developers and treat the architecture as somebody else's problem. Concretely: an architect outside the delivery team reviews the platform and hosting decisions, the work goes through the same QA and test automation practice as our own projects, and where you want an outside verdict on the estate before anyone commits to a scope we run a quality audit. Team extension is managed teams; handing over the outcome instead is custom software development.
This one is the platform: runtimes, hosting, greenfield system design, moving off .NET Framework, and workloads that are not web applications at all. C# is the language, so language version, async correctness and code-level refactors belong there. ASP.NET is the web framework on top of the platform, so routes, authentication and Web Forms belong there. Real engagements normally touch all three, so start from whichever is closest to your problem and we will sort the rest out on the call.
No. Current .NET runs on Linux and in containers, and for most new systems that is what we would do, because the hosting is cheaper and the deployment path is simpler. What keeps an application on Windows is rarely the platform itself, it is specific dependencies: server-side WCF hosting, Web Forms, COM interop, GDI drawing, MSMQ, registry access. Those are the first thing we look for, because they decide whether moving to Linux is a configuration change or a redesign of a component.
Broadly four. Web applications and the APIs behind them. Internal business platforms such as order management, dispatch and service scheduling. Background and integration workloads that never render a page. And desktop or line-of-business tools that are still running quietly inside companies. If you came looking for public examples of sites running on the platform rather than for a supplier, our post on web resources built using .NET is the more useful page. The commercial answer is that the platform is rarely the interesting constraint, and what your system has to guarantee is.
A scoping call with an engineer rather than a salesperson. For an existing estate we ask for read access to the repository and the build output first, because half an hour inside a solution file moves an estimate more than an hour of description does. What comes back is written: what we would do first, what we would not touch, and where the risk is concentrated. Most engagements start within two to four weeks, so ask on the call and the answer will be specific to your system.
Three shapes, and which one fits depends on how settled the scope is. Time and materials is billed hourly and quoted per project, which suits work where the scope is still moving. Fixed price is outcome based and quoted per project, and we will only offer it once the first read is done, because a fixed number on a system nobody has opened yet is a guess with a contract around it. Team extension is billed monthly per engineer, for when you need people inside your own process and planning. The rate inside any of them depends on the seniority mix the work actually needs, so it is quoted rather than listed.
Building on .NET, or stuck on .NET Framework?
Tell us what the system does and what is blocked. You will get an engineer's read on the platform decision, the migration path, and the parts we would leave alone.