Attól, hogy fejlesztőt váltasz, még nem kell újraépíteni a weboldaladat. Először azt érdemes kipróbálni, hogy az új szakember a meglévő anyagokból működő példányt tud-e készíteni, el tud-e végezni egy kisebb módosítást, le tudja-e tesztelni a fontos ügyfélfolyamatot, és vissza tud-e állni egy hibás közzététel után. Ezek többet mondanak, mint egy jól kinéző képernyőkép vagy egy azonnali ajánlat az újraépítésre.

Első lépésként körülhatárolt átvételi felmérést kérnék. Ebből derüljön ki, mi maradhat, mit kell javítani, és mi az, amit még nem tudunk. Egy hiányzó hozzáférés más feladat, mint egy olyan rendszer, amelyben a következő fontos igény már csak aránytalan munkával oldható meg.

Tisztázd, valójában min változtatnál

Válaszd külön, ki gondozza a weboldalt, hol fut, és mit kell tudnia a vállalkozás számára. Lehet, hogy csak új karbantartóra van szükséged, miközben a tárhely és a megjelenés marad. Előfordulhat, hogy egyetlen szolgáltatást kell lecserélni. Az is lehet, hogy a következő üzleti igény már nagyobb átalakítást indokol.

Írd le konkrétan, miért váltanál. Például: „Olyan fejlesztőt keresünk, aki hozzá tud adni egy magyar szolgáltatási oldalt, és karban tartja a foglalási kapcsolatot.” Ez egy lehetséges feladatleírás, nem ügyféleredmény. Az új fejlesztő ebből már tudja, mit kell megvizsgálnia.

Sorold fel azt is, minek kell folyamatosan működnie az átállás alatt: a közzétett oldalaknak, a megkeresések fogadásának, a foglalásnak, a rendeléseknek és a munkatársak belépésének. Az új dizájn külön döntés. Ha arra is szükséged van, az átvételi felmérés mellé használd a weboldal-megújításhoz készített briefvázlatot.

A működő rendszert térképezzétek fel

Jelszólista helyett az éles weboldal működéséből indulj ki. A jelenlegi szolgáltatóval és a saját csapatoddal ezeket azonosítsátok:

  • Az éles változat: a nyilvános cím, a használt platform vagy kódtár, valamint a jelenleg közzétett verzió.
  • Az üzemeltetési fiókok: domainregisztráció, DNS-beállítások, tárhely, tartalomszerkesztés és a megújítások felelősei.
  • A kapcsolódó szolgáltatások: a ténylegesen használt űrlapok, e-mail-küldés, foglalás, fizetés, analitika és CRM-kapcsolat.
  • A helyreállításhoz szükséges anyagok: forrásfájlok, tartalom- és adatexportok, feltöltött képek és dokumentumok, mentések és visszaállítási útmutató.
  • A módosítás menete: hogyan lesz a szerkesztésből előnézet, majd éles változat, ki hagyja jóvá, és hogyan lehet visszaállni az előző verzióra.

Minden tételnél külön jelöld, hogy „azonosítva”, „hozzáférés ellenőrizve” vagy „kipróbálva”. Attól, hogy valaki tudja a tárhelyszolgáltató nevét, az új csapat még nem biztos, hogy közzé tud tenni egy módosítást. A kódtár tartalmáról is ellenőrizni kell, hogy megfelel-e a működő weboldalnak.

Egyeztesd a szolgáltatóval, melyik fiók felett ki rendelkezik majd, és milyen licenc- vagy átadási korlátok vannak. Az adminisztrátori hozzáférés és az egyes anyagok újrafelhasználásának engedélye külön kérdés. A nyitott pontokat írjátok le; egy letöltött mappa önmagában nem rendezi őket.

Egy kisebb módosítással próbáljátok ki az átvételt

Az új fejlesztő a kapott útmutató alapján készítsen elkülönített tesztpéldányt, megfelelő próbaadatokkal. A tesztmegkeresések, fizetési műveletek és automatikus üzenetek ne érjenek el valódi ügyfeleket. Az éles értesítéseket véletlenül kiküldő előnézet nem megfelelő próbakörnyezet.

