Modernizacija legacy sistema i starih aplikacija

Modernizacija legacy sistema je način da poslovanje zadrži softver na koji se kupci već oslanjaju, a zamijeni runtime, framework i navike deploymenta zbog kojih je svaka izmjena skupa. Narudžbe, nalozi i sadržaj ostaju dostupni. Dijelovi koji blokiraju nadogradnju PHP-a, novi checkout ili sigurniji hosting mijenjaju se u koracima, uz rollback ako se korak pokvari.

Sadržaj

U CodeWizu modernizujemo WordPress i WooCommerce sajtove, Laravel i obične PHP aplikacije, Node.js API-je i frontende koji uz njih idu. Popišemo šta sistem zaista radi, to ponašanje učvrstimo testovima, nadogradimo runtime i frameworke, pomjerimo hosting i ostavimo deploy koji vaš tim može ponoviti. Gdje bi potpuno prepisivanje bacilo logiku koja radi, tu logiku zadržavamo i mijenjamo platformu ispod nje.

Usluga je za kompanije čiji sajt još radi na verziji PHP-a bez sigurnosnih zakrpa, čiji su prvobitni programeri otišli, ili čija prodavnica ne može primiti novi način plaćanja jer je platforma ispod nje zamrznuta. Namijenjena je i timovima koji žele bolje performanse i čistiju sigurnost, a da naredne mjesece ne vežu za prepisivanje u jednom koraku.

Modernizacija: Fasada zgrade prekrivena zelenom zaštitnom mrežom skele tokom renoviranja

Migracija sistema koja drži poslovanje online

Migracija sistema prebacuje aplikaciju sa servera, operativnog sistema ili arhitekture na kojoj je zaglavila, na infrastrukturu kojom se zaista može upravljati. Poslovni uslov je kontinuitet: katalozi, korisnički nalozi, narudžbe i urednički sadržaj moraju preživjeti selidbu, a javni URL-ovi koji već rangiraju moraju i dalje raditi.

Migracija koju možemo vratiti

Popis aplikacija, cron poslova, uploada, sesija, redova i integracija koje zovu unutra ili van, uključujući one koje niko nije dokumentovao.
Staging kopija vraćena iz stvarnog backupa, tako da proba koristi podatke oblika produkcije, a ne igračku bazu.
Plan prelaska sa prozorom zamrzavanja ili replikacijom, prebacivanjem DNS-a ili proxyja, i vremenski ograničenim rollbackom koji je isproban prije lansiranja.
Sesije, fajlovi i keš prebačeni na dijeljeno ili objektno skladište kada više od jednog aplikativnog servera služi promet.
Logovanje i provjera dostupnosti na mjestu prije prebacivanja, tako da je prvi sat novog okruženja vidljiv.

Mnogim sistemima treba samo novi VPS, aktuelna Linux slika i deploy koji se može ponoviti. Drugima kontejneri pomognu kada nekoliko verzija PHP-a ili Node.js-a mora živjeti jedno pored drugog. O deploymentu na DigitalOceanu, AWS-u, Hetzneru i bare metalu pisali smo za timove koji biraju gdje će taj novi dom biti. Selidba se proba prije nego što se produkcijski DNS promijeni.

Nadogradnja tehnologije: PHP, frameworki i frontend

Nadogradnja tehnologije dovodi jezik, framework i frontend build na verzije koje i dalje dobijaju zakrpe. Uobičajeno polazište je aplikacija zaključana na staro izdanje PHP-a jer je plugin, ekstenzija ili neprovjeren kutak koda pao pri prvom pokušaju pomjeranja. Nadograđujemo jednu major verziju po jednu, a kapija su testovi — postojeći ili novi, koji fiksiraju današnje ponašanje.

Sloj	Uobičajeno polazište	Gdje je vodimo	Glavni rizik
PHP runtime	PHP 7 ili rana instalacija 8.0	Izdanje koje i dalje dobija sigurnosne zakrpe	Uklonjene ekstenzije i sintaksa između verzija
Framework	Stari Laravel, Symfony, CodeIgniter ili vlastiti MVC	Održavano izdanje, jedna major verzija po jedna	Izmjene u auth-u, redovima, mailu i fajl sistemu
WordPress	Zastarjeli core i napušteni plugini	Aktuelni core, plugini zamijenjeni ili izolovani	Plugin koji radi samo na starom PHP-u
Frontend	jQuery stranice ili ostarjeli webpack build	Vite, ili šabloni na serveru gdje SPA nije potreban	Vizuelne regresije na šablonima koje niko nije naveo
Baza podataka	MySQL 5.7 ili stari MariaDB	MySQL 8 ili aktuelni MariaDB	SQL mode, charseti i rezervisane riječi
Node.js	Nepodržana major verzija	Aktivni LTS, uz ponovnu izgradnju lockfilea	Nativni addoni i lomovi prelaznih zavisnosti

