Migracija sa starog CMS-a na custom rešenje treba da se vodi kao kontrolisana promena sistema, a ne kao jednokratni eksport i import sadržaja. Pored tekstova i slika, potrebno je sačuvati ili planski promeniti URL-ove, metapodatke, odnose između sadržaja, korisničke dozvole, preusmerenja i tehničke signale koje pretraživači već poznaju.
Najbezbedniji pristup je da se pre razvoja napravi inventar postojećeg sajta, definiše novi content model, mapira svaki važan stari URL na odgovarajuću novu adresu i pripremi plan provere posle puštanja. Ako nova arhitektura treba da reši ograničenja postojećeg sistema, custom CMS rešenje treba projektovati oko stvarnih uredničkih i poslovnih tokova, a ne samo oko vizuelnog izgleda sajta.
Šta se zapravo migrira
Prvi korak je razdvajanje elemenata koji se često pogrešno posmatraju kao „sadržaj“. Migracija obično obuhvata najmanje četiri sloja:
- Sadržaj: stranice, članci, kategorije, proizvodi, reference, autori, taksonomije i prateća polja.
- Mediji: slike, dokumenti, video zapisi, alt tekstovi, nazivi fajlova i veze iz sadržaja.
- Identitet i struktura: slugovi, URL putanje, canonical oznake, meta podaci, breadcrumbs i interna povezanost stranica.
- Operativna pravila: statusi objave, zakazivanje, revizije, korisničke uloge, dozvole, forme, integracije i automatizacije.
Nije svaki element potrebno preneti jedan-na-jedan. Neke stare kategorije mogu se spojiti, deo sadržaja može biti arhiviran, a pojedina polja mogu dobiti drugačiji tip u novom sistemu. Važno je da svaka takva odluka bude zapisana. Bez migracione matrice tim teško može da utvrdi šta je preneto, šta je transformisano, a šta namerno izostavljeno.
Inventar pre migracije: polazna tačka za odluke
Pre nego što se napiše skripta za migraciju, napravite snimak postojećeg sistema. Izvezite URL, naslov, status, tip sadržaja, datum izmene, canonical adresu, robots direktive, broj internih linkova i, gde je dostupno, podatke o organskom saobraćaju ili spoljnim linkovima. Ovaj spisak ne služi samo za SEO; on pomaže da se otkriju poslovno važne stranice koje nisu očigledne u glavnom meniju.
Kako prioritizovati URL-ove
URL-ovi ne moraju svi imati isti tretman. Posebno označite:
- stranice koje su deo glavne navigacije ili ključnih korisničkih tokova;
- landing stranice koje se koriste u kampanjama ili prodajnim procesima;
- članke, vodiče i kategorije koje imaju relevantne spoljne linkove;
- URL-ove koji se pojavljuju u XML sitemapama, analitici, Search Console izveštajima ili internim dokumentima;
- stranice koje imaju formu, prijavu, preuzimanje dokumenta ili drugu funkcionalnu ulogu.
Niske vrednosti i duplikate ne treba automatski preusmeriti na početnu stranicu. Ako nema bliskog ekvivalenta, prikladnije rešenje može biti odgovarajući status da sadržaj više ne postoji. Preusmerenje treba da vodi na najbližu relevantnu novu adresu, a ne samo na stranicu koja je tehnički dostupna.
Content model pre prenosa podataka
Custom CMS je prilika da se sadržaj modeluje preciznije, ali i izvor novih problema ako se struktura definiše tek nakon početka importa. Za svaki tip sadržaja odredite obavezna polja, veze sa drugim entitetima, status životnog ciklusa, pravila objave i način prikaza na sajtu.
Na primer, „referenca“ može imati naslov, klijenta, industriju, opis izazova, rešeni problem, galeriju i povezanu uslugu. Ako su ti podaci na starom sajtu bili sabijeni u jedan HTML editor, migracija nije samo kopiranje teksta. Potrebno je odlučiti da li se postojeći sadržaj parsira u nova polja, ručno uređuje ili ostaje kao nestrukturirani tekst.
Detaljnije kriterijume za ovu fazu možete razraditi kroz vodič Content model u custom CMS-u: kako strukturirati podatke pre programiranja. Njegova vrednost u migraciji je u tome što povezuje poslovni model sadržaja sa budućim komponentama i uredničkim procesom.
Mapiranje polja
Napravite tabelu sa najmanje sledećim kolonama:
| Staro polje ili element | Novo polje | Pravila transformacije | Provera |
|---|---|---|---|
| Naslov | Title | Trimovanje, dozvoljena dužina i fallback pravilo | Ručno uzorkovanje |
| Stari slug | Slug | Očuvati gde je moguće ili generisati mapu preusmerenja | HTTP test i crawl |
| Glavna slika | Media reference | Preuzimanje fajla i povezivanje sa alt tekstom | Provera prikaza i URL-a |
| Autor | Author relation | Uparivanje naloga ili očuvanje prikaza autora | Kontrola stranica autora |
| HTML telo | Rich text ili blokovi | Čišćenje oznaka, linkova i embed elemenata | Vizuelna i HTML kontrola |
Ovakva matrica omogućava ponovljiv import. Ako se skripta menja, tim može da vidi da li je promenjeno pravilo za sve zapise ili samo korekcija pojedinačnog podatka.
URL-ovi, preusmerenja i SEO signali
Promena CMS-a sama po sebi ne zahteva promenu URL strukture. Ako su postojeće adrese čiste, razumljive i kompatibilne sa novom arhitekturom, njihovo očuvanje smanjuje broj promenljivih u projektu. Nova struktura može biti opravdana kada uklanja tehničke ostatke starog sistema, rešava nejasnu hijerarhiju ili podržava drugačiji model sadržaja, ali tada mora postojati potpuna mapa starih i novih adresa.
Mapa redirekcija
Za svaku staru adresu zabeležite cilj, tip preusmerenja i razlog. Uobičajeno je da se za trajno preseljen sadržaj koristi trajno server-side preusmerenje, ali konkretna implementacija zavisi od infrastrukture. Izbegavajte lance, na primer: stari URL vodi na privremeni URL, a on zatim na novu konačnu adresu. Svaki važan stari URL treba, kad god je moguće, da vodi direktno na konačni ekvivalent.
Ne testirajte samo početnu stranicu. Proverite stare članke, paginaciju, kategorije, fajlove, AMP ili druge istorijske varijante ako su postojale, kao i URL-ove sa velikim slovima, završnom kosom crtom ili starim parametrima. Preusmerenja treba testirati i nakon izmene server konfiguracije, CDN-a ili keširanja.
Canonical, robots i sitemap
Na novom sajtu proverite da canonical adrese pokazuju na odgovarajuću glavnu verziju, da robots direktive nisu slučajno preuzete iz staging okruženja i da XML sitemap sadrži samo URL-ove koje želite da budu otkrivene i indeksirane. Sitemap nije zamena za internu navigaciju ni za redirekcije; on je pomoćni signal za otkrivanje aktuelnih adresa.
Google u svojoj dokumentaciji za selidbu sajta sa promenom URL-ova preporučuje pripremu mape URL-ova, pravilna preusmerenja i praćenje ponašanja nakon lansiranja. I kada se domen ne menja, isti princip je koristan za migraciju CMS-a jer se često menjaju putanje, renderovanje ili tehnička pravila.
Faze migracije koje smanjuju rizik
1. Analiza i specifikacija
Definišite šta se prenosi, šta se transformiše, a šta se gasi. U ovoj fazi se potvrđuju tipovi sadržaja, URL politika, integracije, korisničke uloge, kriterijumi prihvatanja i plan povratka na staru verziju. „Radi na računaru developera“ nije dovoljan kriterijum; za svaki tok treba definisati očekivano ponašanje.
2. Razvoj migracionog sloja
Import je sigurniji kada je ponovljiv i idempotentan: ponovno pokretanje ne bi trebalo da pravi duplikate ili gubi postojeće izmene. Zabeležite identifikator izvornog zapisa, vreme importa, greške i preskočene stavke. Za velike baze koristite obradu u paketima i mogućnost nastavka nakon prekida.
3. Testni import
Ne počinjite kompletnim prenosom bez probnog uzorka. Izaberite reprezentativne stranice: jednostavan tekst, bogat sadržaj sa tabelama i slikama, zapis sa više odnosa, arhivirani sadržaj, zapis bez slike i stranicu sa specijalnim karakterima u slug-u. Posle importa proverite podatke u administraciji i na javnom prikazu.
4. Paralelna provera
Na staging okruženju uporedite stari i novi prikaz, ali pazite da testna verzija ne bude dostupna pretraživačima. Testirajte obrasce, pretragu, filtriranje, preglede po kategorijama, prijavu korisnika, uloge urednika i sve spoljne integracije. Posebno proverite da li se greške prikazuju korisniku bez izlaganja osetljivih tehničkih informacija.
5. Lansiranje
Napravite plan sa redosledom koraka i odgovornim osobama: zamrzavanje uredničkih izmena, poslednji eksport, import novih zapisa, promena konfiguracije, aktiviranje redirekcija, provera DNS-a ili proxy sloja i otvaranje pristupa crawlerima. Ako sadržaj ostane promenljiv do poslednjeg trenutka, uvedite delta import ili jasno definišite cut-off vreme.
6. Nadzor posle objave
Prvih dana proveravajte logove, 404 i 5xx odgovore, redirekcije, obrasce, ključne tokove i dostupnost medija. U Google Search Console pratite izveštaje o indeksiranju i eventualne probleme sa sitemapom. Dokumentacija o promeni sajta naglašava da se signalima posle migracije treba baviti kontinuirano, a ne samo na dan lansiranja.
Najčešći rizici i njihova kontrola
| Rizik | Kako nastaje | Kontrolna mera |
|---|---|---|
| Gubitak sadržaja | Import podržava samo osnovna polja ili prekid nije zabeležen | Brojanje zapisa, kontrolni uzorak, log grešaka i ponovljiv import |
| 404 stranice | Promenjeni slugovi nisu mapirani | Kompletna lista starih URL-ova i crawl nakon lansiranja |
| Duplikati | Više URL obrazaca prikazuje isti zapis | Jedinstvena canonical politika, konsolidacija putanja i test parametara |
| Blokirano indeksiranje | Staging robots pravilo ostane na produkciji | Provera robots.txt, meta robots direktiva i HTTP zaglavlja |
| Neispravne slike | Fajlovi nisu preneti ili su promenjene putanje | Provera svih media referenci i test nedostupnih resursa |
| Pogrešne dozvole | Uloge se kopiraju bez analize novog sistema | Test matrica uloga, najmanje privilegije i revizija pristupa |
| Gubitak uredničkih izmena | Promene nastaju između izvoza i lansiranja | Freeze period, delta import ili ručna evidencija izmena |
Korisnici, dozvole i bezbednost
Migracija naloga nije isto što i migracija sadržaja. Pre prenosa proverite koji korisnici zaista moraju imati pristup, da li se lozinke mogu bezbedno preneti, kako se tretiraju neaktivni nalozi i koji korisnici imaju privilegije za objavu, brisanje ili promenu konfiguracije. Ne kopirajte administratorske dozvole samo zato što su postojale u starom CMS-u.
Za praktičnu razradu ove teme koristan je vodič Uloge i dozvole u CMS-u: kako organizovati editor, reviewer i administrator pristup. Bezbednosni deo migracije treba povezati i sa autentikacijom, zaštitom sesija, validacijom uploadova, tajnama u konfiguraciji i hardeningom servera; širi pregled je dat u tekstu Bezbednost custom CMS-a: autentikacija, autorizacija i hardening.
Kako izgleda dobar plan povratka
Rollback nije samo čuvanje kopije starog sajta. Potrebno je znati kako se vraća aplikacija, baza, konfiguracija, DNS ili proxy rutiranje i kako se sprečava da se nove izmene izgube. Pre lansiranja odredite pragove za odluku: na primer, kritičan problem sa prijavom, plaćanjem, objavom ili velikim brojem nedostupnih stranica može zahtevati povratak, dok se manji urednički problem rešava hotfixom.
Stari sistem ne treba odmah obrisati. Održavajte ga u stanju iz kog je moguće proveriti podatke i vratiti servis, ali ograničite mogućnost paralelnog uređivanja nakon cut-off trenutka. Dokumentujte ko donosi odluku o rollbacku, koliko traje procena i kojim redom se proverava da je povratak uspešan.
Kada je migracija završena?
Migracija nije završena kada se nova početna stranica učita. Završena je kada su potvrđeni podaci, URL mapa, funkcionalni tokovi, korisničke dozvole, indeksabilnost i monitoring. Napravite završnu kontrolnu listu koja obuhvata:
- broj prenetih zapisa po tipu sadržaja i broj namerno izostavljenih zapisa;
- proveru najvažnijih starih URL-ova i direktnih preusmerenja;
- nasumičnu kontrolu sadržaja, slika, linkova i metapodataka;
- proveru canonical, robots i sitemap pravila;
- test formi, pretrage, prijave, objave i integracija;
- proveru dozvola po ulogama i uklanjanje nepotrebnih privilegija;
- praćenje grešaka, logova i izveštaja nakon lansiranja.
Ako se uz promenu CMS-a menja i kompletna prezentacija ili informacijska arhitektura, projekat može zahtevati zaseban plan za SEO migraciju sajta. Ako se, pak, paralelno redizajnira ili razvija potpuno nov sajt, kriterijume obima, komponenti i tehničke arhitekture treba uskladiti sa procesom izrade sajta, umesto da se migracija tretira kao naknadni tehnički dodatak.
Praktičan sledeći korak
Pre donošenja odluke o prelasku napravite tri dokumenta: inventar postojećih URL-ova i sadržaja, mapu polja između starog i novog sistema i listu testova za lansiranje. Ta tri dokumenta brzo pokazuju da li je najveći problem u podacima, strukturi URL-ova, uredničkom procesu ili infrastrukturi. Tek nakon toga ima smisla definisati obim custom rešenja, način importa i kriterijume prihvatanja.
