Kako izvršiti migraciju servera? Prenos web stranice bez gubitka podataka

Migracija servera (prenos) je planski proces prebacivanja datoteka web stranice, baze podataka, email naloga, DNS zapisa i aplikativnih podešavanja sa postojećeg na novi server. Osnovni metod za prenos stranice bez gubitka podataka je sljedeći: prvo se napravi potpuni backup, novi server se pripremi sa istim ili novijim verzijama softvera, prebace se datoteke i baza podataka, izvrši se testiranje putem hosts datoteke ili privremenog URL-a, DNS usmjeravanje se promijeni sa niskim TTL-om, a nakon migracije se provjeravaju logovi, forme, tokovi plaćanja, isporuka emailova i SEO signali.

Migracija servera nije jednostavan proces kopiranja i lijepljenja. Naročito za WordPress, WooCommerce, Laravel, prilagođene PHP aplikacije, visokoprometne news portale ili firme koje koriste poslovni email, pogrešna migracija može dovesti do gubitka narudžbi, oštećenih lokalnih karaktera, 500 grešaka, SSL upozorenja, prekida email komunikacije i pada vidljivosti na pretraživačima. Zbog toga se plan migracije mora sprovesti uz tehničku kontrolnu listu i povratni scenario.

U ovom vodiču ćemo korak po korak obraditi kako izvršiti promjenu hostinga ili servera u skladu sa SEO i performansnim očekivanjima za 2026. godinu. Također ćemo se dotaknuti različitih scenarija poput cPanela, Pleska, VPS-a, cloud servera i ručne migracije; podijelit ćemo primjenjive savjete o trajanju DNS propagacije, obuhvatu backupa, kompatibilnosti baze podataka, instalaciji SSL-a i SEO provjerama nakon prenosa.

Kada je potrebna migracija servera?

Prenos web stranice na novi server obično proizlazi iz potrebe za boljim performansama, sigurnošću, smanjenjem troškova ili skalabilnošću. Na primjer, korporativna stranica sa 5.000 mjesečnih posjetitelja može nesmetano raditi na shared hostingu, dok e-commerce stranica sa 20.000 dnevnih posjeta može imati probleme sa CPU limitom, sporim upitima i timeout-om na stranici za plaćanje. U tom trenutku se bira jači hosting paket, VPS ili cloud infrastruktura.

Uobičajeni signali koji ukazuju na potrebu za migracijom servera su:

• Vrijeme učitavanja stranice prelazi 3 sekunde i pogoršavaju se metrike Core Web Vitals.
• Često dostizanje limita CPU-a, RAM-a, inode-a ili diska u hosting panelu.
• Potreba za novijim verzijama komponenti kao što su PHP, MySQL, MariaDB, Node.js ili ionCube.
• Učestali problemi sa SSL obnavljanjem, isporukom emailova ili DNS upravljanjem.
• Nezadovoljavajući kvalitet podrške, backupa ili nivo sigurnosti kod postojećeg provajdera.
• Naglo povećanje prometa na stranici tokom kampanja, reklama ili sezonskih perioda.

Ako vaša stranica raste i približava se granicama trenutnog paketa, mnogo je sigurnije napraviti kontrolisani plan migracije nego vršiti prenos u kriznom trenutku. U zavisnosti od vaših potreba, možete uporediti web hosting paketi, VPS serverska rješenja ili Korporativni Hosting opcije kako biste odabrali pravu infrastrukturu.

Priprema prije migracije: Najkritičnija faza

Većina projekata migracije sa gubitkom podataka ne propadne tokom samog prenosa, već zbog nedostatka pripreme. Prije početka migracije treba napraviti inventar postojeće stranice i razjasniti koji će se podaci prenositi i koji su servisi osjetljivi na prekid rada.

1. Napravite inventar stranice

