Før du signerer med en partner for skymigrering, bør du spørre hvordan de skal kartlegge det du kjører, velge en migreringsstrategi for hver applikasjon, utforme og sikre målmiljøet, rulle tilbake hver overgang, vise deg kostnadene og forberede teamet ditt på å drifte resultatet. Konkrete, skriftlige svar forteller deg mer om migreringen som ligger foran deg, enn dagsprisen gjør.
Spør hvordan de skal finne ut hva du faktisk kjører
En migreringsplan er aldri bedre enn kartleggingen bak den. Spør partneren hvordan de skal bygge den: fra intervjuer med applikasjonseierne, fra infrastrukturdata som servermetrikker og nettverksforbindelser, fra selve koden, eller fra alle tre. Eksisterende dokumentasjon er et utgangspunkt, ikke et bevis, fordi den glir bort fra det som faktisk kjører.
Spør hva kartleggingen skal registrere, og hvem som eier den etterpå. Et godt svar navngir feltene og bekrefter at kartleggingen blir hos deg, uansett hva du bestemmer deg for videre.
- Hver applikasjon, forretningseieren og hvor kritisk den er
- Kjøremiljøer, rammeverk og operativsystemer, med merking av alt som har passert slutten av levetiden
- Databaser, filområder, planlagte jobber og køer hver applikasjon er avhengig av
- Integrasjoner i begge retninger, også dem ingen har dokumentert
- Lisenser knyttet til maskinvare eller antall prosessorer som kanskje ikke kan overføres til skyen
- Akseptabel nedetid og virksomhetens kalender: månedsslutt, høysesong, regulatoriske frister
Forvent en strategi per applikasjon, ikke én for hele porteføljen
Applikasjoner flyttes til skyen på ulike måter. De vanlige alternativene er å flytte en applikasjon som den er (lift and shift), flytte den med små endringer som en administrert database, bygge den om for å bruke skytjenester, erstatte den med et programvareprodukt levert som tjeneste (SaaS), beholde den der den er inntil videre, eller avvikle den. En partner som foreslår én tilnærming for alt, har ikke sett nøye nok etter.
Be om kriteriene de bruker for å velge, og be om å få se dem brukt på tre eller fire av dine egne applikasjoner før du signerer. Resonnementet deres om de faktiske systemene dine forteller deg mer enn et lysbilde om metode. Spør særlig hvordan de behandler applikasjoner på kjøremiljøer som har nådd slutten av levetiden, fordi du tar med deg de gamle risikoene over på den nye plattformen hvis du flytter dem uendret.
Finn ut hvem som utformer og sikrer landingssonen
Landingssonen er det forberedte målmiljøet: kontostruktur, identitet og tilgang, nettverk, logging, kryptering og rekkverkene hver applikasjon arver. En feil her gjentas i hver applikasjon som lander der. Spør hvem som utformer den, om den er definert som kode, for eksempel med Terraform, og om sikkerhetsteamet ditt går gjennom den før den første applikasjonen flyttes.
Sikkerhet i skyen er et delt ansvar. Leverandøren sikrer den underliggende infrastrukturen, og du har fortsatt ansvaret for hvordan du konfigurerer og bruker den. Spør partneren hvilke kontroller de skal sette opp, hvilke som blir liggende hos teamet ditt, og hvordan tilgangen til deres egne utviklere gis, loggføres og fjernes til slutt.
- Egne kontoer eller prosjekter per miljø, med produksjon isolert
- Enkel pålogging (SSO) med navngitte brukere og roller med minste nødvendige rettigheter, og ingen delte administratorpålogginger
- Sentral logging og revisjonsspor som prosjektets utviklere ikke kan slå av
- Kryptering av lagrede data og data under overføring som standard, med hemmeligheter holdt utenfor koden
- Regioner valgt for å oppfylle kravene til datalokasjon og forpliktelsene dine etter GDPR
Be dem gå gjennom én overgang og én tilbakerulling med deg
Overgangen er øyeblikket da trafikk og data bytter til det nye miljøet, og det er der en migrering er mest synlig for virksomheten. Be partneren gå gjennom en overgang steg for steg for én av applikasjonene dine: hvordan dataene synkroniseres, hvordan trafikken byttes, hvilke kontroller som kjøres etterpå, og hvem som avgjør at det fungerte.
Spør deretter hvordan de ville gått tilbake. En troverdig plan navngir vilkårene som utløser en tilbakerulling, personen som tar avgjørelsen, og hvor lenge det gamle miljøet forblir tilgjengelig. Hvis brukere har skrevet data i det nye miljøet siden byttet, spør hvordan de dataene kommer tilbake til det gamle. Svake planer hopper over det spørsmålet.
Artikkelen vår om migrering av hundrevis av eldre apper til AWS viser hvordan disse stegene blir til prosedyrer på tvers av en stor portefølje.
Krev å se kostnadene før den første regningen kommer
Kostnader i skyen oppfører seg annerledes enn i et datasenter. Du betaler for det som kjører, også testmiljøer ingen har slått av, lagring som stadig vokser, og data som overføres ut av leverandørens nettverk. Be om et kostnadsestimat per applikasjon med forutsetningene skrevet ned, og spør hvordan partneren skal sammenligne det med faktisk bruk de første månedene.
Innsyn i kostnadene er en designbeslutning, ikke en månedlig rapport. Be om regler for merking (tagging) som knytter hver ressurs til en applikasjon og en eier, budsjetter og varsler fra første dag, og en gjennomgang av instansstørrelsene når applikasjonene har kjørt under reell belastning. Å dimensjonere skyservere etter den gamle maskinvaren er en sikker måte å betale for kapasitet ingen bruker.
Varseltegn på at et migreringsforslag ikke er klart
Hvert av disse kan ha en forklaring. Flere i det samme forslaget betyr som regel at risikoen er overlatt til deg å oppdage.
- En fast tidsplan før noen har sett kartleggingen din
- Én migreringsstrategi brukt på alle applikasjoner
- Ingen skriftlig plan for tilbakerulling, eller en tilbakerulling som avhenger av å gjenopprette sikkerhetskopier under press
- Skykontoer, infrastrukturkode eller pipelines som eies av partneren i stedet for av deg
- Kostnadsestimater uten forutsetninger, og ingen plan for merking eller budsjetter
- Kunnskapsoverføring satt opp til den siste uken
Planlegg kunnskapsoverføringen fra første uke, ikke den siste
Migreringen tar slutt; driften av plattformen gjør det ikke. Spør hvordan teamet ditt skal lære å drifte det som bygges: parprogrammering på ekte oppgaver under migreringen, prosedyrer for tilbakevendende operasjoner og en gjennomgang av overvåking og varsler med dem som skal ha vakt.
Be om at alt ligger i dine kontoer og repositorier fra starten: infrastrukturkode, pipelines, prosedyrer og diagrammer. Avtal deretter hvordan overleveringen godkjennes, for eksempel at teamet ditt ruller ut og ruller tilbake en applikasjon uten hjelp fra partneren.
Vi var med i teamet som flyttet 600+ interne applikasjoner hos Crédit Agricole fra gamle VM-er til AWS, og leverte selv 50+ av disse migreringene. Hvis du vil ha en annen vurdering av et migreringsforslag, eller et team som leverer en del av arbeidet, kan utviklerne våre innen skyinfrastruktur gå gjennom disse spørsmålene sammen med deg.
Det viktigste
- Spør hvordan kartleggingen skal bygges og kontrolleres, fordi hvert estimat og hver bølgeplan avhenger av den.
- Forvent en migreringsstrategi valgt per applikasjon, med kriterier du kan se brukt på dine egne systemer.
- Sørg for at landingssonen er definert som kode, gjennomgått av sikkerhetsteamet ditt og lagret i dine kontoer.
- Godta ikke en plan for overgang uten en navngitt utløser for tilbakerulling og en måte å gjenopprette data skrevet etter byttet på.
- Avtal merking, budsjetter og hvordan overleveringen godkjennes, før den første applikasjonen flyttes.
Spørsmål og svar
Bør partneren som vurderer porteføljen vår, også migrere den?
Det kan den, og det sparer ofte tid, fordi teamet som bygde kartleggingen, kjenner grensetilfellene. Kjøp vurderingen som en egen leveranse som dere eier, slik at dere kan ta den med til en annen partner hvis migreringsforslaget ikke overbeviser.
Hvordan sammenligner vi forslag fra ulike partnere for skymigrering?
Gi alle partnerne det samme utdraget fra kartleggingen og de samme spørsmålene, og be hver av dem bruke kriteriene sine på de samme få applikasjonene. Sammenlign resonnementet, planene for tilbakerulling og forutsetningene bak estimatene, ikke bare totalprisen.
Kan teamet vårt fortsette å lansere nye funksjoner under migreringen?
Ja, hvis planen sier hvordan. Avtal et frysevindu for endringer for hver applikasjon, en måte å holde begge miljøene synkronisert mens den flyttes, og hvem som godkjenner lanseringer mens en applikasjon er under flytting.