--- title: "Migrare cloud: ce întrebați un partener înainte de semnare" description: "Ce întrebați un partener de migrare cloud înainte de a semna: inventar, strategie pe aplicație, landing zone, securitate, cutover și rollback, costuri, predare." canonical: https://sdk.enterprises/ro/insights/questions-before-hiring-a-cloud-migration-partner language: ro --- # Migrare cloud: ce întrebați un partener înainte de semnare Actualizat: 2026-09-26 > Înainte de a semna cu un partener de migrare în cloud, întrebați cum va inventaria ce rulați, cum va alege o strategie de migrare pentru fiecare aplicație, cum va proiecta și securiza mediul țintă, cum va reveni din fiecare cutover, cum vă va arăta costurile și cum vă va pregăti echipa să opereze rezultatul. Răspunsurile concrete și scrise vă spun mai multe despre migrarea care urmează decât tariful zilnic. ## Întrebați cum vor afla ce rulați de fapt Un plan de migrare este la fel de bun ca inventarul pe care se sprijină. Întrebați partenerul cum îl va construi: din interviuri cu responsabilii aplicațiilor, din date de infrastructură precum metricile serverelor și conexiunile de rețea, din codul însuși sau din toate trei. Documentația existentă este un punct de plecare, nu o dovadă, pentru că se îndepărtează în timp de ce rulează efectiv. Întrebați ce va conține inventarul și cui îi va aparține ulterior. Un răspuns bun numește câmpurile și confirmă că inventarul rămâne la dumneavoastră, orice ați decide mai departe. - Fiecare aplicație, responsabilul ei de business și cât de critică este - Runtime-urile, framework-urile și sistemele de operare, cu tot ce a ajuns la sfârșitul suportului semnalat - Bazele de date, partajările de fișiere, joburile programate și cozile de care depinde fiecare aplicație - Integrările în ambele sensuri, inclusiv cele pe care nu le-a documentat nimeni - Licențele legate de hardware sau de numărul de procesoare, care s-ar putea să nu fie transferabile în cloud - Indisponibilitatea acceptabilă și calendarul businessului: închiderea de lună, sezonul de vârf, termenele de reglementare ## Așteptați o strategie pentru fiecare aplicație, nu una pentru întregul parc Aplicațiile se mută în cloud în moduri diferite. Opțiunile uzuale sunt: rehostarea unei aplicații așa cum este (lift and shift), replatformarea ei cu mici modificări, precum o bază de date gestionată, refactorizarea ei pentru a folosi servicii cloud, înlocuirea ei cu un produs software-as-a-service, păstrarea ei deocamdată unde este sau retragerea ei. Un partener care propune o singură abordare pentru toate nu s-a uitat suficient de atent. Cereți criteriile pe care le folosesc pentru a alege și cereți să le vedeți aplicate pe trei sau patru dintre propriile aplicații înainte de a semna. Raționamentul lor despre sistemele dumneavoastră reale vă spune mai mult decât un slide despre metodă. Întrebați în special cum tratează aplicațiile pe runtime-uri ajunse la sfârșitul suportului, pentru că mutarea lor neschimbată duce vechile riscuri pe noua platformă. ## Aflați cine proiectează și securizează landing zone-ul Landing zone-ul este mediul țintă pregătit: structura conturilor, identitatea și accesul, rețeaua, jurnalizarea, criptarea și regulile de protecție pe care le moștenește fiecare aplicație. O greșeală aici se repetă în fiecare aplicație care ajunge pe el. Întrebați cine îl proiectează, dacă este definit prin cod, de exemplu cu Terraform, și dacă echipa dumneavoastră de securitate îl verifică înainte de mutarea primei aplicații. Securitatea în cloud este partajată. Furnizorul securizează infrastructura de bază, iar dumneavoastră rămâneți responsabili de modul în care o configurați și o folosiți. Întrebați partenerul ce controale va pune în practică, care rămân la echipa dumneavoastră și cum este acordat, jurnalizat și retras la final accesul propriilor lui ingineri. - Conturi sau proiecte separate pentru fiecare mediu, cu producția izolată - Single sign-on cu utilizatori nominali și roluri cu privilegii minime, fără credențiale de administrator partajate - Jurnalizare centralizată și piste de audit pe care inginerii proiectului nu le pot dezactiva - Criptare implicită în repaus și în tranzit, cu secretele ținute în afara codului - Regiuni alese pentru a respecta obligațiile de rezidență a datelor și RGPD ## Cereți-le să vă explice pas cu pas un cutover și un rollback Cutoverul este momentul în care traficul și datele trec în noul mediu și este partea migrării cea mai vizibilă pentru business. Cereți partenerului să vă explice pas cu pas un cutover pentru una dintre aplicațiile dumneavoastră: cum sunt sincronizate datele, cum este comutat traficul, ce verificări rulează după aceea și cine decide că a funcționat. Apoi întrebați cum ar reveni. Un plan credibil numește condițiile care declanșează un rollback, persoana care ia decizia și cât timp rămâne disponibil vechiul mediu. Dacă utilizatorii au scris date în noul mediu după comutare, întrebați cum ajung acele date înapoi în cel vechi. Planurile slabe sar peste această întrebare. Articolul nostru despre migrarea a sute de aplicații legacy în AWS arată cum acești pași devin runbookuri într-un parc mare. ## Insistați să vedeți costurile înainte să sosească prima factură Costurile cloud se comportă altfel decât cele ale unui centru de date. Plătiți pentru ce rulează, inclusiv mediile de test pe care nu le-a oprit nimeni, stocarea care tot crește și datele transferate în afara rețelei furnizorului. Cereți o estimare a costurilor pentru fiecare aplicație, cu ipotezele scrise, și întrebați cum o va compara partenerul cu utilizarea reală în primele luni. Vizibilitatea costurilor este o decizie de design, nu un raport lunar. Cereți reguli de etichetare (tagging) care leagă fiecare resursă de o aplicație și de un responsabil, bugete și alerte din prima zi și o revizuire a dimensiunilor instanțelor după ce aplicațiile au rulat sub încărcare reală. Dimensionarea serverelor cloud după hardware-ul vechi este o metodă sigură de a plăti pentru capacitate pe care nu o folosește nimeni. ## Semne că o propunere de migrare nu este pregătită Oricare dintre ele poate avea o explicație. Mai multe în aceeași propunere înseamnă de obicei că riscul v-a fost lăsat dumneavoastră să-l descoperiți. - Un calendar fix înainte ca cineva să vă fi văzut inventarul - O singură strategie de migrare aplicată fiecărei aplicații - Niciun plan de rollback scris sau un rollback care depinde de restaurarea backupurilor sub presiune - Conturi cloud, cod de infrastructură sau pipeline-uri deținute de partener, nu de dumneavoastră - Estimări de cost fără ipoteze și niciun plan pentru etichetare sau bugete - Transferul de cunoștințe programat în ultima săptămână ## Planificați transferul de cunoștințe din prima săptămână, nu din ultima Migrarea se încheie; operarea platformei, nu. Întrebați cum va învăța echipa dumneavoastră să opereze ce se construiește: lucru în pereche pe sarcini reale în timpul migrării, runbookuri pentru operațiunile recurente și o prezentare a monitorizării și a alertelor împreună cu oamenii care vor fi de gardă. Cereți ca totul să se afle în conturile și depozitele dumneavoastră de la început: codul de infrastructură, pipeline-urile, runbookurile și diagramele. Apoi conveniți cum este acceptată predarea, de exemplu echipa dumneavoastră face deploy și rollback pentru o aplicație fără ajutorul partenerului. Am lucrat în echipa care a mutat 600+ de aplicații interne Crédit Agricole de pe VM-uri vechi în AWS, livrând noi înșine 50+ dintre aceste migrări. Dacă doriți o a doua opinie despre o propunere de migrare sau o echipă care să livreze o parte din muncă, inginerii noștri de infrastructură cloud pot trece prin aceste întrebări împreună cu dumneavoastră. ## De reținut - Întrebați cum va fi construit și verificat inventarul, pentru că de el depind toate estimările și planul valurilor de migrare. - Așteptați o strategie de migrare aleasă pentru fiecare aplicație, cu criterii pe care le puteți vedea aplicate propriilor sisteme. - Cereți ca landing zone-ul să fie definit prin cod, verificat de echipa dumneavoastră de securitate și păstrat în conturile dumneavoastră. - Nu acceptați un plan de cutover fără un declanșator de rollback numit și o cale de recuperare a datelor scrise după comutare. - Conveniți etichetarea, bugetele și modul de acceptare a predării înainte de mutarea primei aplicații. ## Întrebări frecvente ### Partenerul care ne evaluează parcul ar trebui să îl și migreze? Poate, și adesea economisește timp, pentru că echipa care a construit inventarul cunoaște cazurile limită. Cumpărați evaluarea ca livrabil separat, care vă aparține, ca să o puteți duce la alt partener dacă propunerea de migrare nu vă convinge. ### Cum comparăm propunerile unor parteneri de migrare diferiți? Dați fiecărui partener același extras din inventar și aceleași întrebări și cereți-i fiecăruia să-și aplice criteriile pe aceleași câteva aplicații. Comparați raționamentul, planurile de rollback și ipotezele din spatele estimărilor, nu doar prețul total. ### Poate echipa noastră să livreze în continuare funcționalități în timpul migrării? Da, dacă planul spune cum. Conveniți o fereastră de înghețare a modificărilor pentru fiecare aplicație, o modalitate de a menține ambele medii sincronizate cât timp aplicația se mută și cine aprobă lansările cât timp o aplicație este în curs de migrare. ## Servicii conexe - [Migrare în cloud](https://sdk.enterprises/ro/services/cloud-infrastructure) - [Audit tehnic și consultanță](https://sdk.enterprises/ro/services/consulting) ## Lecturi suplimentare - [Migrarea a sute de aplicații legacy în AWS fără blocaje](https://sdk.enterprises/ro/insights/migrating-hundreds-of-apps-to-aws) - [Întrebări de pus înainte de a alege un partener software](https://sdk.enterprises/ro/insights/choosing-a-software-partner)