Din utvecklare är borta: så tar du över en .NET-applikation utan att tappa kontrollen

När utvecklaren eller byrån bakom en affärsapplikation försvinner fortsätter applikationen oftast att fungera ett tag. Det är just det som är farligt. Ingenting ser trasigt ut förrän ett certifikat går ut, en server behöver uppdateras eller en kund hittar ett fel som ingen kan rätta.

Då öppnar någon repositoryt, och den senaste posten ser ut ungefär så här:

$ git log -1 --format="%cr · %an · %s"
1 year, 4 months ago · dev · quick fix, clean up later

Ett övertagande är en serie steg, och ordningen spelar roll: först säkrar du det du äger, sedan tar du reda på vad du faktiskt har, sedan stabiliserar du det, och först därefter bestämmer du vad som ska hända på lång sikt. Här är de stegen, ett i taget, så som vi går till väga när vi tar över ett .NET-system.

1. 48 timmarSäkra det du äger
2. Första veckanTa reda på vad du har
3. Första månadenStabilisera
4. SedanBehålla, modernisera eller skriva om

De första 48 timmarna: säkra det du äger

Innan något tekniskt händer, se till att det är företaget och inte en enskild person som har nycklarna. Gå igenom den här listan med den som fortfarande har administratörsbehörighet.

• Källkod. Var ligger repositoryt: GitHub, Azure DevOps, GitLab, Bitbucket? Tillhör organisationen ditt företag eller utvecklarens privata konto? Gör en fullständig klon redan i dag, med alla grenar och taggar.
• Domän och DNS. Kontot hos registraren ska stå på ditt företag och använda företagets e-postadress. Byråer registrerar ofta domäner åt kunder i eget namn.
• Hosting och moln. Azure-prenumeration, AWS-konto, virtuell server eller egen maskin: vem äger den, vem betalar, vem kan logga in? Lägg till en andra administratör från ditt eget företag.
• Databaser och säkerhetskopior. Ladda ner en färsk säkerhetskopia nu, och kontrollera att den faktiskt går att återställa.
• Inloggningsuppgifter och hemligheter. Anslutningssträngar, API-nycklar för betalnings-, e-post- och sms-leverantörer, TLS-certifikat, appregistreringar i Microsoft Entra ID. Lista allt som applikationen behöver för att fungera.
• Bygge och driftsättning. CI/CD-pipelines i Azure DevOps eller GitHub Actions, och de hemligheter som lagras i dem. Om driftsättningen görs för hand, skriv ner exakt hur den gick till.
• Licenser. Kommersiella komponentbibliotek och verktyg är ofta registrerade på utvecklarens e-postadress. Se till att de förs över till företaget.
• Avtalet. Kontrollera vem som äger koden och om du har rätt till källkoden. Om det är oklart, få det på papper nu, medan relationen fortfarande fungerar, och fråga en jurist om det behövs.

Först när du har administratörsbehörighet överallt tar du bort den tidigare utvecklarens åtkomst och byter alla hemligheter som den kände till. Gör du det i omvänd ordning kan du låsa ute dig själv från ditt eget system.

Om utvecklaren fortfarande går att nå, betala för några timmars inspelad överlämning: var allt finns, hur man driftsätter, vad som är skört. Det är den billigaste försäkring du någonsin kommer att köpa.

Om byrån har gått i konkurs eller lagts ner, kontakta konkursförvaltaren eller den som avvecklar den så tidigt du kan. Repositoryn, molnkonton och domäner kan försvinna tillsammans med företaget.

Första veckan: ta reda på vad du faktiskt har

Det är här överraskningarna finns.

1. Bygg på en ren maskin. Klona repositoryt på en nyinstallerad maskin och bygg med bara det som finns i repositoryt. Om det misslyckas har du hittat den första saknade biten: ett privat NuGet-flöde, en DLL som kopierats in i en mapp för hand, en miljövariabel som bara fanns på den gamla laptopen.
2. Jämför med produktion. Kör produktionen koden från repositoryt? Snabbfixar som kopierats direkt till servern och inställningar som ändrats för hand i IIS eller Azure-portalen är vanliga. Jämför versioner, konfiguration och de driftsatta filerna.
3. Driftsätt i en testmiljö. Tills du kan driftsätta en ändring på ett säkert sätt kan du inte rätta något på ett säkert sätt.
4. Inventera.
   • .NET-versionen och om den fortfarande har support (.NET 8 och .NET 9 förlorar supporten den 10 november 2026)
   • föråldrade och sårbara paket
   • externa tjänster och integrationer
   • arbete som körs utanför applikationen: SQL Server Agent-jobb, schemalagda aktiviteter i Windows, bakgrundstjänster
   • loggning och övervakning, om det finns någon
   • tester: hur många det finns och om de går igenom
5. Leta efter tidsinställda bomber. Saker som slutar fungera på ett visst datum: TLS-certifikat, klienthemligheter i Microsoft Entra ID (de går ut efter högst 24 månader), API-nycklar med utgångsdatum, licensförnyelser, domänförnyelser.
6. Prata med användarna. Fråga vad som går sönder, vad de jobbar runt och vad de har slutat rapportera eftersom ingen rättade det.