Rector i statički analizator kao što je PHPStan hvataju mehaničke lomove u PHP-u prije nego što stignu do browsera.
Laravel i Symfony aplikacije prate zvanične vodiče za nadogradnju, i svaka major verzija se merguje tek kada kritične putanje prođu.
WordPress nadogradnja kreće od liste plugina i tema: sve napušteno se zamijeni, fork-uje ili ubaci u kod prije nego što se core pomjeri.
Dozvoljena verzija PHP-a provjerava se u CI-ju, prema listi na stranici podržanih verzija na php.net, tako da budući deploy ne može skliznuti nazad na nepodržan runtime.

<?php
if (PHP_VERSION_ID < 80300) {
    fwrite(STDERR, "This application requires PHP 8.3 or newer.\n");
    exit(1);
}

Poboljšanje performansi na starijem kodu

Poboljšanje performansi na legacy aplikaciji obično dolazi od nekoliko koncentrisanih popravki. Stari kod skuplja N+1 upite, nedostajuće indekse, slike u rezoluciji fotoaparata i posao koji teče unutar web zahtjeva, a mogao bi biti queue job.

Spori upiti se izmjere, pa poprave indeksom, eager loadingom ili prepisanim upitom. Baza dobija explain plan.
Keš cijele stranice i fragmenata — Varnish, Redis ili CDN — stoji ispred stranica koje su iste za većinu posjetilaca.
Slike se smanjuju i serviraju u modernom formatu, a prvi ekran više ne čekaju skripte koje šablonu ne trebaju.
Email, generisanje PDF-a, uvozi i drugi spor posao idu u queue, tako da browser dobije odgovor dok se posao završava.
Pretraga koja je bila težak LIKE upit može preći na poseban engine. U tekstu o Typesense pretrazi za starije projekte opisana je ta podjela.

Pratimo Largest Contentful Paint, Interaction to Next Paint i vrijeme odgovora servera prije i poslije, istim pristupom kao u radu na rezultatu 100/100 za performanse stranice. Googleova objavljena granica za dobar LCP je ispod 2.5 sekunde.

Dugačak prolaz sa crnim serverskim ormarima u svijetlom modernom data centru

Sigurnosna poboljšanja legacy aplikacija

Sigurnosna poboljšanja zatvaraju rupe koje se nakupe kada aplikacija prestane dobijati ažuriranja. Nepodržan PHP, nezakrpani plugini, admin URL na otvorenom internetu i tajne commitovane prije godina obični su nalazi. Tretiramo ih kao dio modernizacije, jer je brža aplikacija na napuštenom runtimeu i dalje obaveza.

Runtime, CMS, plugini i Composer ili npm zavisnosti prelaze na verzije koje i dalje dobijaju sigurnosne zakrpe. composer audit i npm audit poslije toga rade u CI-ju.
Pregledaju se autentifikacija i kolačići sesije: HttpOnly, Secure, SameSite, hashiranje lozinki i skladište sesija koje preživi drugi aplikativni server.
Forme dobijaju CSRF zaštitu, upiti ostaju parametrizovani, a uploadi se provjeravaju po tipu i čuvaju van javnog web korijena.
Admin i debug površine ograničene su mrežom ili dodatnom prijavom, a listing direktorija i opširne greške u produkciji ostaju isključeni.
Sigurnosna zaglavlja i HTTPS postavljaju se na proxyju. Stare kopije sajta na zaboravljenim poddomenima uklanjaju se ili preusmjeravaju, da ne serviraju zastario, ranjiv kod.

Modernizacija je dobar trenutak da se rotiraju lozinke baze, API ključevi i tajne plaćanja, i da se čitaju iz okruženja umjesto iz fajla u Gitu. Kada nalazi traže dublju procjenu, nju dogovaramo posebno.

Modernizacija legacy sistema: koji put izabrati

