Uvod — šta je downtime i zašto matters

Downtime je svaka minuta u kojoj Vaš sajt nije dostupan posjetiocima. Tokom migracije WordPress sajta na novi hosting, downtime se tradicionalno dešava iz tri razloga: pogrešan redoslijed koraka, pogrešno podešeni DNS zapisi, ili pokušaj da se sve uradi „na brzinu" u jednoj sesiji.

Za portfolio blog sa 50 posjeta dnevno, 2 sata downtime-a nije drama. Ali za e-commerce sajt koji prodaje 500 KM dnevno — 2 sata je 40+ KM propuštenog prihoda plus klijenti koji vide „site unavailable" poruku i više se ne vraćaju. Za SaaS sajt ili B2B portal, downtime u radnim satima može pokrenuti reklamacije i narušavanje SLA-a.

Dobra vijest: uz pravilnu pripremu i staged DNS pristup, WordPress migracija može biti potpuno bez vidljivog downtime-a. Ovaj vodič Vas vodi kroz šest konkretnih koraka, sa fokusom na pristup koji 15+ godina radimo u praksi za naše klijente u Bosni i Hercegovini.

Priprema — prije nego što bilo šta dirate

Prije nego što pokrenete migraciju, imajte spremno:

Access podatke za stari hosting: SSH ili SFTP kredencijali, pristup bazi podataka (phpMyAdmin ili direktan MySQL), cPanel/kontrol panel kredencijali
Access podatke za novi hosting: isto kao gore + DNS zone access
WordPress admin kredencijale: treba Vam aktivan admin nalog
Dovoljno vremena: planirajte minimum 2-3 sata za mali sajt, 4-6 sati za sajt sa WooCommerce ili velikom bazom
Backup prostora: minimum 2x veličine Vašeg sajta slobodnog prostora lokalno
Najniži promet vremenski prozor: subota ujutro za većinu BiH biznisa, ili noć između 23:00-03:00 za e-commerce

Najvažnije: smanjite TTL DNS zapisa minimum 24 sata prije migracije. Ako je Vaš TTL trenutno 3600 sekundi (1 sat), promijenite ga na 300 sekundi (5 minuta). Ovo je ključno za staged DNS flip — bez ovoga, neki posjetioci će gledati star server još satima nakon DNS promjene.

Ako želite prvo razumjeti kako hosting i DNS rade kao cjelina, pregledajte i vodič šta je hosting. Taj kontekst posebno pomaže vlasnicima firmi koji migraciju delegiraju, ali žele kontrolu nad odlukama.

Step 1 — Puni backup WordPress-a

Nikada ne migrirajte bez pune kopije koja se može vratiti u roku od nekoliko minuta ako nešto krene po zlu.

Opcija A — plugin pristup (laičke prijateljsko): Koristite UpdraftPlus ili All-in-One WP Migration. UpdraftPlus je stabilniji za veće sajtove; All-in-One je jednostavniji za sajtove ispod 1 GB (veći zahtijevaju premium verziju). Plugin kreira arhivu koju skinete lokalno.

Opcija B — ručni pristup (za veće sajtove i developere): Preko SSH-a na starom serveru:

# Arhiviraj sve fajlove WordPress instalacije
cd /home/vasusername/public_html
tar -czvf wp-files-backup-$(date +%Y%m%d).tar.gz .

# Dump baze podataka
mysqldump -u DB_USER -p DB_NAME > wp-db-backup-$(date +%Y%m%d).sql

# Skinite lokalno preko SCP
scp user@stari-server:/home/vasusername/wp-*-backup-*.* ~/Desktop/

Ručni pristup je bolji jer ne zavisi od plugin verzije, PHP memory limit-a ili timeout-a. Za sajtove iznad 5 GB, ručni pristup je jedini razuman.

Nakon backup-a, testirajte ga. Otvorite arhivu, provjerite veličinu, pregledajte .sql fajl. Backup koji niste verifikovali nije backup.

Pre-migration audit (15 tačaka prije „go”)

Prije realnog prebacivanja uradite audit koji većina timova preskoči:

Verzija WordPress core-a i aktivne teme
Lista svih plugin-ova i da li su aktivni/licencirani
Veličina baze i najveće tabele
Cron zadaci (interni WP cron ili server cron)
SMTP konfiguracija i transakcijski mail provider
API integracije (payment, ERP, CRM, shipping)
Cache slojevi (plugin cache + server cache + CDN cache)
Redirect pravila i custom .htaccess rewrites
Security plugin pravila (IP whitelist, 2FA, reCAPTCHA)
SSL certifikat i SAN pokrivenost (www i non-www)
Robots/sitemap status
Search Console verifikacija
Monitoringi i alerting
Plan „ko je owner odluke“ kad nešto krene po zlu
Tačan rollback trigger (npr. checkout ne radi 10+ min)

