Vaš developer je otišao: kako preuzeti .NET aplikaciju bez gubitka kontrole

Developer ili agencija koji stoje iza vaše .NET aplikacije su otišli. Što osigurati u prvih 48 sati, što provjeriti prvi tjedan i kad ima smisla prepisati.

Vlado Pandžić

Vlado Pandžić · Osnivač · Senior .NET arhitekt
Objavljeno · 7 min čitanja

Kad developer ili agencija koji stoje iza poslovne aplikacije nestanu, aplikacija obično još neko vrijeme radi. To je opasni dio. Ništa ne izgleda pokvareno dok ne istekne certifikat, dok server ne zatreba ažuriranje ili dok klijent ne pronađe grešku koju nitko ne zna popraviti.

Onda netko otvori repozitorij, a zadnji zapis glasi otprilike ovako:

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

Preuzimanje je redoslijed koraka, i redoslijed je važan: prvo osigurajte ono što je vaše, zatim saznajte što zapravo imate, onda to stabilizirajte, i tek tada odlučite što s tim dugoročno. Ovo je taj redoslijed, korak po korak, onako kako ga mi provodimo kad preuzimamo .NET sustav.

  1. 48 satiOsigurajte ono što je vaše
  2. Prvi tjedanSaznajte što imate
  3. Prvi mjesecStabilizirajte
  4. ZatimZadržati, modernizirati ili prepisati

Prvih 48 sati: osigurajte ono što je vaše

Prije ičeg tehničkog, pobrinite se da ključeve drži tvrtka, a ne pojedinac. Prođite ovaj popis s onim tko još ima administratorski pristup.

  • Izvorni kod. Gdje je repozitorij: GitHub, Azure DevOps, GitLab, Bitbucket? Pripada li organizacija vašoj tvrtki ili osobnom računu developera? Napravite potpunu kopiju još danas, sa svim granama i oznakama.
  • Domena i DNS. Račun kod registrara treba biti na ime vaše tvrtke i koristiti vašu e-mail adresu. Agencije često registriraju domene za klijente na svoje ime.
  • Hosting i cloud. Azure pretplata, AWS račun, virtualni server ili vlastiti server: tko ga posjeduje, tko ga plaća, tko se može prijaviti? Dodajte drugog administratora iz vlastite tvrtke.
  • Baze podataka i backupi. Preuzmite nedavni backup odmah i provjerite da se stvarno može vratiti.
  • Pristupni podaci i tajne. Connection stringovi, API ključevi za plaćanje, e-mail i SMS servise, TLS certifikati, registracije aplikacija u Microsoft Entra ID-u. Popišite sve što aplikacija treba da bi radila.
  • Build i isporuka. CI/CD pipelineovi u Azure DevOpsu ili GitHub Actionsu i tajne spremljene u njima. Ako je isporuka ručna, zapišite točno kako se radila.
  • Licence. Komercijalne biblioteke komponenti i alati često su registrirani na e-mail adresu developera. Neka se prebace na tvrtku.
  • Ugovor. Provjerite tko je vlasnik koda i imate li pravo na izvorni kod. Ako nije jasno, dobijte to pismeno sada, dok odnos još funkcionira, i pitajte odvjetnika ako treba.

Tek kad imate administratorski pristup svugdje, uklonite pristup bivšeg developera i promijenite svaku tajnu koju je znao. Obrnutim redom možete zaključati sami sebe izvan vlastitog sustava.

Ako je developer još dostupan, platite nekoliko sati snimljene primopredaje: gdje je što, kako se isporučuje, što je krhko. To je najjeftinije osiguranje koje ćete ikad kupiti.

Ako je agencija prestala s radom, javite se onome tko je likvidira čim prije možete. Repozitoriji, cloud računi i domene mogu nestati zajedno s tvrtkom.

Prvi tjedan: saznajte što zapravo imate

Ovdje su iznenađenja.

  1. Buildajte na čistom računalu. Klonirajte repozitorij na tek postavljeno računalo i buildajte samo s onim što je u repozitoriju. Ako ne uspije, pronašli ste prvi dio koji nedostaje: privatni NuGet feed, DLL ručno kopiran u mapu, varijablu okruženja koja je postojala samo na starom laptopu.
  2. Usporedite s produkcijom. Vrti li produkcija kod iz repozitorija? Hitni popravci kopirani ravno na server i postavke ručno promijenjene u IIS-u ili Azure portalu su česti. Usporedite verzije, konfiguraciju i isporučene datoteke.
  3. Isporučite na testno okruženje. Dok ne možete sigurno isporučiti promjenu, ne možete ništa sigurno ni popraviti.
  4. Napravite popis stanja.
    • verziju .NET-a i je li još podržana (.NET 8 i .NET 9 gube podršku 10. studenog 2026.)
    • zastarjele i ranjive pakete
    • vanjske servise i integracije
    • posao koji se odvija izvan aplikacije: SQL Server Agent jobove, zakazane zadatke u Windowsu, pozadinske servise
    • logiranje i nadzor, ako ih uopće ima
    • testove: koliko ih ima i prolaze li
  5. Potražite tempirane bombe. Stvari koje otkažu na određeni datum: TLS certifikati, client secreti u Microsoft Entra ID-u (istječu najkasnije nakon 24 mjeseca), API ključevi s datumom isteka, obnove licenci, obnove domena.
  6. Razgovarajte s korisnicima. Pitajte što se kvari, što zaobilaze i što su prestali prijavljivati jer to nitko nije popravio.

