--- title: "Frågor till en partner för molnmigrering innan du skriver på" description: "Fråga detta innan du anlitar en partner för molnmigrering: inventering, strategi per app, landing zone, säkerhet, övergång, återgång, kostnader, överlämning." canonical: https://sdk.enterprises/sv/insights/questions-before-hiring-a-cloud-migration-partner language: sv --- # Frågor till en partner för molnmigrering innan du skriver på Uppdaterad: 2026-09-26 > Innan du skriver avtal med en partner för molnmigrering: fråga hur partnern ska inventera det du kör, välja migreringsstrategi för varje applikation, utforma och säkra målmiljön, kunna backa varje övergång, visa dig kostnaderna och förbereda ditt team på att driva resultatet. Konkreta, skriftliga svar säger mer om migreringen som väntar än dagpriset gör. ## Fråga hur de ska ta reda på vad du faktiskt kör En migreringsplan är aldrig bättre än inventeringen bakom den. Fråga partnern hur den ska tas fram: genom intervjuer med applikationsägare, genom infrastrukturdata som servermått och nätverksanslutningar, genom själva koden eller genom alla tre. Befintlig dokumentation är en startpunkt, inte ett bevis, eftersom den glider isär från det som faktiskt körs. Fråga vad inventeringen ska innehålla och vem som äger den efteråt. Ett bra svar namnger fälten och bekräftar att inventeringen stannar hos dig, vad du än bestämmer härnäst. - Varje applikation, dess verksamhetsägare och hur kritisk den är - Körmiljöer, ramverk och operativsystem, med markering av allt som har nått end of life - Databaser, filresurser, schemalagda jobb och köer som varje applikation är beroende av - Integrationer i båda riktningarna, även dem som ingen har dokumenterat - Licenser som är knutna till hårdvara eller antal processorer och som kanske inte följer med till molnet - Acceptabla driftstopp och verksamhetens kalender: månadsskifte, högsäsong, regulatoriska tidsfrister ## Räkna med en strategi per applikation, inte en för hela beståndet Applikationer flyttar till molnet på olika sätt. De vanliga alternativen är att flytta en applikation som den är (lift and shift), flytta den med små ändringar som en hanterad databas, bygga om den för att använda molntjänster, ersätta den med en SaaS-produkt, låta den stå kvar tills vidare eller avveckla den. En partner som föreslår ett och samma angreppssätt för allt har inte tittat tillräckligt noga. Be om kriterierna de använder för att välja, och be att få se dem tillämpade på tre eller fyra av dina egna applikationer innan du skriver på. Hur de resonerar kring dina verkliga system säger mer än en bild om metoden. Fråga särskilt hur de hanterar applikationer i körmiljöer som har nått end of life, eftersom de gamla riskerna följer med till den nya plattformen om applikationerna flyttas oförändrade. ## Ta reda på vem som utformar och säkrar din landing zone En landing zone är den förberedda målmiljön: kontostruktur, identitet och åtkomst, nätverk, loggning, kryptering och de skyddsräcken som varje applikation ärver. Ett misstag här upprepas i varje applikation som landar i den. Fråga vem som utformar den, om den är definierad som kod, till exempel med Terraform, och om din säkerhetsavdelning granskar den innan den första applikationen flyttas. Säkerheten i molnet är delad. Leverantören säkrar den underliggande infrastrukturen, och du ansvarar fortfarande för hur du konfigurerar och använder den. Fråga partnern vilka kontroller de ska sätta upp, vilka som stannar hos ditt team och hur deras egna utvecklares åtkomst beviljas, loggas och tas bort i slutet. - Separata konton eller projekt per miljö, med produktionen isolerad - Single sign-on med namngivna användare och roller med minsta möjliga behörighet, och inga delade administratörsuppgifter - Central loggning och granskningsspår som projektets utvecklare inte kan stänga av - Kryptering av lagrade data och data under överföring som standard, med hemligheter utanför koden - Regioner som väljs för att uppfylla dina krav på datalagringsplats och dina skyldigheter enligt GDPR ## Låt dem gå igenom en övergång och en återgång med dig Övergången är det ögonblick då trafik och data växlar till den nya miljön, och det är där en migrering syns mest för verksamheten. Be partnern gå igenom en övergång steg för steg för en av dina applikationer: hur data synkroniseras, hur trafiken ställs om, vilka kontroller som körs efteråt och vem som avgör att det fungerade. Fråga sedan hur de skulle gå tillbaka. En trovärdig plan anger villkoren som utlöser en återgång, personen som fattar beslutet och hur länge den gamla miljön förblir tillgänglig. Om användare har skrivit data i den nya miljön sedan omställningen: fråga hur de data kommer tillbaka till den gamla. Svaga planer hoppar över den frågan. Vår artikel om att migrera hundratals äldre appar till AWS visar hur de här stegen blir runbooks i ett stort bestånd. ## Kräv att få se kostnaderna innan den första fakturan kommer Kostnader i molnet beter sig annorlunda än i ett datacenter. Du betalar för det som körs, även testmiljöer som ingen har stängt av, lagring som fortsätter att växa och data som förs ut ur leverantörens nätverk. Be om en kostnadsuppskattning per applikation med antagandena nedskrivna, och fråga hur partnern ska jämföra den med den verkliga användningen under de första månaderna. Insyn i kostnaderna är ett designbeslut, inte en månadsrapport. Be om regler för taggning som kopplar varje resurs till en applikation och en ägare, budgetar och larm från första dagen och en genomgång av instansstorlekar när applikationerna har körts under verklig last. Att dimensionera molnservrar efter den gamla hårdvaran är ett säkert sätt att betala för kapacitet som ingen använder. ## Varningstecken på att ett migreringsförslag inte är färdigt Vart och ett av dessa kan ha en förklaring. Flera i samma förslag betyder oftast att risken har lämnats åt dig att upptäcka. - En fast tidsplan innan någon har sett din inventering - En och samma migreringsstrategi för varje applikation - Ingen skriftlig plan för återgång, eller en återgång som bygger på att återställa säkerhetskopior under press - Molnkonton, infrastrukturkod eller pipelines som ägs av partnern i stället för av dig - Kostnadsuppskattningar utan antaganden, och ingen plan för taggning eller budgetar - Kunskapsöverföring inplanerad till den sista veckan ## Planera kunskapsöverföringen från första veckan, inte den sista Migreringen tar slut; driften av plattformen gör det inte. Fråga hur ditt team ska lära sig att driva det som byggs: parprogrammering på verkliga uppgifter under migreringen, runbooks för återkommande åtgärder och en genomgång av övervakning och larm med dem som ska ha jour. Be om att allt ska ligga i dina konton och kodförråd från början: infrastrukturkod, pipelines, runbooks och diagram. Kom sedan överens om hur överlämningen godkänns, till exempel att ditt team driftsätter och backar en applikation utan partnerns hjälp. Vi arbetade i teamet som flyttade 600+ interna applikationer hos Crédit Agricole från äldre virtuella maskiner till AWS, och levererade själva 50+ av de migreringarna. Om du vill ha en second opinion på ett migreringsförslag, eller ett team som levererar en del av arbetet, kan våra utvecklare inom molninfrastruktur gå igenom de här frågorna med dig. ## Det viktigaste - Fråga hur inventeringen ska tas fram och kontrolleras, eftersom varje uppskattning och varje plan för migreringsvågor bygger på den. - Räkna med en migreringsstrategi som väljs per applikation, med kriterier som du kan se tillämpade på dina egna system. - Se till att din landing zone är definierad som kod, granskad av din säkerhetsavdelning och ligger i dina konton. - Godta inte en plan för övergången utan en namngiven utlösare för återgång och ett sätt att återställa data som skrivits efter omställningen. - Kom överens om taggning, budgetar och hur överlämningen godkänns innan den första applikationen flyttas. ## Vanliga frågor ### Ska partnern som bedömer vårt bestånd också migrera det? Det kan den göra, och det sparar ofta tid, eftersom teamet som tog fram inventeringen känner till specialfallen. Köp bedömningen som en separat leverans som du äger, så att du kan ta den till en annan partner om migreringsförslaget inte övertygar. ### Hur jämför vi förslag från olika partner för molnmigrering? Ge varje partner samma utdrag ur inventeringen och samma frågor, och be var och en tillämpa sina kriterier på samma fåtal applikationer. Jämför resonemangen, planerna för återgång och antagandena bakom uppskattningarna, inte bara totalpriset. ### Kan vårt team fortsätta leverera funktioner under migreringen? Ja, om planen anger hur. Kom överens om en frysperiod för ändringar för varje applikation, ett sätt att hålla båda miljöerna synkroniserade medan den flyttas och vem som godkänner releaser medan en applikation är mitt i flytten. ## Relaterade tjänster - [Molnmigrering](https://sdk.enterprises/sv/services/cloud-infrastructure) - [Teknisk granskning och rådgivning](https://sdk.enterprises/sv/services/consulting) ## Läs vidare - [Migrera hundratals äldre appar till AWS utan att fastna](https://sdk.enterprises/sv/insights/migrating-hundreds-of-apps-to-aws) - [Frågor att ställa innan du anlitar en mjukvarupartner](https://sdk.enterprises/sv/insights/choosing-a-software-partner)