--- title: "Migrer hundrevis av eldre applikasjoner til AWS uten stans" description: "Praktisk metode for å flytte hundrevis av eldre VM-apper til AWS: kartlegging, oppgradering eller nybygging per app, blokkteam, overgang og tilbakerulling." canonical: https://sdk.enterprises/no/insights/migrating-hundreds-of-apps-to-aws language: no --- # Migrer hundrevis av eldre applikasjoner til AWS uten stans Oppdatert: 2026-09-25 > Å migrere hundrevis av eldre VM-applikasjoner til AWS fungerer når du driver det som et samlebånd heller enn hundrevis av enkeltprosjekter: kartlegg og klassifiser hver app, avgjør oppgradering eller nybygging per app, og del porteføljen inn i blokker som eies av små team. Et felles applikasjonsskjelett, testede steg for overgang og tilbakerulling, og prosedyrer som alle team kan følge, holder kvaliteten stabil når volumet vokser. ## Start med en kartlegging som viser hva hver app faktisk trenger Før noen rører AWS, bør du liste opp alle applikasjoner som kjører på de gamle VM-ene, og registrere fakta som avgjør hvor mye migreringen krever. Et delt regneark holder i starten. Det viktige er at hver app har en rad, en eier og de samme kolonnene. Klassifiser deretter hver app i et lite antall spor, for eksempel oppgradering, nybygging og avvikling. Teamene kan da planlegge per spor i stedet for å diskutere hver app fra bunnen av. - Kjøremiljø og rammeverksversjon, med merking av alt som har passert slutten av levetiden - Databaser, filområder og planlagte jobber appen er avhengig av - Inngående og utgående integrasjoner, inkludert hardkodede vertsnavn og IP-adresser - Autentiseringsmetode og eventuelle hemmeligheter som er lagret på VM-en - Forretningseier, bruksnivå og akseptabelt tidsvindu for nedetid ## Avgjør oppgradering eller nybygging per app, ikke én gang for hele programmet Ingen enkelt strategi passer for hundrevis av apper. Noen trenger bare en oppgradering av rammeverket, konfigurasjon flyttet ut av koden og et nytt mål for utrulling. Andre har så mye død kode eller så floket struktur at det går raskere å bygge dem på nytt på et rent grunnlag enn å reparere dem. Ta beslutningen etter skriftlige kriterier, slik at ulike team kommer til samme svar. En nyttig regel: hvis det å få appen over på standardskjelettet uansett betyr å skrive om de fleste kontrollerne og datatilgangen, bygg den på nytt. Hvis forretningslogikken kan flyttes stort sett uendret, oppgrader den. Programmet hos Crédit Agricole, som flyttet 600+ interne applikasjoner fra gamle VM-er til AWS, brukte begge veiene. Appene ble bygget om på bankens interne CodeIgniter-skjelett, noen ved oppgradering og noen bygget helt fra bunnen av. - Oppgrader når koden er lesbar, oppførselen er tydelig og avstanden til nytt rammeverk er liten - Bygg på nytt når forretningslogikken er blandet inn i presentasjonen overalt, eller appen er avhengig av språkfunksjoner som er fjernet - Avvikle når bruken er nær null og forretningseieren er enig, fordi den billigste migreringen er den du slipper ## Del porteføljen inn i blokker, og gi hver blokk til ett team I denne skalaen blir ett enkelt sentralt team flaskehalsen. En blokkinndelt modell gir en gruppe relaterte apper til ett lite team som eier dem fra analyse til overgang. Grupper blokkene etter felles avhengigheter, ikke alfabetisk. Apper som deler en database eller kaller hverandre, bør flyttes sammen, ellers blir det samme integrasjonsarbeidet gjentatt i flere team. Blokker gjør også fremdriften målbar. Hvert team rapporterer de samme statusene for hver app, for eksempel analysert, migrert, testet, overført og avviklet, og programmets oversikt er summen av disse statusene. Programmet hos Crédit Agricole ble drevet slik, og SDK Enterprises leverte 50+ av applikasjonsmigreringene som en del av programteamet. ## Bygg ett standardskjelett, og la alle apper lande på det Et standard applikasjonsskjelett er det som gjør hundrevis av migreringer til en repeterbar prosess. Det låser beslutningene som ikke skal tas på nytt for hver app: katalogstruktur, konfigurasjon fra miljøvariabler, loggformat, helsesjekker, koblingspunkter for autentisering og utrullingspipelinen. Hver migrerte app skiller seg da bare fra de andre i forretningslogikken. De som går gjennom koden, vet hvor de skal se, driftsteamene får konsistente logger og alarmer, og en retting i skjelettet når alle apper som er bygget på det. Hold skjelettet lite og versjonert. Hvis det vokser til et eget rammeverk, vil teamene begynne å jobbe rundt det. ## Planlegg overgang og tilbakerulling før første migrering Hver app trenger en plan for overgangen som sier hvordan trafikken flyttes, hvordan dataene flyttes, og hvordan man går tilbake. Bestem dette før den første appen flyttes. Å improvisere en tilbakerulling midt i en hendelse er slik migreringsprogrammer mister virksomhetens tillit. - Frysevindu: avtal med forretningseieren når endringer på den gamle VM-en stopper - Datasynkronisering: migrer dataene på forhånd, og kjør en siste synkronisering av endringene i overgangsvinduet - Bytte av trafikk: endre DNS eller rutingen i lastbalansereren, med lave DNS-TTL-er satt flere dager i forveien - Røyktester: en kort skriptet kontroll av innlogging, viktige skjermbilder og integrasjoner rett etter byttet - Utløser for tilbakerulling: en navngitt person og skriftlige vilkår for å bytte tilbake - Den gamle VM-en beholdes: stopp den, men ikke slett den før appen har kjørt feilfritt på AWS i en avtalt periode ## Skriv prosedyrer som alle team kan følge fra første dag En prosedyre (runbook) er sjekklisten for én repeterbar operasjon: klargjøre en app, gjennomføre overgangen, rulle den tilbake, avvikle VM-en. Skriv hver av dem én gang, test den på de første appene, og oppdater den hver gang noe overrasker et team. Gode prosedyrer navngir kommandoer, ansvarlige og forventede resultater, ikke intensjoner. «Sjekk at appen fungerer» er ikke et steg. «Logg inn som testbrukeren og bekreft at dashbordet laster kontodata» er det. Prosedyrene er også det som gjør at utviklere som kommer inn midt i programmet, raskt blir produktive. En spesialist som kommer inn i uke seks, bør kunne gjennomføre overgangen for en app ved å følge dokumentene etter én økt i par. ## Der et eksternt team passer inn i en stor migrering Store programmer trenger ofte ekstra kapasitet i en avgrenset periode uten å gi fra seg kontrollen. Vi tar på oss migreringsblokker i større programmer og jobber på kundens skjelett, prosedyrer og verktøy, med våre egne utviklere og kvalitetssikrede frilansspesialister under én kontrakt. ## Det viktigste - Kartlegg og klassifiser hver app før du migrerer noen av dem, slik at arbeidet kan planlegges per spor. - Velg oppgradering, nybygging eller avvikling per app etter skriftlige kriterier som alle team bruker på samme måte. - Del porteføljen inn i blokker av relaterte apper, som hver eies helt og holdent av ett lite team. - Et lite, versjonert applikasjonsskjelett gjør hundrevis av migreringer konsistente og enkle å gå gjennom. - Gjennomfør aldri overgangen for en app uten en testet vei tilbake og den gamle VM-en fortsatt tilgjengelig. ## Spørsmål og svar ### Hvor lang tid tar det å migrere hundrevis av applikasjoner til AWS? Det avhenger av antall apper, andelen som må bygges på nytt, antall team som jobber parallelt, og overgangsvinduene virksomheten godtar. Estimer etter klassifiseringen: ta tiden på noen apper fra hvert spor, gang med størrelsen på hvert spor, og del på teamenes kapasitet. ### Bør vi bruke lift and shift på eldre apper først og modernisere senere? Lift and shift er raskest når en app allerede kjører på et støttet kjøremiljø og målet er å forlate et datasenter. For apper på kjøremiljøer som har nådd slutten av levetiden, tar du med deg de gamle risikoene over på den nye plattformen hvis du flytter dem uendret, så det blir ofte billigere totalt sett å oppgradere eller bygge på nytt under flyttingen. ### Hva er en blokkinndelt migrering? En blokkinndelt migrering deler en stor applikasjonsportefølje inn i grupper av relaterte apper og gir hver gruppe til ett team som eier den fra analyse til overgang. Det fjerner den sentrale flaskehalsen og gjør fremdriften enkel å følge på tvers av mange team. ## Relaterte tjenester - [Skymigrering](https://sdk.enterprises/no/services/cloud-infrastructure)