Prvi korak je kreiranje tehničke mape web stranice. Treba zabilježiti korišteni CMS ili framework, PHP verziju, tip baze podataka, veličinu diska, email naloge, cron zadatke, DNS zapise, SSL certifikat, posebna preusmjeravanja i integracije sa trećim stranama. Na primjer, kod WordPress stranice nije dovoljno prenijeti samo wp-content folder; potrebno je provjeriti i .htaccess pravila, wp-config.php podešavanja, prefikse tabela baze podataka, cache dodatke i medijske datoteke.

Kod e-commerce stranice dodatno treba ispitati infrastrukturu za plaćanje, integraciju dostave, sinhronizaciju zaliha, ERP konekciju, SMTP servis i webhook URL adrese. Ako nakon migracije ne pristižu narudžbe, problem često nije u prenosu datoteka, već u zaboravljenom API IP ograničenju ili sigurnosnom pravilu definisanom na starom serveru.

2. Uzmite potpuni backup i provjerite ga

U procesu migracije servera, samo uzeti backup nije dovoljno; mora se potvrditi i da se backup može vratiti. Potpuni backup treba da obuhvati sljedeće komponente:

• Datoteke web stranice: public_html, aplikativni folderi, upload direktoriji, teme i datoteke dodataka.
• Baze podataka: MySQL, MariaDB, PostgreSQL ili druge baze koje aplikacija koristi.
• Email podaci: sandučići, preusmjeravanja, filteri, podešavanja automatskog odgovora.
• DNS zapisi: A, AAAA, CNAME, MX, TXT, SPF, DKIM, DMARC zapisi.
• Konfiguracije: .htaccess, nginx.conf, php.ini, cron job, environment datoteke.
• SSL certifikati i posebna sigurnosna pravila.

Kao praktičan pristup, prije migracije uzmite najmanje dvije kopije backupa: jednu čuvajte na postojećem serveru, a drugu na drugoj lokaciji. Kod velikih stranica za backup datoteka može se koristiti rsync, za bazu podataka mysqldump ili alati za backup iz panela. Za baze podataka veće od 10 GB, kompresovani i podijeljeni backupi mogu biti sigurniji od dumpa u jednom dijelu.

3. Unaprijed smanjite DNS TTL vrijednost

Dobra je praksa smanjiti TTL vrijednost 24 sata prije migracije kako bi se DNS promjena brzo proširila. Na primjer, ako je TTL vrijednost 14400 sekundi, neki korisnici mogu satima nastaviti pristupati starom serveru. Smanjenje TTL-a na 300 sekundi prije migracije čini DNS prelazak kontrolisanijim. Nakon što je migracija završena i sve provjereno, TTL se može ponovo povećati na 3600 ili 14400 sekundi.

Redovno upravljanje DNS-om vašeg domena direktno utiče na uspjeh migracije. Za konfiguraciju domena i DNS-a možete pogledati vodiče za pretraga domena i upravljanje domenama.

Poređenje metoda migracije servera

Ne postoji univerzalno najbolji metod migracije za svaku stranicu. Mala korporativna stranica se lako može prenijeti putem panela, dok visokoprometna e-commerce stranica može zahtijevati postepenu sinhronizaciju i mod održavanja.

Prilikom odabira nove infrastrukture, gledati samo prostor na disku može biti pogrešno. Kriteriji poput broja PHP workera, CPU jezgri, RAM-a, NVMe diska, učestalosti backupa, lokacije data centra, podrške za LiteSpeed ili Nginx, WAF i DDoS zaštite također određuju performanse. Zbog toga prelazak na najjeftiniji paket bez analize potreba može uskoro stvoriti potrebu za novom migracijom.

Kako izvršiti migraciju servera korak po korak?

Korak 1: Pripremite novi server

Na novom serveru treba instalirati operativni sistem, web server, PHP verziju, servis baze podataka i potrebne module. Za WordPress se preporučuje PHP 8.2 ili 8.3, aktuelni MariaDB, OPcache i odgovarajuća vrijednost memory_limit-a. Kod frameworka poput Laravela potrebno je posebno podesiti Composer, cron, queue worker i dozvole za storage. Ako PHP dodaci koji rade na starom serveru ne postoje na novom, nakon prenosa stranice može se pojaviti bijeli ekran ili 500 greška.

