(Technology) · .NET 10 LTS · SQL Server 2025
A stack with published end dates.
Plenty of platforms look fast on launch day. For something you intend to run for a decade the question is different, and duller, and far more important: who maintains the foundations, and until when?
Choosing a technology is choosing who you depend on. We would rather it were someone with a published obligation.
Every website rests on foundations somebody else maintains - a language, a framework, a database. Most of the time nobody thinks about them, right up until the day support ends and the security patches stop. We build on Microsoft's .NET and SQL Server because for both of those, the end dates are published years ahead and you can plan against them instead of hoping.
(The foundations, and their dates)
Dates you can put in a business plan.
Released in November 2025 and supported by Microsoft until November 2028, on a published annual cycle where every even-numbered release carries three years. Worth knowing if you are comparing quotes: .NET 8 and .NET 9 both reach end of support in November 2026, so a proposal built on either is starting life with a migration already due.
Mainstream support until January 2031 and security updates through to January 2036, under Microsoft's fixed lifecycle policy. That is a decade of published dates for the part of the system holding your data - and it is a standard database, not a proprietary format only one supplier can open.
No surprise rewrite because a framework was quietly abandoned. Security patches from a vendor with a support obligation rather than a volunteer's spare evening. And mainstream skills: C# and SQL Server developers are everywhere, so nothing here rests on one rare specialism.
Why this stack, practically.
(The ongoing bit)
Keeping it current is part of the job.
(01)The dates are diarised, not discovered
Support windows are tracked from the day we build. An upgrade is planned before support ends, which makes a version change a scheduled piece of work rather than an emergency triggered by a warning nobody was watching for.
(02)Patches matter as much as versions
Being on a supported version only helps if you apply what it ships. Cumulative updates and out-of-band security releases are assessed weekly as part of the same Security Watch that covers everything else.
(03)Upgrades are tested like features
A framework upgrade goes through the same independent review and regression pass as new development. Nothing is assumed safe because Microsoft published it.
(04)Your data stays portable
Your content and data are yours and export cleanly, in a standard database format any competent developer can read. OliveCore itself is available under licence - to organisations and to other agencies - so choosing us does not have to mean being stuck with us. There is more on that, including where the limits sit, on the platform page.
The honest edges.
Ours included. Building on a Microsoft stack means depending on Microsoft's roadmap, and a supported version does eventually stop being supported - which is precisely why the dates matter and why we track them. A site built this way is also not something you can hand to the cheapest freelancer on a marketplace and expect a good outcome, because it is engineered rather than assembled. What you get in exchange is a system that behaves predictably, patches cleanly, and is still supportable in ten years. For most organisations that is the trade worth making - but it is a trade, and we would rather say so than pretend otherwise.
