ASP.NET development services
ASP.NET is the web layer of an application: its pages, its sign-in, and the code that answers each request. This page answers three questions. Whether an application you already run can still be changed safely. Whether ASP.NET Core is the right thing to build a new one on. And whether ASP.NET engineers can work beside a team you already have.
01Capabilities
The expensive problem first, then the other three
ASP.NET is where the web application itself lives: the routes, the sign-in, the middleware that sits between a request and your code. Four kinds of work arrive on it, and the first is where most of this page goes, because an application that can no longer be safely changed is the expensive problem. Platform-level .NET questions belong on our .NET page, and language-level ones on our C# page.
- Legacy
Web Forms and legacy MVC, moved without a rewrite
Applications off .NET Framework and onto current .NET, where a rewrite is not warranted. Web Forms estates need a route-by-route path: the page lifecycle does not translate cleanly, and pretending otherwise is how these projects fail. This sits inside legacy modernization. On Triathlon Ireland's platform the main functionality moved from Webforms to .NET Core 3.1 plus a Vue JS module, module by module.
- Portals
Internal platforms people run the company on
Portals, back-office tools and business web applications on ASP.NET Core, from fintech back offices to automotive service systems. Authorisation and auditability matter more here than anything user-facing, because these are the systems a GDPR subject-access request or an internal audit lands on. We use ASP.NET Core Identity and policy-based authorisation rather than role checks scattered through controllers.
- APIs
APIs over data that was never designed for them
ASP.NET Core APIs in front of existing databases and third-party systems, including the awkward middle layer where an old schema meets a client that expects clean resources. Minimal APIs where the surface is small, MVC controllers where it is not, Entity Framework Core over the schema you already have, and SignalR only where a client genuinely needs pushed updates instead of polling.
- Performance
Applications that have quietly become slow
Slow or unreliable under load, and the cause is rarely the framework. It is data access patterns and synchronous work on request threads: N+1 queries through the ORM, blocking calls inside async handlers, no response or output caching, and a hosting model nobody has revisited since the day it was deployed.
02Case studies
Six systems, and the job the web layer had
Six published builds, across logistics, security, sport, modernization, fintech and automotive.
See all case studies
LogisticsMiniMoves Orders Management PlatformA custom-built moving order system that simplifies booking, boosts automation, and improves operational efficiency.Double digit growthMaintained without a substantial increase in staffing
SecurityMulti-factor authentication platform: Data architecture refactoringSolus Connect is an innovative multi-factor authentication platform that uses 3D facial authentication and machine learning to track down fraudulent behavior.
SportSports app development for Triathlon associationunicrew engineers modernized the sports website and built a mobile app for better membership management and race planning.- 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.
FintechAccounting Software Integration & Automation for a Financial Advisory CompanyBookkeeping reconciliation automated on a build unicrew took over, with no issues reported as transaction sizes grew in testing.
AutomotiveJack Cooper: Software for automotiveA sophisticated vehicle inspection tool for one of the biggest transportation providers.
03Fit
Modernize, rewrite, or keep it running
Two decisions arrive here. Whether ASP.NET Core is the right thing to put a new web application on, and whether an existing one should be modernized in place or rewritten. On the second our default is modernize, because a rewrite has to earn itself. Each of the eight rows below names the move that fits, from a new ASP.NET Core build to keeping a stable estate running.
| Your situation | What we recommend |
|---|---|
| New build, rule-heavy web application, Microsoft estate already in-house | Use ASP.NET CoreSQL Server, Active Directory and the people who already run them line up, and the tooling makes large refactors survivable rather than heroic. |
| A dated but sound domain model that has become slow to change | Modernize in placeUpgrade the runtime, isolate data access, then move surface area a route at a time. This is our default, because a rewrite has to earn itself. |
| A Web Forms estate | Port route by routeNever an automatic conversion. The page lifecycle and view state have no ASP.NET Core equivalent, so anyone quoting this as mechanical has not opened the code. |
| The domain model itself needs redesigning, not only updating | Rewrite is justifiedThis is the main case where it is. Global On Media is the published example: the code rewritten and the infrastructure moved with it, onto .NET Core. |
| New build, and your own developers write JavaScript | Build it in Node.jsNode.js keeps one language across the stack, so your own developers can maintain what gets built. |
| Stable, patched, and nothing the business needs is blocked by it | Keep it runningA migration with no blocked change behind it is spending with no return. Put the budget where change is actually stuck. |
| The real question is the platform: runtimes, hosting, a workload that renders no pages | Different pageOur .NET page. There the platform decision dominates the web framework one. |
| 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 framework migration. |
Scope
What we own on an ASP.NET engagement is the web-layer decision and everything downstream of it. The routes, the sign-in model, the failure modes, the upgrade path. And whether your own developers can keep shipping after we stop. We build under an ISO 27001:2022 certified information-security management system. unicrew has been building software since 2012, with 100+ senior in-house engineers across six countries. The recommendation is sized to what the application needs, even when that is a smaller piece of work than the one you came for.
On an ASP.NET estate, we first pull business logic out of page lifecycle events into plain classes. The application keeps running, and the logic becomes testable. We then move to current .NET route by route, and you can stop halfway with a working system.
Yaroslav HavrylivSenior Engineering Manager, unicrew04Delivery
How a Web Forms estate moves one route at a time
Four steps, in this order, and the order is what keeps the application shippable throughout. Step two is the largest single piece of work on a Web Forms estate, and it is the one people try to skip. What comes out of each step, and what we need from you to run it, is stated per step.
- Inventory the real surfaceEvery route, every scheduled job, every integration and every direct database consumer we can find. On applications of this age there is almost always a consumer nobody remembered, and finding it after the cutover is the expensive version. What comes out: a written inventory of routes, jobs, integrations and direct database consumers, with the ones nobody can account for flagged. What we need from you: read access to the repository and to the production configuration, plus someone who can chase the unclaimed integrations.
- Get the behaviour under testCharacterisation tests over the critical paths, driven through the interface where the internals resist unit testing. On a Web Forms estate this is often the largest single piece of work, and skipping it is why these projects acquire a reputation. What comes out: a suite that pins current behaviour and runs in CI, so a regression is a failing build rather than a support ticket. What we need from you: one person who can settle what correct behaviour is when the code and the documentation disagree, and a non-production data set that looks like the real one.
- Split the data access from the frameworkIsolating persistence from the web layer is what makes the rest incremental. Once it is separate, individual routes can move without dragging the whole application behind them, and Entity Framework Core can be introduced behind the seam instead of in a big bang. What comes out: data access behind explicit boundaries, with the schema and the awkward parts of it documented. What we need from you: a decision on which reports, jobs and third parties keep talking to the database directly.
- Move route by route behind a proxyOld and new applications served under one hostname, traffic shifted a route at a time, with the ability to move it back. Usually that is YARP as the reverse proxy, with the System.Web adapters so session and authentication are shared while both applications are live. Cutover stops being an event you rehearse and becomes a setting you change. What comes out: both applications in production behind one hostname, with a per-route way back. What we need from you: DNS and hosting access, and a business owner per route who can say the new one is fine. Each move is verified through the same QA and test automation practice we use on our own builds.
05Client voices
Five clients who had to live with the decision
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.
We scoped out the workflow for the platform. Using this foundation, Artelogic’s executing our requirements and developing the platform. Artelogic executed flawlessly according to our plan thus far. Their work ethic is impressive.
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.
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.
I’m consistently humbled by Artelogic’s performance. Projects of this caliber are hard to outsource. Teams come and go, and this type of work almost never gets done. They’ve kept their priorities straight as they’ve grown and always deliver.
06Stack
What sits on either side of the web layer
The platform under it, the language it is written in, and what runs in front of and behind it. Each has its own page if that is the decision you are actually making.
07Questions
Asked before we get read access to anything
Short answers, the same ones you would get on a call. If yours is not here, it makes a good first message.
Yes, and on modernization work it is often the right shape, because your people hold the domain knowledge and ours hold the migration experience. Ownership of the architecture stays with us too: an architect outside the delivery team reviews the migration plan, and the work goes through the same QA and test automation practice as our own projects. Team extension is managed teams; handing over the outcome is legacy modernization.
ASP.NET is the web application framework. .NET is the platform underneath it. If your question is about a web application, its routes, its sign-in or moving it off Web Forms, this page is the right one. If it is about the platform, or about a service or desktop workload that renders no pages, our .NET development page covers that. Most engagements touch both.
Yes, and the cost is worth knowing up front. There is no automatic translation: Web Forms depends on a page lifecycle and view state model ASP.NET Core does not have, so it is a route-by-route port rather than an upgrade. We run it behind a reverse proxy, usually YARP with the System.Web adapters, and move traffic gradually. On Triathlon Ireland's platform the main functionality moved from Webforms to .NET Core 3.1 plus a Vue JS module.
For the right application, yes. It is a strong default when the application is rule-heavy, the data already lives in SQL Server, and your own people work in the Microsoft stack. It is the wrong default when your developers write JavaScript and Node.js would keep one language across the stack, or when the hard part is models and data rather than screens, where Python owns the ecosystem.
No, and bundling the two is a common way to make both harder to judge. A framework migration and a hosting migration each carry their own risk, and running them together means you cannot tell which one caused a regression. We normally sequence them. Which one goes first depends on whether your current hosting is the more urgent problem, and that is worth settling before either starts.
A scoping call with an engineer, not a salesperson. For an existing application we ask for read access to the repository first, because on a Web Forms estate half an hour in the code changes the estimate more than any amount of description. What comes back is written: the routes, jobs and integrations we found, the ones nobody can account for, and one recommendation of three. Most engagements start within two to four weeks.
Three reasons make the case: security patching on an unsupported framework, an inability to hire anyone willing to maintain it, and change becoming slow enough that the business stops asking for things. Any one of them is reason enough to plan the move. When none applies, the application can keep running as it is, and the budget goes where change is actually blocked.
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 still moving. Fixed price is outcome based, and we only offer it once the first read is done, because a fixed number on a system nobody has opened is a guess with a contract around it. Team extension is billed monthly per engineer.
Have an ASP.NET application you are afraid to touch, or a new one to start?
Tell us what it does and what breaks, or what you are about to build. You will get a straight assessment: modernize, rewrite, keep it running, or build it on something else.