För dina utvecklare, kommandona som besvarar de första frågorna:

git log -1 --format="%ci %an"                           # last commit and who made it
dotnet --list-sdks                                      # which .NET SDKs are installed
dotnet list package --outdated                          # packages with newer versions
dotnet list package --vulnerable --include-transitive   # packages with known vulnerabilities

# when the TLS certificate expires
echo | openssl s_client -connect yourapp.com:443 -servername yourapp.com 2>/dev/null | openssl x509 -noout -enddate

# when the client secrets of app registrations in Microsoft Entra ID expire
az ad app list --all --query "[].{app:displayName, secretsExpire:join(', ', passwordCredentials[].endDateTime)}" -o table

Första månaden: stabilisera innan du ändrar något

• Övervakning och larm. Application Insights eller OpenTelemetry, plus en tillgänglighetskontroll, så att du hör talas om problem innan kunderna ringer.
• Säkerhetskopior som är testade, inte bara konfigurerade.
• Grundläggande säkerhet. Byt hemligheter, flytta ut dem ur repositoryt till ett valv, uppdatera sårbara paket, förnya certifikat innan de går ut.
• Tester runt det som drar in pengar. Innan du rör kassan, faktureringen eller rapporterna, lås fast hur de beter sig i dag.
• En README som en ny utvecklare kan följa: hur man bygger, kör, driftsätter och rullar tillbaka.
• Rätta de tre saker användarna klagar mest på. Deras förtroende är en del av övertagandet.

I en typisk ASP.NET Core-applikation handlar övervakning, en hälsokontroll och hemligheter i ett valv om några rader i Program.cs:

builder.Configuration.AddAzureKeyVault(                 // secrets from Key Vault instead of appsettings.json
    new Uri("https://your-vault.vault.azure.net/"),
    new DefaultAzureCredential());

builder.Services.AddOpenTelemetry().UseAzureMonitor();  // requests, dependencies and exceptions in Application Insights
builder.Services.AddHealthChecks()
    .AddDbContextCheck<AppDbContext>();                 // can the application reach its database?

var app = builder.Build();

app.MapHealthChecks("/health");                         // the address your uptime check calls

Sedan bestämmer du: behålla, modernisera eller skriva om

Situation	Oftast rätt beslut
Koden fungerar och affärslogiken är sund	Behåll den, underhåll den, förbättra den efter hand
Den fungerar, men ramverket saknar support eller varje ändring går långsamt	Modernisera steg för steg: uppgradera, refaktorera, byt ut delar
Koden stämmer inte längre med hur verksamheten fungerar, och tekniken är en återvändsgränd	Överväg en omskrivning, med gammalt och nytt i drift sida vid sida

En fullständig omskrivning är sällan rätt första svar. Den kastar bort år av rättade buggar och specialfall som ingen skrev ner, och den fryser utvecklingen i månader. Joel Spolsky kallade redan år 2000 en omskrivning från grunden för det värsta strategiska misstag ett mjukvaruföretag kan göra. Det stämmer fortfarande för det mesta.

Varningssignaler som gör ett övertagande dyrare

• bara kompilerade filer, ingen källkod
• produktionen stämmer inte med repositoryt
• lösenord och nycklar incheckade i repositoryt
• inga säkerhetskopior, eller säkerhetskopior som ingen någonsin har återställt
• en enda server med manuella driftsättningar
• ett ramverk utan support: .NET Core 3.1, .NET 5 till 7, eller .NET Framework utan plan
• kommersiella komponenter utan överlåtbara licenser
• ett hemmabyggt ramverk som bara den tidigare utvecklaren förstod

Inget av detta är ett skäl att få panik. Vart och ett är ett skäl att avsätta mer tid för första veckan.

Så hamnar du aldrig här igen

• Konton som ägs av företaget för allt: kod, moln, domän och e-postadressen de är registrerade på, med minst två administratörer.
• Hemligheter i ett valv, inte i koden eller i någons huvud.
• Automatiserat bygge och automatiserad driftsättning, så att en release inte hänger på en persons laptop.
• En README och en driftmanual som någon annan än författaren faktiskt har följt.
• För affärskritiska system byggda av externa leverantörer, en klausul om deponering av källkod (escrow) i avtalet.

Hur lång tid det tar

För en typisk affärsapplikation: att säkra åtkomsten tar några dagar, inventeringen ungefär en vecka och stabiliseringen några veckor. Det du hittar första veckan avgör resten.

Så arbetar vi

ProCoding är en .NET-studio från Split i Kroatien, och att ta över .NET-applikationer vars utvecklare eller byrå har försvunnit är något av det vi gör oftast. Vi börjar med en inventering av kod, åtkomst, driftsättning, säkerhet och risker, och till sist får du en plan för att stabilisera applikationen. Därefter stabiliserar vi applikationen och underhåller den, på egen hand eller tillsammans med ditt team. Det första steget är ett kostnadsfritt samtal på 30 minuter.

Källor

• Things You Should Never Do, Part I, Joel Spolsky
• Lägga till och hantera autentiseringsuppgifter för appar i Microsoft Entra ID, Microsoft Learn
• dotnet list package, Microsoft Learn