Ovaj audit često otkrije da „migracija sajta“ zapravo nije samo kopiranje fajlova, nego koordinacija više servisa.

Step 2 — Setup WordPress na novom hostingu

Na novom hostingu (u macido Cloud Panel-u ili bilo kojem modernom panelu):

Kreirajte novu hosting tenant / account za Vaš domen
Dodajte privremeni hostname ili koristite hosts file trik (objasnjeno u Step 6)
Instalirajte čisti WordPress preko jednokličnog instalera
Kreirajte MySQL bazu — zapišite kredencijale (DB_NAME, DB_USER, DB_PASSWORD, DB_HOST)
Instalirajte istu PHP verziju kao na starom hostingu (ili novije — WordPress je backward-compatible)

Kritično: ne pokušavajte SSL u ovom koraku. SSL dolazi nakon DNS flip-a jer Let's Encrypt ne može izdati sertifikat za domen koji još ne pokazuje na ovaj server.

Step 3 — Transfer fajlova (FTP/SSH + rsync)

Najbrži i najpouzdaniji način je rsync između servera (ako oba imaju SSH):

# Sa novog servera, povuci fajlove sa starog
rsync -avz --progress user@stari-server:/home/vasusername/public_html/ /home/noviuser/public_html/

Ako nemate SSH na starom hostingu (shared hosting bez SSH pristupa), alternativa je:

Skinite backup arhivu lokalno preko FTP-a
Uploadujte na novi hosting preko SFTP-a
Extractujte na serveru preko kontrol panela ili SSH-a

Provjerite permissions. WordPress treba:

Fajlovi: 644
Direktoriji: 755
wp-config.php: 600 ili 640

find /home/noviuser/public_html -type f -exec chmod 644 {} \;
find /home/noviuser/public_html -type d -exec chmod 755 {} \;
chmod 600 /home/noviuser/public_html/wp-config.php

Step 4 — Transfer baze (mysqldump + import)

Uploadajte .sql backup na novi server, zatim importujte u novu bazu:

mysql -u NEW_DB_USER -p NEW_DB_NAME < wp-db-backup-20260422.sql

Za velike baze (iznad 500 MB), direktan MySQL import je značajno brži od phpMyAdmin import-a (koji ima timeout limite).

Ažurirajte wp-config.php sa novim kredencijalima baze:

define( 'DB_NAME', 'novo_ime_baze' );
define( 'DB_USER', 'novi_user' );
define( 'DB_PASSWORD', 'nova_sifra' );
define( 'DB_HOST', 'localhost' );

Step 5 — Search-replace URL-ova

Ovo je korak gdje većina amaterskih migracija pada. WordPress baza sadrži absolutne URL-ove — https://vasdomen.ba/... — serializovane u wp_options, wp_postmeta i na drugim mjestima. Ne možete ih jednostavno zamijeniti sa SQL REPLACE komandom jer serijalizovani stringovi imaju hardcoded brojače dužine.

Ispravan pristup — WP-CLI:

cd /home/noviuser/public_html
wp search-replace 'http://stari-url.ba' 'https://novi-url.ba' --dry-run
# Provjerite output, zatim uradite bez --dry-run:
wp search-replace 'http://stari-url.ba' 'https://novi-url.ba'

Ako ne možete koristiti WP-CLI, alternativa je plugin Better Search Replace (besplatan) — radi search-replace sa pravilnom deserijalizacijom.

Ovaj korak radite dok sajt još nije live na novom serveru — testirajte preko hosts file trika (Step 6).

Step 6 — DNS switch sa staged flip pristupom

Sada dolazi dio koji odvaja amatera od profesionalca.

Amaterski pristup: „Prebaciš DNS, pa čekaš". Rezultat: dok DNS propagira (1-24h), neki posjetioci vide stari server, neki novi, narudžbe se gube, mailovi se bounce-uju.

Pravilan pristup — staged flip:

24 sata prije: Smanjite TTL na 300 sekundi (vidi pripremu)
Testirajte novi server preko hosts file-a prije DNS promjene:

Na Windows-u (kao admin, edit C:\Windows\System32\drivers\etc\hosts):

123.45.67.89 vasdomen.ba www.vasdomen.ba

Gdje 123.45.67.89 je IP novog servera. Sada Vaš browser ide direktno na novi server, ali za ostatak interneta sajt i dalje radi na starom. Testirajte sve: prijave, login, kontakt formu, WooCommerce checkout, sve.

