--- title: "Mit kérdezzen egy felhőmigrációs partnertől aláírás előtt?" description: "Kérdések egy felhőmigrációs partnernek aláírás előtt: leltár, alkalmazásonkénti stratégia, landing zone és biztonság, átállás és visszaállás, költség, átadás." canonical: https://sdk.enterprises/hu/insights/questions-before-hiring-a-cloud-migration-partner language: hu --- # Mit kérdezzen egy felhőmigrációs partnertől aláírás előtt? Frissítve: 2026-09-26 > Mielőtt szerződést köt egy felhőmigrációs partnerrel, kérdezze meg, hogyan leltározza fel, amit üzemeltet, hogyan választ migrációs stratégiát az egyes alkalmazásokhoz, hogyan tervezi meg és védi a célkörnyezetet, hogyan teszi visszafordíthatóvá az egyes átállásokat, hogyan mutatja meg a költségeket, és hogyan készíti fel a csapatát az eredmény üzemeltetésére. A konkrét, írásos válaszok többet elárulnak az Ön előtt álló migrációról, mint a napidíj. ## Kérdezze meg, hogyan derítik ki, mit üzemeltet valójában Egy migrációs terv csak annyira jó, amennyire a mögötte álló leltár. Kérdezze meg a partnert, hogyan állítja össze: az alkalmazásgazdákkal készített interjúkból, infrastruktúra-adatokból, például szervermetrikákból és hálózati kapcsolatokból, magából a kódból, vagy mindháromból. A meglévő dokumentáció kiindulópont, nem bizonyíték, mert idővel eltávolodik attól, ami valójában fut. Kérdezze meg, mit rögzít majd a leltár, és ki lesz utána a gazdája. Egy jó válasz megnevezi a mezőket, és megerősíti, hogy a leltár Önnél marad, bármit is dönt később. - Minden alkalmazás, az üzleti gazdája és a kritikussága - Futtatókörnyezetek, keretrendszerek és operációs rendszerek, külön jelölve mindent, aminek lejárt a támogatása - Adatbázisok, megosztott fájltárak, ütemezett feladatok és üzenetsorok, amelyektől az egyes alkalmazások függenek - Integrációk mindkét irányban, azokkal együtt, amelyeket senki nem dokumentált - Hardverhez vagy processzorszámhoz kötött licencek, amelyek nem feltétlenül vihetők át a felhőbe - Elfogadható leállási idő és az üzleti naptár: hónapzárás, főszezon, szabályozói határidők ## Alkalmazásonkénti stratégiát várjon, ne egyet a teljes állományra Az alkalmazások különböző módokon költöznek a felhőbe. A szokásos lehetőségek: az alkalmazás változatlan áthelyezése (rehost, lift and shift), kisebb módosításokkal, például menedzselt adatbázissal történő átültetése (replatform), átalakítása a felhőszolgáltatások használatára (refactor), lecserélése egy SaaS-termékre, egyelőre a helyén hagyása, vagy kivezetése. Az a partner, amely mindenre egyetlen megközelítést javasol, nem nézett elég alaposan utána. Kérdezze meg, milyen kritériumok alapján választanak, és kérje, hogy aláírás előtt mutassák be ezek alkalmazását három-négy saját alkalmazásán. Az, ahogyan a valódi rendszereiről gondolkodnak, többet elárul egy módszertani diánál. Külön kérdezzen rá, hogyan kezelik a lejárt támogatású futtatókörnyezeteken futó alkalmazásokat, mert ezek változatlan áthelyezése a régi kockázatokat is átviszi az új platformra. ## Tudja meg, ki tervezi meg és ki védi a landing zone-t A landing zone az előkészített célkörnyezet: fiókstruktúra, identitás- és hozzáférés-kezelés, hálózat, naplózás, titkosítás és azok a védőkorlátok, amelyeket minden alkalmazás örököl. Egy itt elkövetett hiba minden ráköltöző alkalmazásban megismétlődik. Kérdezze meg, ki tervezi, kódként definiálják-e, például Terraformmal, és átnézi-e a biztonsági csapata, mielőtt az első alkalmazás átköltözik. A felhőbiztonság megosztott felelősség. A szolgáltató védi az alapul szolgáló infrastruktúrát, Ön pedig felelős marad azért, hogyan konfigurálja és használja. Kérdezze meg a partnert, mely kontrollokat állítja be ő, melyek maradnak az Ön csapatánál, és hogyan adják meg, naplózzák és vonják vissza a végén a saját mérnökeik hozzáférését. - Környezetenként külön fiókok vagy projektek, elszigetelt éles környezettel - Egyszeri bejelentkezés (SSO) névre szóló felhasználókkal és minimális jogosultságú szerepkörökkel, közös adminisztrátori hitelesítő adatok nélkül - Központi naplózás és auditnaplók, amelyeket a projekt mérnökei nem tudnak kikapcsolni - Alapértelmezett titkosítás tároláskor és átvitel közben, a titkos adatok a kódon kívül - Olyan régiók, amelyek megfelelnek az adatok tárolási helyére és a GDPR-ra vonatkozó kötelezettségeinek ## Kérje, hogy vezessenek végig egy átálláson és egy visszaálláson Az átállás az a pillanat, amikor a forgalom és az adatok átkerülnek az új környezetbe, és ez az a pont, ahol a migráció az üzlet számára a leglátványosabb. Kérje meg a partnert, hogy lépésről lépésre vezessen végig egy átálláson az egyik alkalmazásánál: hogyan szinkronizálják az adatokat, hogyan irányítják át a forgalmat, milyen ellenőrzések futnak utána, és ki dönti el, hogy sikerült. Aztán kérdezze meg, hogyan lépnének vissza. Egy hiteles terv megnevezi a visszaállást kiváltó feltételeket, a döntést meghozó személyt, és azt, hogy meddig marad elérhető a régi környezet. Ha a felhasználók az átállás óta adatokat írtak az új környezetbe, kérdezze meg, hogyan kerülnek vissza ezek az adatok a régibe. A gyenge tervek átsiklanak e kérdés felett. A több száz régi alkalmazás AWS-re migrálásáról szóló cikkünk bemutatja, hogyan válnak ezek a lépések runbookokká egy nagy alkalmazásállományban. ## Ragaszkodjon ahhoz, hogy lássa a költségeket, mielőtt megérkezik az első számla A felhőköltségek másként viselkednek, mint egy adatközpont költségei. Azért fizet, ami fut, beleértve a tesztkörnyezeteket, amelyeket senki nem kapcsolt ki, a folyamatosan növekvő tárhelyet és a szolgáltató hálózatából kifelé irányuló adatforgalmat. Kérjen alkalmazásonkénti költségbecslést, írásban rögzített feltételezésekkel, és kérdezze meg, hogyan veti össze a partner az első hónapokban a tényleges használattal. A költségek átláthatósága tervezési döntés, nem havi jelentés. Kérjen címkézési szabályokat, amelyek minden erőforrást egy alkalmazáshoz és egy gazdához kötnek, költségkereteket és riasztásokat az első naptól, és a példányméretek felülvizsgálatát, miután az alkalmazások valós terhelés alatt futottak. Ha a felhőszervereket a régi hardverhez méretezik, azzal biztosan olyan kapacitásért fizet, amelyet senki nem használ. ## Figyelmeztető jelek, hogy egy migrációs ajánlat még nem kész Bármelyikre lehet magyarázat. Ha ugyanabban az ajánlatban több is előfordul, az általában azt jelenti, hogy a kockázatok felderítését Önre hagyták. - Rögzített ütemterv, mielőtt bárki látta volna a leltárát - Egyetlen migrációs stratégia minden alkalmazásra - Nincs írásos visszaállási terv, vagy a visszaállás a mentések nyomás alatti visszatöltésén múlik - A felhőfiókok, az infrastruktúrakód vagy a pipeline-ok a partner, nem pedig az Ön tulajdonában vannak - Feltételezések nélküli költségbecslések, címkézési és költségkeret-terv nélkül - Az utolsó hétre ütemezett tudásátadás ## A tudásátadást az első héttől tervezze, ne az utolsóra hagyja A migráció véget ér, a platform üzemeltetése nem. Kérdezze meg, hogyan tanulja meg a csapata üzemeltetni azt, ami elkészül: közös munkával valódi feladatokon a migráció alatt, runbookokkal az ismétlődő műveletekhez, és a monitorozás és a riasztások bemutatásával azoknak, akik ügyeletet tartanak majd. Kérje, hogy kezdettől minden az Ön fiókjaiban és repositoryjaiban legyen: az infrastruktúrakód, a pipeline-ok, a runbookok és az ábrák. Aztán egyezzenek meg, hogyan veszik át az átadást, például úgy, hogy a csapata a partner segítsége nélkül telepít és állít vissza egy alkalmazást. Részt vettünk abban a csapatban, amely a Crédit Agricole 600+ belső alkalmazását költöztette régi virtuális gépekről az AWS-re, és ezek közül 50+ migrációt mi magunk szállítottunk le. Ha második véleményre van szüksége egy migrációs ajánlatról, vagy egy csapatra, amely a munka egy részét elvégzi, felhőinfrastruktúra-mérnökeink végigveszik Önnel ezeket a kérdéseket. ## A legfontosabbak - Kérdezze meg, hogyan készül és hogyan ellenőrzik a leltárt, mert minden becslés és migrációs hullám erre épül. - Alkalmazásonként választott migrációs stratégiát várjon, olyan kritériumokkal, amelyeket a saját rendszerein alkalmazva is láthat. - A landing zone legyen kódként definiálva, a biztonsági csapata nézze át, és az Ön fiókjaiban legyen. - Ne fogadjon el olyan átállási tervet, amelyben nincs megnevezett visszaállási feltétel, és nincs mód az átállás után írt adatok visszanyerésére. - A címkézésről, a költségkeretekről és az átadás elfogadásának módjáról az első alkalmazás költözése előtt állapodjanak meg. ## GYIK ### A felmérést végző partner migrálja is az alkalmazásállományunkat? Megteheti, és ez gyakran időt takarít meg, mert a leltárt összeállító csapat ismeri a határeseteket. A felmérést azonban külön, az Ön tulajdonába kerülő eredménytermékként vásárolja meg, hogy másik partnerhez vihesse, ha a migrációs ajánlat nem győzi meg. ### Hogyan hasonlítsuk össze a különböző migrációs partnerek ajánlatait? Minden partnernek ugyanazt a leltárkivonatot és ugyanazokat a kérdéseket adja, és kérje, hogy mindegyik ugyanarra a néhány alkalmazásra alkalmazza a kritériumait. A gondolatmenetet, a visszaállási terveket és a becslések mögötti feltételezéseket vesse össze, ne csak a végösszeget. ### Szállíthat a csapatunk új funkciókat a migráció alatt? Igen, ha a terv leírja, hogyan. Egyezzenek meg minden alkalmazásra egy változtatási befagyasztási időablakban, egy módszerben, amellyel a két környezet szinkronban marad a költözés alatt, és abban, ki hagyja jóvá a kiadásokat, amíg egy alkalmazás éppen költözik. ## Kapcsolódó szolgáltatások - [Felhőmigráció](https://sdk.enterprises/hu/services/cloud-infrastructure) - [Technikai audit és tanácsadás](https://sdk.enterprises/hu/services/consulting) ## További olvasnivaló - [Több száz régi alkalmazás migrálása AWS-re elakadás nélkül](https://sdk.enterprises/hu/insights/migrating-hundreds-of-apps-to-aws) - [Mit kérdezzen, mielőtt szoftverfejlesztő partnert választ?](https://sdk.enterprises/hu/insights/choosing-a-software-partner)