Na sigurnosnoj strani treba konfigurisati politiku SSH porta, jake lozinke, firewall, skeniranje malware-a i automatska ažuriranja. Postavljanje sigurnosne osnove dok je novi server prazan, prije migracije, lakše je nego kasnije intervenisati. Ako vam je potreban SSL, obavezno uključite temu Instalacija SSL certifikata u plan migracije.

Korak 2: Prenesite datoteke

Za prenos datoteka, u zavisnosti od veličine stranice, može se koristiti FTP, SFTP, SSH, rsync ili panelni backup. Kod malih stranica dovoljno je kreirati kompresovanu arhivu i otvoriti je na novom serveru. Kod velikih stranica preporučuje se prvo kopiranje putem rsync-a, a zatim druga sinhronizacija neposredno prije DNS promjene. Ovaj metod štedi vrijeme, posebno kod stranica gdje se upload folder stalno mijenja.

Nakon prenosa datoteka provjerite dozvole. Generalno, folderi rade sa dozvolama 755, a datoteke 644; međutim, potrebe svake aplikacije mogu biti različite. Osjetljive datoteke poput wp-config.php, .env ili slične ne bi trebale biti čitljive svima. Također, pobrinite se da su kopirane i skrivene datoteke, odnosno datoteke poput .htaccess i .user.ini.

Korak 3: Prenesite bazu podataka

Prenos baze podataka je najosjetljiviji dio prevencije gubitka podataka. Prvo se uzme dump sa starog servera, a zatim se na novom serveru kreiraju baza i korisnik. Ako je moguće, set karaktera treba postaviti na utf8mb4. Da bi se spriječilo oštećenje lokalnih karaktera, tokom izvoza i uvoza mora se očuvati ista collation struktura.

Kod stranica koje generišu podatke u realnom vremenu, poput WooCommerce-a ili članskih sistema, tokom migracije se može koristiti mod održavanja. U suprotnom, tokom DNS propagacije neki korisnici mogu upisivati podatke na stari, a neki na novi server. To stvara nekonzistentnost u narudžbama, komentarima, zapisima formi ili članskim informacijama. Kod kritičnih stranica, posljednji dump baze treba uzeti nakon uključivanja moda održavanja.

Korak 4: Ažurirajte konfiguracijske datoteke

Ime baze, korisničko ime, lozinka, informacije o hostu i putanje datoteka moraju se urediti prema novom serveru. Za WordPress se provjerava wp-config.php, za Laravel .env, a za prilagođene aplikacije config.php ili slične datoteke. Ako ostanu apsolutne putanje datoteka, IP adrese, SMTP podešavanja ili cache direktoriji sa starog servera, stranica može izgledati kao da radi, ali u pozadini stvara greške.

Također, vrijednosti PHP memory_limit, upload_max_filesize, post_max_size i max_execution_time treba podesiti prema potrebama vaše aplikacije. Na primjer, ako upload limit ostane 32 MB u admin panelu koji učitava slike proizvoda od 200 MB, operacija se ne može nastaviti iako je migracija uspjela.

Korak 5: Testirajte prije promjene DNS-a

Najsigurnija praksa migracije je testiranje stranice na novom serveru prije promjene DNS-a. Da biste to uradili, možete mapirati svoj domen sa IP adresom novog servera u hosts datoteci na svom računaru. Na taj način, dok posjetitelji i dalje vide stari server, vi testirate novi server sa pravim imenom domena.

Test lista treba da uključuje sljedeće provjere:

• Da li se otvaraju početna stranica, kategorije, proizvodi, blog i kontakt stranice?
• Da li rade slanje formi, prijava članova, reset lozinke i tok plaćanja?
• Da li se slike, CSS i JavaScript datoteke učitavaju u potpunosti?
• Da li se admin panel otvara bez greške?
• Da li je SSL certifikat instaliran za ispravan domen?
• Postoje li 404, 500, mixed content greške ili petlje preusmjeravanja?
• Da li su robots.txt, sitemap.xml i canonical tagovi ispravni?