Kada ste potpuno sigurni: promijenite A zapis (i AAAA ako imate IPv6) u DNS-u da pokazuje na IP novog servera. Promjena propagira za 5-15 minuta zbog niskog TTL-a.
Ne mijenjajte MX zapise ako email ostaje na trenutnom provajderu — to je zasebna migracija.
Odmah nakon flip-a: izdajte Let's Encrypt SSL sertifikat za domen (sad kad domen pokazuje na novi server, ovo radi automatski).
Uklonite hosts file entry — sad gledate isti server kao i svi drugi.

Tokom staged flip-a nema prozora u kojem sajt ne radi — stari i novi server rade paralelno 15-30 minuta dok DNS propagira.

Rollback plan koji stvarno radi u 15 minuta

Mnogi napišu „imamo rollback“, ali ga nikad ne testiraju. Praktičan rollback plan mora biti izvršiv bez improvizacije:

Sačuvan stari server netaknut najmanje 72 sata
Export zadnje baze neposredno prije DNS switch-a
Snapshot DNS zapisa prije promjene
Jasna odluka ko vraća MX/A/AAAA zapise i ko potvrđuje povrat

Minimalni rollback scenarij:

Vratite A/AAAA zapise na stari server
Purge DNS cache gdje je moguće
Obavijestite tim i support da je rollback aktivan
Zamrznite nove deploy-e dok se ne izoluje root cause
Uzmite logove sa novog hosta prije bilo kakvog dodatnog „gašenja požara“

Ako imate webshop, rollback trigger treba biti strožiji: checkout, payment callback i order email moraju svi raditi. Dovoljan je jedan od ova tri da faila i već imate realan finansijski problem.

Problemi koji se mogu javiti i kako ih riješiti

Broken permalinks (404 na svim post-ovima): Idite na WP Admin → Settings → Permalinks → kliknite „Save Changes" (bez mijenjanja opcije). Ovo regeneriše .htaccess pravila.

Missing images / 404 na media fajlovima: Obično znači da wp-content/uploads/ folder nije potpuno prebačen ili ima pogrešne permissions. Ponovite rsync za taj folder specifično:

rsync -avz user@stari-server:/home/vasusername/public_html/wp-content/uploads/ /home/noviuser/public_html/wp-content/uploads/
chmod -R 755 /home/noviuser/public_html/wp-content/uploads/

Email deliverability problemi: Ako koristite WordPress za slanje mailova (kontakt forma, WooCommerce order confirmations), novi server ima drugi IP. Provjerite da li su SPF i DKIM zapisi ažurirani za novi izlazni mail server, ili koristite SMTP plugin (WP Mail SMTP) sa SendGrid/Postmark/macido Webmail SMTP kredencijalima.

SSL mixed-content warning: Znači da neki URL-ovi u bazi još uvijek imaju http:// umjesto https://. Pokrenite ponovo wp-cli search-replace ili Better Search Replace.

WooCommerce orders missing: Obično znači da je baza migrirana prije nego što su pristigle nove narudžbe, a DNS je već prebačen. Uvijek radite krajnji mysqldump neposredno prije DNS flip-a za transaction-heavy sajtove.

Plugin/tema incompatibility: Noviji hosting može imati noviju PHP verziju. Ako neki stari plugin puca, provjerite PHP compatibility u admin panelu i ažurirajte ga ili zamijenite alternativom.

Za tehničke reference tokom troubleshooting-a korisni su:

WooCommerce i „osjetljivi“ sajtovi: šta ne smijete preskočiti

Ako migrirate klasični korporativni sajt, rizik je manji. Ako migrirate WooCommerce, booking ili membership platformu, rizik je duplo veći jer svaka minuta utiče na narudžbe i korisničke naloge.

Kritične tačke:

Order state consistency: narudžbe koje stignu tokom propagacije moraju završiti u istom sistemu
Payment webhooks: Stripe/PayPal callback URL mora ostati validan i nakon prebacivanja
Session handling: cart sesije se ne smiju resetovati usred checkout-a
Transactional email: potvrde narudžbi i password reset mailovi moraju proći bez kašnjenja

Najsigurniji pristup je migration window izvan peak satnice + privremeni freeze marketing kampanja 2-4 sata prije i poslije DNS switch-a.

Ako tek planirate prelazak na online prodaju, korisno je prvo proći vodič kako napraviti web shop u BiH 2026, a za finansijski dio i očekivani trošak pogledajte koliko košta web stranica u BiH.

Post-launch kontrola prvih 24 sata

Čim DNS switch završi, posao nije gotov. Prvih 24 sata odlučuje da li je migracija stvarno uspješna ili ste samo „imali sreće“.

Kontrolni raspored:

T+15 min: homepage, login, checkout, kontakt forma
T+1h: order email i password reset email test
T+3h: server error log, PHP warning log, mail queue
T+6h: Google Search Console crawl test + sitemap fetch
T+12h: load test sa realnim scenarijima (cart + checkout + admin login)
T+24h: finalni report i zatvaranje migracijskog incidenta