Za vaše developere, naredbe koje odgovaraju na prva pitanja:

git log -1 --format="%ci %an"                           # zadnji commit i tko ga je napravio
dotnet --list-sdks                                      # koji su .NET SDK-ovi instalirani
dotnet list package --outdated                          # paketi s novijim verzijama
dotnet list package --vulnerable --include-transitive   # paketi s poznatim ranjivostima

# kad istječe TLS certifikat
echo | openssl s_client -connect yourapp.com:443 -servername yourapp.com 2>/dev/null | openssl x509 -noout -enddate

# kad istječu client secreti registracija aplikacija u Microsoft Entra ID-u
az ad app list --all --query "[].{app:displayName, secretsExpire:join(', ', passwordCredentials[].endDateTime)}" -o table

Prvi mjesec: stabilizirajte prije nego išta mijenjate

  • Nadzor i upozorenja. Application Insights ili OpenTelemetry, uz provjeru dostupnosti, da za probleme čujete prije nego vas nazovu klijenti.
  • Backupi koji su testirani, a ne samo postavljeni.
  • Sigurnosne osnove. Promijenite tajne, premjestite ih iz repozitorija u trezor, ažurirajte ranjive pakete, obnovite certifikate prije nego isteknu.
  • Testovi oko onoga što donosi novac. Prije nego dirnete naplatu, fakturiranje ili izvještaje, zabilježite kako se danas ponašaju.
  • README koji novi developer može slijediti: kako buildati, pokrenuti, isporučiti i vratiti na prethodnu verziju.
  • Popravite tri stvari na koje se korisnici najviše žale. Njihovo povjerenje dio je preuzimanja.

U tipičnoj ASP.NET Core aplikaciji nadzor, health check i tajne u trezoru svode se na nekoliko redaka u Program.cs:

builder.Configuration.AddAzureKeyVault(                 // tajne iz Key Vaulta umjesto iz appsettings.json
    new Uri("https://your-vault.vault.azure.net/"),
    new DefaultAzureCredential());

builder.Services.AddOpenTelemetry().UseAzureMonitor();  // zahtjevi, ovisnosti i iznimke u Application Insightsu
builder.Services.AddHealthChecks()
    .AddDbContextCheck<AppDbContext>();                 // može li aplikacija doći do svoje baze?

var app = builder.Build();

app.MapHealthChecks("/health");                         // adresa koju poziva provjera dostupnosti

Zatim odlučite: zadržati, modernizirati ili prepisati

Situacija Obično je ispravna odluka
Kod radi i poslovna logika je dobra Zadržati, održavati, poboljšavati usput
Radi, ali framework više nije podržan ili je svaka promjena spora Modernizirati korak po korak: nadogradnja, refaktoriranje, zamjena dijelova
Kod više ne odgovara tome kako posao funkcionira, a tehnologija je slijepa ulica Razmotriti prepisivanje, uz paralelni rad starog i novog

Potpuno prepisivanje rijetko je ispravan prvi odgovor. Baca godine popravljenih grešaka i rubnih slučajeva koje nitko nije zapisao i zamrzava razvoj na mjesece. Joel Spolsky je još 2000. prepisivanje od nule nazvao najgorom strateškom greškom koju softverska tvrtka može napraviti. To uglavnom i dalje vrijedi.

Znakovi upozorenja koji preuzimanje čine skupljim

  • samo kompajlirane datoteke, bez izvornog koda
  • produkcija ne odgovara repozitoriju
  • lozinke i ključevi commitani u repozitorij
  • nema backupa ili backupi koje nitko nikad nije vratio
  • jedan server s ručnim isporukama
  • framework bez podrške: .NET Core 3.1, .NET 5 do 7 ili .NET Framework bez plana
  • komercijalne komponente bez prenosivih licenci
  • vlastiti framework koji je razumio samo prethodni developer

Ništa od ovoga nije razlog za paniku. Svako od toga razlog je da za prvi tjedan predvidite više vremena.

Kako se ovdje više nikad ne naći

  • Računi za sve u vlasništvu tvrtke: kod, cloud, domena i e-mail adresa na koju su registrirani, s barem dva administratora.
  • Tajne u trezoru, a ne u kodu ili u nečijoj glavi.
  • Automatizirani build i isporuka, da izdavanje ne ovisi o nečijem laptopu.
  • README i upute za rad (runbook) koje je netko osim autora stvarno slijedio.
  • Za poslovno kritične sustave koje grade vanjski dobavljači, klauzula o pohrani izvornog koda kod treće strane (escrow) u ugovoru.

Koliko to traje

Za tipičnu poslovnu aplikaciju: osiguravanje pristupa traje nekoliko dana, popis stanja otprilike tjedan, a stabilizacija nekoliko tjedana. Ono što nađete prvi tjedan odlučuje o ostatku.

Izvori

© 2026 ProCoding — Sva prava pridržana.Impresum i privatnostSplit, Hrvatska