Korak 6: Instalirajte SSL certifikat

Na modernim web stranicama SSL nije obavezan samo zbog sigurnosti, već i zbog SEO-a i povjerenja korisnika. Ako se DNS promijeni bez instaliranog SSL-a na novom serveru, korisnici mogu vidjeti upozorenje "nije sigurno". Zbog toga SSL certifikat treba pripremiti neposredno prije ili istovremeno sa DNS prelaskom. Besplatni certifikati poput Let’s Encrypt mogu biti dovoljni za mnoge stranice; međutim, za korporativne projekte koji primaju plaćanja mogu se preferirati SSL opcije sa višim nivoom validacije.

Nakon SSL-a, pobrinite se da se HTTP adrese preusmjeravaju na HTTPS putem 301, da nema mixed content grešaka i da su u mapi stranice prisutni HTTPS URL-ovi. Za SSL proizvode i opcije instalacije možete pogledati stranicu SSL certifikati.

Korak 7: Promijenite DNS zapise

Nakon uspješno završenih testova, na DNS strani se A zapis usmjerava na IP adresu novog servera. Ako se i email servis prenosi na isti server, moraju se ažurirati i MX, SPF, DKIM i DMARC zapisi. Ako email ostaje kod drugog provajdera, MX zapise ne treba dirati. Jedna od najčešćih grešaka je slučajna promjena email zapisa prilikom prenosa samo web stranice, što prekida mail promet.

DNS propagacija se obično završava u roku od nekoliko minuta do 24 sata. Ako je TTL unaprijed smanjen, većina korisnika će brzo pristupiti novom serveru. U ovom procesu nemojte odmah gasiti stari server. Sigurna praksa je držati ga dostupnim najmanje 48 sati, a po mogućnosti 72 sata.

Korak 8: Obavite posljednju sinhronizaciju i provjeru logova

Nakon DNS promjene treba provjeriti da li ima novih podataka upisanih na stari server. Posebno treba uporediti narudžbe, kontakt forme, korisničke registracije i komentare. Access log i error log datoteke web servera pomažu da se shvati koje IP adrese šalju zahtjeve na koji server.

Unutar prva 24 sata nakon migracije treba pratiti 500 greške, porast 404 grešaka, spore upite, CPU skokove i email redove. Ako se ove provjere ne izvrše, stranica može izgledati kao da radi, ali u pozadini može doći do gubitka konverzija.

Profesionalna kontrolna lista za prenos stranice bez gubitka podataka

Kontrolna lista ispod pokriva tačke koje u praksi najčešće uzrokuju probleme. Označavanje ove liste prije i poslije migracije ozbiljno smanjuje rizik migracije.

• Vrijeme migracije je isplanirano u satima niskog prometa.
• Uzet je potpuni backup datoteka, baze, emailova i DNS-a.
• Testirano je da se backup može otvoriti i vratiti.
• DNS TTL vrijednost je smanjena najmanje 24 sata ranije.
• PHP, baza podataka i potrebni moduli su pripremljeni na novom serveru.
• Datoteke su u potpunosti prenesene i provjerene su dozvole.
• Potvrđena je usklađenost seta karaktera i collation-a baze podataka.
• Config datoteke su ažurirane prema informacijama novog servera.
• Testiranje je obavljeno putem hosts datoteke prije puštanja u produkciju.
• SSL je instaliran, provjerena su HTTPS preusmjeravanja.
• DNS A, AAAA, MX, TXT zapisi su ispravno ažurirani.
• Stari server je ostavljen aktivan najmanje 48 sati.
• Praćeni su Google Search Console, Analytics i log zapisi.

Provjere nakon migracije da ne bi došlo do SEO gubitka