Ako bilo koji kritični test padne, rollback odluka treba biti automatska, ne emocionalna. Najviše štete nastaje kada tim „još malo pokušava“ dok sajt polovično radi.

Koristan detalj: u prva 24 sata imenujte jednu osobu kao “incident owner”. Ta osoba odlučuje da li ostajete na novom hostu ili aktivirate rollback, umjesto da pet ljudi paralelno donosi različite odluke u stresu. Jedna jasna odgovornost smanjuje vrijeme reakcije i čuva tim od haosa.

Uz to, zapišite unaprijed i “go/no-go” kriterijume prije DNS prebacivanja. Kada su pravila jasna unaprijed, tim ne gubi vrijeme na raspravu u kritičnom trenutku i migracija ostaje pod kontrolom čak i ako se pojavi neplanirani edge case.

Takva priprema čini razliku između “srećne” i profesionalne migracije.

Upravo ta disciplina čuva prihode i reputaciju kada je promet najveći.

Bez toga, greške su skupe.

Plan spašava projekat, budžet i tim.

Najčešći edge-case problemi na velikim WordPress sajtovima

Na sajtovima sa većim prometom i složenijim plugin stack-om, javlja se par specifičnih problema:

MU-plugins i custom drop-in fajlovi nisu preneseni pa dio funkcija nestane
Object cache konflikt između starog i novog okruženja
Cron lock ostane aktivan i jobs se ne pokreću
Webhook timeout kod payment providera nakon promjene origin servera
Stale CDN cache servira staru verziju checkout skripti

Rješenje je da migration runbook uključuje i ove tačke, ne samo „fajlovi + baza“. Zato ozbiljna migracija izgleda kao mini-projekat, a ne kao jedan terminal command.

Ako želite lakši početak, najprije standardizujte hosting parametre preko wordpress hostinga, a tehnički minimum (DNS, backup, SLA) provjerite i u vodiču kako izabrati hosting u BiH.

SEO i analytics provjera poslije migracije

Mnogo timova tehnički “uspješno” migrira sajt, ali izgubi dio organskog prometa jer preskoči SEO i analytics kontrolu nakon DNS switch-a. Ovo je tih, skup problem jer ga primijetite tek nakon nekoliko dana.

Obavezno provjerite:

da su canonical URL-ovi ostali isti (www vs non-www)
da robots.txt nije slučajno blokirao crawl (Disallow: /)
da XML sitemap vraća 200 status i nove URL-ove
da Google Search Console i dalje vidi property bez greške
da su GA4 / Meta pixel / conversion eventi aktivni na novom hostu

Ako ste mijenjali i strukturu URL-ova, pripremite 301 redirect mapu prije migracije. Bez toga Google tretira stare URL-ove kao “nestale”, a novi URL-ovi kreću od nule. Za ozbiljnije sajtove vrijedi napraviti i kratki “post-migration SEO audit” 7 dana nakon prebacivanja, da uhvatite sve soft 404 i indexing anomalije dok je problem još svjež.

Praktično: migracija nije završena kad sajt “otvara”, nego kad tehnički, poslovni i SEO signali rade kao prije ili bolje.

macido migration service — kada ima smisla koristiti

Sve gore navedeno možete uraditi sami ako imate tehnički background i vrijeme. Međutim, za Vaš biznis je često ekonomski isplativije delegirati migraciju. Kao dio macido paketa, nudimo besplatnu WordPress migraciju za sve Business pakete i više.

Šta konkretno radimo:

Audit (1 dan): pregledamo Vaš sajt, dokumentujemo teme, plugin-ove, custom kod, bazu, mail konfiguraciju
Setup i transfer (1 dan): podesimo novi hosting, povučemo fajlove i bazu, uradimo WP-CLI search-replace, testiramo na staging URL-u
DNS flip (30 min): koordinišemo staged DNS prebacivanje u terminu koji Vama odgovara (obično subota ujutro)
Post-migration check (1 dan): provjera SSL-a, permalinks-a, WooCommerce-a, mail-a, brzina load-a

Zero downtime garantovan. Ako migracija ne uspije — vraćamo na stari server i ne plaćate ništa.

Checklista post-migration

Nakon DNS flip-a, prođite:

CTA

Migracija WordPress sajta ne mora biti stresna. Ako želite da to uradimo za Vas — bez downtime-a, bez gubitka podataka, bez stresa:

Radimo u Bosni i Hercegovini već 15+ godina. Znamo razliku između „samo prebacili fajlove" i „pravilne migracije sa staged DNS-om".

WordPress migracija na novi hosting bez downtime-a