Postoje četiri praktična puta, a pravi zavisi od toga koliko je ponašanje isprepleteno i koliko poslovanje može čekati na vrijednost. Najčešće koristimo strangler fig obrazac Martina Fowlera: novi kod preuzima jednu rutu po jednu, stara aplikacija zadržava ostatak, a proxy odlučuje koja strana odgovara.

Put	Rizik zastoja	Kada stiže vrijednost	Odgovara kada
Strangler fig	Nizak	Nakon prvog zamijenjenog toka	Sistem mora ostati živ dok se dijelovi mijenjaju
Replatform	Srednji	Na prelasku	Ponašanje je zdravo, a platforma je problem
Omot API-jem	Nizak	Kada krene novi kanal	Novoj aplikaciji ili izlogu trebaju podaci, a jezgro može čekati
Prepisivanje	Visok	Na kraju	Opseg je mali, ili se model podataka ne može sačuvati

# one section moves to the new app; everything else stays
location /account/ {
    proxy_pass http://new_app;
}
location / {
    proxy_pass http://legacy_app;
}

Mala aplikacija bez testova i sa modelom podataka koji se opire svakoj funkciji može biti jeftinija za ponovnu izgradnju nad istom bazom nego za zamjenu rutu po rutu. Velika prodavnica sa godinama narudžbi je suprotan slučaj: modernizacija legacy sistema u koracima štiti prihod dok se rizični kutovi mijenjaju. Nakon popisa preporučujemo kraći siguran put, i reći ćemo kada je prepisivanje taj put.

Podaci, URL-ovi i integracije tokom selidbe

Podaci i javni URL-ovi su ono što kupci i pretraživači primijete. Kod se može zamijeniti dvaput; izgubljene narudžbe ili pokvaren rang mnogo se teže vraćaju.

Izmjene šeme idu obrascem expand-contract: doda se nova kolona ili tabela, uradi backfill, prebace se čitanja i pisanja, pa se stari oblik obriše tek kada novi kod odradi u produkciji.
URL-ovi ostaju isti gdje je sadržaj isti. Svaki promijenjeni URL dobija 301 redirect, a stara i nova sitemap se uporede prije lansiranja.
Uvozi iz servisa za plaćanje, ERP-a i dostave popisuju se sa vlasnicima, pa se ponovo puste na staging. Idempotentni endpointi čuvaju da ponovljeni poziv ne napravi drugu narudžbu.
Urednički sadržaj, podaci o proizvodima i korisnički nalozi broje se prije i poslije migracije, da se tiho sječenje vidi.
Kratko zamrzavanje ili prozor kašnjenja replikacije dogovara se sa ljudima koji primaju narudžbe, da prelazak ne prepolovi uplatu.

Modernizacija legacy sistema: česte greške

Početak prepisivanja bez popisa, pa otkriće da stari sistem šalje fakture, razgovara sa kurirskom službom i u cron poslu preračunava porez.
Skok kroz nekoliko PHP ili Laravel major verzija u jednoj grani, tako da sve greške stignu odjednom i ne mogu se prepoloviti.
Nadogradnja WordPress corea dok napušteni plugin i dalje vraća staru verziju PHP-a.
Promjena URL-ova tokom obnove, uz nadu da će se rang u pretrazi sam vratiti.
Uploadi i sesije na lokalnom disku jednog servera, pa njihov gubitak onog dana kada se doda drugi server.
Projekat proglašen gotovim na dan prelaska, bez plana za sljedeću sigurnosnu zakrpu.

Od čega zavisi cijena projekta modernizacije

Opseg se dovoljno razlikuje da procjenu dajemo nakon kratkog audita. Pokretači cijene obično su vidljivi već pri prvom pogledu na repozitorij i server:

Veličina koda i to da li automatski testovi opisuju ponašanje koje mora ostati.
Koliko verzija runtime i framework moraju preći, i koliko napuštenih plugina stoji na putu.
Obim podataka, zastoj koji poslovanje prihvata i broj vanjskih sistema koji razmjenjuju narudžbe ili kupce.
Da li se javni dizajn mijenja u istom projektu, ili je rad ograničen na ponašanje i platformu.
Jedan prelazak naspram strangler programa koji mijenja jedno područje po objavi, plus ko rezultat održava poslije.

Građevinski radnik ojačava stare temelje tokom podzemnog renoviranja stanice

Kako radimo