Migracija servera teoretski ne bi trebala uzrokovati SEO gubitak sve dok se struktura URL-a ne mijenja. Međutim, u praksi sporost, 404 greške, pogrešan robots.txt, nedostatak SSL-a ili greške u preusmjeravanju mogu uticati na rangiranje. Zbog toga je SEO provjera nakon prenosa jednako važna kao i tehnička migracija.

Provjera URL-a i preusmjeravanja

Ako ne mijenjate strukturu URL-a prilikom prenosa stranice, potreba za 301 preusmjeravanjem je minimalna. Međutim, ako se istovremeno mijenjaju domen, struktura permalinkova ili foldera, stari URL-ovi se moraju preusmjeriti na nove ekvivalente putem 301. Privremeno 302 preusmjeravanje nije prikladno za trajni prenos SEO signala. Na primjer, ako je stara stranica /proizvod/abc premještena na novu adresu /prodavnica/abc, treba napraviti direktno preusmjeravanje; preusmjeravanje svih starih URL-ova na početnu stranicu negativno utiče na korisničko iskustvo i SEO performanse.

Provjera Robots.txt i Sitemap-a

Ako je tokom testiranja korišten Disallow u robots.txt da bi se blokirali pretraživači, to se mora ukloniti prilikom puštanja u produkciju. Ova greška je jedan od najklasičnijih uzroka gubitka indeksa nakon migracije. U datoteci mape stranice trebaju se nalaziti novi HTTPS URL-ovi i treba je ponovo poslati putem Google Search Console-a.

Performanse i Core Web Vitals

Čak i ako je novi server jači, pogrešno podešavanje cache-a može smanjiti performanse. LiteSpeed Cache, Redis, OPcache, CDN i optimizacija slika moraju biti ispravno konfigurisani. Tokom prve sedmice nakon migracije treba pratiti PageSpeed Insights, Chrome UX Report i serverske logove kako bi se provjerilo da li je došlo do pogoršanja u metrikama LCP, INP i CLS. Za poboljšanje performansi hostinga možete koristiti sadržaje o Optimizacija brzine WordPress-a.

Stvari na koje treba obratiti pažnju tokom prenosa emaila

Kod mnogih migracija stranica, web datoteke se prenesu bez problema dok se email aspekt previdi. Ako se emailovi čuvaju na postojećem serveru, sandučići, korisničke lozinke, preusmjeravanja i filteri moraju se prenijeti. IMAP sinhronizacija je pouzdan metod za prebacivanje mailova iz starog sandučeta u novi.

Na DNS strani, MX zapis određuje mail server, SPF ovlaštenje za slanje, DKIM potpisivanje, a DMARC politiku domena. Ako su ovi zapisi pogrešno konfigurisani, emailovi mogu završiti u spam folderu ili biti potpuno odbijeni. Nakon migracije treba poslati testne emailove na Gmail, Outlook i poslovne mail naloge i provjeriti informacije u mail headeru.

Česte greške pri migraciji servera

Zajednička tačka uspješnih projekata migracije je prevencija jednostavnih grešaka. Greške navedene ispod su najčešći problemi:

• Vršenje migracije bez uzimanja backupa ili bez testiranja backupa.
• Promjena IP-a bez prethodnog smanjenja DNS TTL vrijednosti.
• Gašenje starog servera prije završetka DNS propagacije.
• Pogrešan prenos seta karaktera baze podataka i oštećenje lokalnih znakova.
• Zaboravljanje .htaccess ili nginx pravila preusmjeravanja.
• Preusmjeravanje HTTPS prometa na novi server bez instaliranog SSL-a.
• Pogrešno ažuriranje email MX i TXT zapisa.
• Ostavljanje cache dodatka sa putanjom starog servera.
• Nepraćenje Search Console-a i logova nakon migracije.

