When you commission a system to manage orders, inventory, or invoicing, you rarely ask which platform it will be built on. It seems like a technical matter for the team doing the work. But that choice stays with you for years after launch, and it shows in the cost of maintenance, in how easy upgrades are, and in your ability to move the system to another team if you need to.
At ITS, we build backend services and APIs for business systems on .NET. In this article, we explain why, in terms that matter to the decision-maker rather than the programmer. We also explain when another option may be a good fit, and we close with questions to ask any vendor, whatever their platform.
What matters to you in choosing a platform
A business owner doesn’t need a comparison of programming languages. What they need are answers to practical questions that affect their budget and the continuity of their business:
- Will the platform keep receiving security updates for the whole life of the system?
- Can upgrades be planned in advance, or will they come as a surprise?
- Are there mature tools for what business systems need: data, permissions, and connecting with other systems?
- Could another team understand and maintain the code if you changed vendors?
- Are you free to choose where the system is hosted?
These are the criteria we use to judge our own choice, and they are the same criteria we advise you to apply to any proposal you receive.
Long-term support and upgrades you can plan for
A business system isn’t replaced every year, so it matters to us that the platform has a public support policy. According to the support policy published on the official .NET website, a new major version is released every year in November. Even-numbered versions are long-term support releases, which receive free support and updates for three years, and odd-numbered versions are standard-term support releases, supported for two years.
The practical effect is that you know in advance when support ends for the version your system runs on. You can put the upgrade into the year’s plan and budget, instead of suddenly discovering that your system is running on a version that no longer receives security updates.
Suppose your system was launched on a long-term support release. You can agree with your team on a set upgrade window before support ends, in which the upgrade is tested on a copy of the system and then applied at a quiet time of year. That way, the upgrade becomes a planned maintenance task, not an emergency.
We plan each upgrade as a small project with a clear scope: reviewing the libraries the system depends on, running the tests, and trying the system in a separate environment before moving it to production. The more organized and tested the code is, the shorter and less risky the upgrade.
Mature tools for business systems
Business systems have similar basic needs: a database that changes over time, APIs that connect the system to a mobile app or to another system, and permissions that decide who sees what. When the platform provides well-known tools for these needs, the team spends its time on your business rules, not on building the basics from scratch.
- Data access: Entity Framework Core, an open-source library from Microsoft, organizes how the system works with the database, supports multiple database engines, and lets the database structure evolve step by step as the system develops.
- APIs: the ASP.NET Core framework is used to build web applications and the APIs that connected apps and systems need.
- Security: ASP.NET Core includes built-in features for authentication, authorization, and data protection, so it doesn’t all have to be written by hand in every project.
Suppose your system needs to connect to a mobile app for your sales reps, and then to an online store a year later. Having a well-known framework for building APIs means the new connection follows the same pattern, and the permissions applied to the screens apply to the APIs as well.
Hosting: options, not lock-in
The .NET platform is free and open source. Its applications run on Windows, Linux, and macOS, and they can run in Docker containers. According to the ASP.NET Core documentation, applications can be deployed to an organization’s own data centers or to the cloud.
This leaves the decision with you: a server inside your company if your data policy requires it, or a cloud service if that suits your branches better. Choosing the platform doesn’t tie you to any particular hosting provider.
You can also start on an in-house server and move to the cloud when your business volume changes, without being forced to change the platform the system was built on.
Code that is easier to maintain and hand over
C#, the main programming language of .NET, is a strongly typed language. Put simply, every value in the code has a defined type, such as an amount, a date, or an invoice number, and many errors surface when the system is built, before they reach the user.
In a small system, this may not seem important. But a custom ERP system built module by module grows over time, and every change to one module may affect others. When the types are clear, the developer sees the effect of a change early, and there is less risk that a fix in sales breaks something in accounting.
Suppose the discount field changes from a fixed amount to either an amount or a percentage. In a strongly typed language, building the system points to every place that uses this field, so no forgotten spot is left calculating the discount the old way.
There’s another effect that matters to you directly: handover. A widely known, open-source platform makes your system less dependent on a single team or a rare skill. If you decide one day to move the system’s maintenance to your in-house team or to another vendor, the new team will find tools and documentation it already knows. That is why we care about keeping the code readable and documented, so that whoever takes it over after us can understand it.
Not the only option
We are not saying .NET is the right choice for every project. There are other mature platforms on which good systems are built, and a team that knows its platform well and writes clear, tested code matters more than the name of the platform itself.
Another option may be a better fit in specific cases: if you have an in-house team that works on another platform and will take over maintenance, or if the new system extends an existing one built with a different technology. In those cases, we discuss it openly, because a system that fits the people who will maintain it matters more than our preferences.
In the end, what matters to us isn’t the platform in itself, but what it means for you: a system that receives security updates, upgrades whose timing you know, and code that others besides us can understand and maintain.
We explained a related idea in “Microservices: when you need them and when you don’t”: a sound technical decision starts from the nature of the business and the size of the team, not from buzzwords. Choosing a platform follows the same rule.
The right platform is the one you can maintain, upgrade, and hand over years from now, not the one that looks modern today.
Questions to ask any vendor
Whether you work with us or with someone else, ask these questions before signing a contract, and ask for the answers in writing:
- Which platform and which version will the system be built on, and when does support for that version end?
- What is the upgrade plan before support ends, and who covers its cost?
- Do I own the code, and will I receive it with enough documentation for another team?
- Can the system be hosted on an in-house server or in the cloud, or is it tied to a single provider?
- How are permissions and data protection handled, and do they rely on the platform’s tools or on hand-written solutions?
- How are changes tested before they reach users?
Clear answers to these questions tell you more about a vendor’s maturity than the name of the platform does. If you’re evaluating a proposal for a new system or thinking about updating an existing one, you can discuss your situation with the ITS team, so that together we can review the technical options and how they affect your business.
Related serviceBackend services and microservices