Olyan visszafordítható módosítást válasszatok, amely jellemző a várható munkára. Kétnyelvű szolgáltatói oldalnál lehet ez egy leírás átírása mindkét nyelven, a hozzá tartozó ajánlatkérési út ellenőrzésével. Rendelési rendszerben egyeztessetek olyan próbát, amely az érintett termék- és rendelési lépéseket ügyfélterhelés nélkül ellenőrzi.

Az átvevő fejlesztő ezeket tudja bemutatni:

  • Az előnézet a megfelelő verziót mutatja, a fontos oldaltípusokkal és a hozzájuk tartozó fájlokkal együtt.
  • A megbeszélt módosítás a szokásos összeállítási vagy közzétételi folyamat után is megmarad.
  • Az érintett ügyfélfolyamat mobilon is működik, és hiba esetén érthető visszajelzést ad.
  • A vállalkozás megtalálja a tesztmegkeresést vagy bejegyzést a megbeszélt helyen.
  • Az előző változat leírt eljárással visszaállítható; ha a tárolt adatok is változnak, azok helyreállítására külön terv van.

Ez célzott átvételi próba, nem teljes biztonsági vagy minőségi audit. Jegyezzétek fel, mire terjedt ki, és mire nem. Ha közben csak szóbeli segítséggel lehetett továbblépni, az új fejlesztő egészítse ki az útmutatót a hiányzó tudnivalókkal.

Miért kevés, ha megnyílik a főoldal?

A saját portfólióoldalam jó példa erre. Az angol és magyar oldalak egy összeállítási folyamat során készülnek el, és az alkalmazásba épített kapcsolat szolgálja ki őket. A kapcsolati űrlap külön szerveroldali végpontot és e-mail-szolgáltatást használ. A látható főoldal reprodukálása önmagában még nem ellenőrzi a megkeresések útját.

Ezért ennél az oldalnál egy közzétett tartalmi módosítást és a kapcsolati űrlap integrációját is bemutattatnám az átvevővel. A próba a tényleges felépítést követi, nem áll meg annál, hogy „betölt a weboldal”.

Ugyanez az elv érvényes a portfóliómban szereplő MarciCRM feladataira is: az ingatlanos megkeresések naptárakkal és utánkövetéssel kapcsolódnak össze. Az átvevő fejlesztőnek ezeket a kapcsolatokat is meg kellene vizsgálnia, nem csak a képernyőket. Ez a termék ellenőrzött feladatkörét írja le, nem egy már lezajlott szolgáltatóváltást.

Ha a megkeresések útja már most hibás, azt külön vizsgáljátok ki. Ehhez segítséget ad az írásom arról, mit ellenőrizz, ha az űrlap sikert jelez, de nem érkezik e-mail.

Nézd meg, mit tartalmaz az export

Ez platformonként eltér. A Webflow kódexportja például nem tartalmaz működő CMS-t vagy webáruház-rendszert, és az exportált űrlapok beküldésfeldolgozása sem marad működőképes. Ha máshol szeretnéd futtatni a fájlokat, ezekhez pótlásra lehet szükség. Más a feladat, ha az új fejlesztő a meglévő platformon folytatja a munkát. A Webflow kódexport-dokumentációja.

A WordPress adatbázismentése nem tartalmazza a sablonokat, bővítményeket, feltöltött fájlokat és konfigurációs fájlokat. A helyreállításhoz az adatbázis mellett az érintett fájlokról is gondoskodni kell. A WordPress útmutatója az adatbázis mentéséhez.

Kérd meg a szolgáltatót, hogy magyarázza el a ti exportotok korlátait, és mutassa be a tervezett visszaállítás vagy továbbfejlesztés menetét. Egy ZIP-fájl méretéből nem derül ki, hogy teljes-e az átadás. A platformtól való függés sem indokol automatikusan újraépítést: elfogadható lehet, ha a vállalkozás tovább tud működni, és a szükséges módosítások elvégezhetők.