Naročito kod stranica sa aktivnom prodajom, migraciju ne treba raditi tokom radnog intenziteta radnim danima, već u vremenskom intervalu kada su promet i obim narudžbi najniži. Kod velikih e-commerce projekata, planiranje prozora održavanja od 15-30 minuta sprječava nekonzistentnosti podataka koje mogu nastati u pozadini.

Kada potražiti profesionalnu podršku za migraciju?

Ručno prenijeti jednostavnu prezentacionu stranicu je moguće; međutim, u nekim situacijama je traženje profesionalne podrške jeftinije i sigurnije. E-commerce stranice sa visokim mjesečnim prometom, kompanije sa velikim brojem email naloga, portali koji koriste prilagođeni softver, visokoprometni medijski sajtovi i firme koje čuvaju podatke podložne regulaciji spadaju u ovu grupu.

U profesionalnoj podršci za migraciju, proces se obično sastoji od preliminarne analize, backupa, postavljanja testnog okruženja, prenosa, DNS prelaska, validacije i koraka praćenja. Na taj način se ne prenose samo datoteke, već i kontinuitet poslovanja. Ako planirate preći na Hostragons infrastrukturu, možete pogledati stranicu Hostragons rješenja za hosting kako biste zajedno procijenili opcije hostinga, domena i SSL-a prikladne vašim potrebama.

Zaključak: Planirana migracija servera sprječava prekid i gubitak podataka

Migracija servera nije operacija koje se treba plašiti kada se pravilno isplanira. Ključ uspjeha je ne preskakati korake potpunog backupa, pravilne pripreme servera, plana DNS TTL-a, testnog okruženja, instalacije SSL-a, email provjera i praćenja nakon prenosa. Naročito kod stranica gdje se baza podataka stalno mijenja, posljednja sinhronizacija i mod održavanja igraju kritičnu ulogu.

Ukratko, da biste prenijeli stranicu bez gubitka podataka, ne žurite, provjerite svaki korak i nemojte odmah gasiti stari server. Ako želite obnoviti svoju infrastrukturu i ponuditi brže i sigurnije web iskustvo, možete istražiti hosting, domen i SSL rješenja na Hostragons-u i mirno i kontrolisano kreirati plan prelaska koji odgovara vašim potrebama.

Često postavljana pitanja

Koliko dugo traje migracija servera?

Trajanje varira u zavisnosti od veličine i složenosti stranice. Mala WordPress stranica može se prenijeti za 30-60 minuta, dok kod velikih e-commerce ili korporativnih projekata sa mnogo emailova proces, uključujući pripremu, testiranje i DNS propagaciju, može trajati 1-3 dana.

Hoće li moja stranica biti nedostupna tokom migracije servera?

Pravilnim planiranjem prekid se može svesti na nekoliko minuta ili ga korisnici možda uopće neće osjetiti. Da bi se to postiglo, DNS TTL treba unaprijed smanjiti, novi server testirati prije puštanja u produkciju, a stari server držati uključenim dok se DNS propagacija ne završi.

Koji je najvažniji korak da ne dođe do gubitka podataka?

Najvažniji korak je potvrđeni potpuni backup. Datoteke, baza podataka, email i DNS zapisi moraju biti backupirani; posebno kod stranica koje generišu podatke o narudžbama ili članstvu, posljednji backup baze treba uzeti nakon uključivanja moda održavanja.

Da li migracija servera utiče na SEO rangiranje?

Ako se struktura URL-a očuva, stranica radi brzo, a SSL i preusmjeravanja su ispravno izvedeni, sama migracija servera ne uzrokuje SEO gubitak. Međutim, 404 greške, pogrešan robots.txt, spor server ili neispravna 301 preusmjeravanja mogu negativno uticati na rangiranje.

Da li se i email nalozi prenose tokom migracije servera?

Ako se emailovi nalaze na starom hostingu, moraju se posebno prenijeti. Treba provjeriti sandučiće, preusmjeravanja, filtere i MX, SPF, DKIM, DMARC zapise. Ako email ostaje kod drugog provajdera, MX zapisi se ne smiju mijenjati.