Principer/Best practice för underhåll av gamla Core-versioner?

Morsning
Tänkte kolla hur principerna för gamla end-of-life-versioner av Core ser ut hos era företag..

Anledningen till att jag undrar är att vi har ett gäng applikationer som är skrivna i Core 3.1, samt ett par stycken skrivna i 2.2 och 2.0. Dessa applikationer är driftsatta sedan många år och rullar således utan någon vidare utveckling. IT-avdelningen kräver nu att vi ska fimpa Core 2.x på servrarna och inom ett år även 3.1 då 2.x redan nått end-of-life och 3.1 om ett år.
För mig som utvecklare känns detta väldigt märkligt då det i princip kräver att vi återstartar massor av projekt för att kunna uppgradera fungerande applikationer till 5.x. Det skapar ju inte bara massor av arbete utan man lär ju få en mängd buggar dessutom på system som fungerar som de är nu sedan många år.

Är det brukligt att IT kräver avinstallation av en utdaterad core-version? Visst fasen gör Microsoft säkerhetspatchar även för utdaterade versioner om säkerhetshål upptäcks?

I vissa fall så kan det ju faktiskt vara en bra idé att vara proaktiva och kunna sprida ut både kostnaden och arbetet över tid, kunna arbeta i lugn och ro, istället för att låta "teknikskulden" växa och sen efter ett par år vara tvingade att göra samma arbete i alla fall, fast med mer stress och till en högre kostnad.

Det är en avvägning.

Kan ni debitera det här till externa kunder, eller är det interna saker? Det avgör lite också, man kanske vill stimulera inflödet av nya debiterbara timmar?

Interna applikationer. Jo jag förstår ju det där med teknikskulden.. Funderade mest på hur andra stora organisationer gör. Nu känns det som att IT (serveransvariga) styr över vad vi måste jobba med i och med det här. Och visst, är det så att Microsoft inte ens släpper säkerhetspatchar när end-of-life har uppnåtts för en core-version så förstår jag ju deras inställning.

Tycker personligen att IT gör rätt som pushar för att gammalt mög som inte längre underhålls ska bort från servrarna.
Gamla grejer kan vara helt säkra...tills en dag då de inte längre är det (någon hittar en exploit i en gammal .NET runtime) och då blir det jäkligt jobbigt om man inte hållit sina grejer uppdaterade.

Man får mycket gratis när man väljer att bygga på .NET plattformen, men man får också acceptera att man får anpassa sig till den riktning .NET utvecklas i. Skiftet från Windows-only till .NET Core var en stor grej men många kunde fortsätta köra på gamla plattformen som fortsatte utvecklas. Men med .NET 5 lämnar man i princip den gamla plattformen åt sitt öde och med det sitter många företag med exvis lösningar som bygger på WCF och vet inte hur de ska göra nu.

Du kan tycka att IT är jobbiga, men de gör er en tjänst som tvingar hålla era saker uppdaterade. Ni vill inte hamna i ett läge där ni sitter med massa gamla saker som inte längre går att modernisera. Det blir ett stort svart hål som suger i sig pengar men aldrig går att bli av med (se på de gamla stordatorsystemen som är byggda med Cobol, kostar enorma summor men ingen lyckas göra sig av med dem).

Kör alltid LTS. 3.1 är LTS, så ert misstag är att inte allt är där redan.

Tydligaste anledningen är att stora hopp är extremt jobbiga. Men att gå LTS 1 -> LTS 2 -> LTS 3.. är sällan övermäktigt. Och när det ändå hänt väldigt mycket så har Microsoft mycket stora incitament att hjälpa er klara migreringen ändå.

Du kommer nog märka att er 2.0 är väldigt jobbig tex.

Vi ser till att hela tiden uppdatera våra system. Vi är på .NET 5 samt har en branch för .NET 6 preview

Samam gäller för nuget. Se till att hela tiden hålla paketen up to date. Mycket lättare med små steg än att göra stora hopp. Divide and conquer

Egentligen borde alla projekt också innehålla ett avtal om aktiv förvaltning framåt i tiden. Bl.a. att man planerar in ett par veckor per år där man lyfter upp till senaste versionen av underliggande ramverk. Det borde vara lika självklart som att man återkommande gör service på en ny bil. Många projekt kostar ju i storleksordningen som en ny bil. Kunderna måste lära sig att ett system kostar inte bara i form av estimerade programmeringstimmar. Det tillkommer en hel del i service och underhåll på flera års sikt.