A hozzáféréseket is nézzétek át

Egy fiók vagy kódtár átadása nem feltétlenül szünteti meg a régi jogosultságokat. A GitHub dokumentációja szerint a kódtár áthelyezésekor a korábbi közreműködők hozzáférése megmaradhat, ahogy a hozzá kapcsolt webhookok, titkos adatok és telepítési kulcsok is. Az átadás után külön ellenőrizni kell a hozzáféréseket és integrációkat. A GitHub útmutatója a kódtárak átadásához.

A titkos értékeket ne írjátok az átadási jegyzetbe. A céljuk, biztonságos tárolási helyük és felelősük szerepeljen benne. Mindenki csak a szükséges hozzáférést kapja meg, a kulcsok cseréjét pedig a rájuk épülő szolgáltatásokkal együtt tervezzétek meg. Az OWASP is a szükséges jogosultságokra korlátozott hozzáférést és a kulcscserék függőségeinek dokumentálását javasolja. Az OWASP útmutatója a titkos adatok kezeléséhez.

Tervezett átadásnál egyezzetek meg, mikor szűnik meg a korábbi szolgáltató hozzáférése, és ki segít az átmeneti időszakban. Ne mondjatok le egy szolgáltatást pusztán azért, mert nem világos a szerepe: előbb derüljön ki, mi függ tőle. Feltételezett illetéktelen hozzáférés esetén külön incidenskezelés szükséges, nem ez a szokásos átadási sorrend.

A feltárt tények alapján válaszd ki a következő munkát

A felmérés végén ilyen következtetést kérnék:

  • Folytatható a karbantartás: a lényeges próba sikerült, a hozzáférések rendezettek, és a következő feladat elvégezhető a jelenlegi rendszerben.
  • Átvétel előtt javítás kell: a rendszer használható, de előbb meg kell oldani egy konkrét hibát, például a sikertelen összeállítást vagy a dokumentálatlan integrációt.
  • Egy rész cseréje indokolt: egy szolgáltatás akadályozza a szükséges munkát, miközben a weboldal többi része megtartható.
  • Érdemes megvizsgálni az újraépítést: a felmérés konkrét korlátokat nevez meg, és összeveti a megtartás, illetve a csere költségét. Az, hogy „másik keretrendszerben szeretek dolgozni”, önmagában kevés bizonyíték.

A javaslat tartalmazza a nyitott kérdéseket, a következtetést alátámasztó tényeket, az egyszeri feladatokat és a rendszeres költségeket. Derüljön ki, ki kezeli a hibákat és a későbbi frissítéseket. Az a fix karbantartási ajánlat, amely tisztázatlan közzétételi folyamatra épül, még nem igazán összehasonlítható.

Ha az URL-eknek is változniuk kell, külön költözési tervre van szükség. A Google útmutatója a régi és új címek megfeleltetését, átirányításokat és utánkövetést ír le, és jelzi, hogy a költözés alatt változhatnak a helyezések. Ennek legyen kimondott oka és meghatározott feladatköre a szolgáltatóváltáson belül. A Google útmutatója webhelyek költöztetéséhez.

Mit küldj el, mielőtt átvételi ajánlatot kérsz?

Küldd el a nyilvános webcímet, a fejlesztőváltás okát, a következő szükséges módosítást, az ismert platformot és a rendelkezésre álló hozzáférések titkos adatokat nem tartalmazó listáját. Írd le a fontos integrációkat, határidőket és azt is, mit adott már át a jelenlegi szolgáltató. Ami nem ismert, maradjon nyitott kérdés.

Írj a meglévő weboldaladról a kapcsolati oldalon, a hello@davidbuka.com címre. Először meghatározhatjuk, milyen ellenőrzések alapján érdemes a karbantartás, javítás vagy csere mellett dönteni. Az első megkereséshez nincs szükség jelszavakra vagy ügyféladatokra.

A forrásokat 2026. október 28-án ellenőriztem. A javasolt próba egy lehetséges felmérés, nem beszámoló ügyféleredményről. A borítókép saját szerkesztőségi illusztráció.