Upoznavanje: čitamo kod, server i integracije, i zapišemo šta mora nastaviti raditi, uključujući poslove koji teku kada niko ne gleda.
Plan: biramo put, ciljnu verziju PHP-a ili Node.js-a, redoslijed koraka i rollback, i sa vama dogovaramo opseg.
Izrada: dodajemo testove koji fiksiraju ponašanje, nadograđujemo malim mergevima i gotove korake usmjeravamo na novi kod kroz proxy ili feature flag.
Testiranje: uporedimo kritične tokove sa starim sistemom, provjerimo redirecte, pokrenemo vraćanje backupa i prođemo sigurnosne stavke iznad.
Puštanje: prelazimo u probi izvedenom prozoru, pratimo greške i vrijeme odgovora i držimo staru verziju spremnu da ponovo primi promet.
Podrška: predajemo bilješke o deploymentu i ostajemo za sljedeće nadogradnje, da se stack ne zamrzne opet za šest mjeseci.

Zašto CodeWiz

Već gradimo na ovim stackovima: WordPress, WooCommerce, Laravel, PHP i Node.js su svakodnevni posao, pa nadogradnja polazi od toga kako se kod zaista ponaša.
Open-source na prvom mjestu: PHP, Laravel, MariaDB, Redis, Varnish i Cloudflare, bez vezivanja modernizacije za vlasničku platformu.
Put prema riziku: replatform, strangler ili malo prepisivanje, izabrani jer odgovaraju sistemu.
Performanse i sigurnost zajedno: isti angažman koji pomjera runtime pokriva i keš, upite, zaglavlja i napuštene plugine.
Fer cijene: vrhunski razvoj bez vrhunskih cijena, iz Banje Luke, uz rad na daljinu sa klijentima iz regiona i svijeta. Više o CodeWizu.

Često postavljana pitanja

Koliko košta modernizacija legacy sistema?

Zavisi od veličine koda, pokrivenosti testovima koju već imate, broja integracija i toga da li mijenjamo platformu ili ponašanje. Nadogradnja jedne uredne Laravel aplikacije mnogo je manji projekat od strangler pristupa na vlastitoj prodavnici sa desetak vanjskih sistema. Procjenu dobijate nakon audita, prije početka rada.

Da li prepisivati ili modernizovati na mjestu?

Modernizujte na mjestu kada su poslovna pravila vrijedna, a platforma je problem. Prepišite kada je aplikacija mala, bez testova i otporna na izmjene, ili kada model podataka ne može ponijeti sljedeći proizvod. Većini sistema koje viđamo bolje služi strangler ili replatform nego prepisivanje od temelja.

Može li se PHP nadograditi bez prepisivanja aplikacije?

Često može. Pomjeranje jedne major verzije po jednu, uz Rector, statičku analizu i testove oko kritičnih putanja, dovoljno je za velik dio WordPress, Laravel i običnog PHP koda. Plugin ili vlastita ekstenzija ponekad se moraju zamijeniti jer ne mogu raditi na podržanom PHP-u. To je lokalna popravka, a ne prepisivanje poslovne logike.

Koliko traje modernizacija?

Pomjeranje runtimea i hostinga za jednu aplikaciju, uz probani prelazak, često traje nekoliko sedmica. Strangler program koji redom mijenja checkout, nalog i katalog traje duže, jer se svaki korak objavi i prati prije sljedećeg. Audit daje redoslijed koji možete isplanirati.

Hoće li modernizacija naštetiti SEO-u?

SEO strada kada se URL-ovi promijene bez redirecta ili kada novi šabloni isporuče lošiji HTML i sporije stranice. URL-ove držimo stabilnim, 301 redirect dodajemo gdje je izmjena neizbježna, upoređujemo sitemape i Core Web Vitals tretiramo kao dio objave. Pretraživači tada vide isti sadržaj na bržem odgovoru.

Šta ako prvobitnih programera više nema?

To je često polazište. Popis, testovi koji fiksiraju ponašanje i staging vraćen iz backupa način su na koji sistem upoznajemo. Nedokumentovani cron poslovi i integracije upravo su ono što faza upoznavanja treba naći, prije bilo kakvog produkcijskog prelaska.

Spremni da modernizujete sistem koji već imate?

Recite nam na čemu aplikacija radi, čega se ne usuđujete dotaći i šta poslovanju treba dalje. Modernizacija legacy sistema koju predložimo ima rollback. Kontaktirajte nas da razgovaramo o projektu, ili pogledajte naše usluge modernizacije legacy sistema.

Modernizacija legacy sistema i starih aplikacija