5 vanligaste misstagen vid molnmigrering — och varför tre av dem egentligen handlar om nätet

En molnmigrering är ett av de större ingrepp ett företag kan göra i sin IT. Fallgroparna är välkända och står i varje checklista: planering, säkerhet, kostnad, nätverk, kompetens. Ändå går projekten snett på ungefär samma ställen.

En del av förklaringen är att listan är sorterad fel. Tre av de fem punkterna nedan har sin verkliga orsak i uppkopplingen och nätverket, alltså i det lager som sällan har någon ägare i projektplanen. Serverrummet har en ansvarig. Molnplattformen har en ansvarig. Linan däremellan antas bara finnas — och det är den som avgör hur migreringen känns för dem som ska arbeta i resultatet.

Vi genomför inte molnmigreringar. Vi levererar det som ligger under dem, och den här texten är skriven utifrån den rollen: vad som brukar saknas i underlaget när nätverksdelen kommer upp, och vad ni kan reda ut innan projektet startar i stället för efteråt.

1. Bristande planering och strategi

Det vanligaste misstaget är att börja flytta innan man bestämt vad som ska flyttas. Alla applikationer hör inte hemma i molnet, en del bör byggas om innan de flyttas, och några bör avvecklas i stället för att följa med. Utan den sorteringen blir migreringen en kopiering av det befintliga, med samma svagheter fast på en annan plats och med en månadskostnad i stället för en engångsinvestering.

Den del av planeringen som nästan alltid saknas är en inventering av vad som faktiskt kommer att gå över linan när flytten är klar. Det är inte samma fråga som vilka servrar som flyttas. Det är frågan om vilken trafik som i dag aldrig lämnar huset och som efter migreringen kommer att göra det varje gång någon öppnar en fil, skriver ut, loggar in eller sparar.

Gör den inventeringen tidigt. Den tar en eftermiddag och den avgör allt i punkt fyra.

2. Underskatta säkerhetsaspekterna

Molnet kräver en annan säkerhetsmodell än ett eget serverrum. Ansvaret delas mellan er och leverantören, och gränsen går inte där många antar. Identitetshantering blir den nya perimetern, åtkomst behöver styras per användare i stället för per nätverkszon, och data behöver skyddas både när den ligger still och när den rör sig.

Det som hör hemma i den här texten är den del som ligger kvar hos er: nätet på kontoret. När systemen flyttar ut upphör inte behovet av segmentering innanför väggarna — det förskjuts. Skrivare, kameror, larm, kassor och maskiner står kvar, de pratar fortfarande med varandra, och de är ofta det som en angripare kommer åt först. Hur ni delar upp nätet så att en enhet inte ger åtkomst till allt hör hemma i nätverk på plats och skydd i nätverkslagret. För ett mindre företag är ordningen viktigare än produkterna — de vanligaste vägarna in och i vilken ordning de ska täppas till.

3. Ignorera kostnadsstyrningen

Molnkostnader har en egenskap som gör dem svåra: de växer av sig själva om ingen tittar till dem. Överdimensionerade instanser som sattes upp under testfasen, miljöer som ingen stängde av, lagring som aldrig rensas och trafik ut ur plattformen som ingen räknade med.

Det sista är värt en extra tanke, eftersom det också är en nätverksfråga. Trafik som lämnar molnplattformen debiteras i regel annorlunda än trafik som går in i den, och en arkitektur där data flyttar fram och tillbaka mellan kontoret och molnet blir dyrare än en där den stannar på ett ställe. Kostnadsstyrning handlar därför inte bara om instansstorlekar utan om var data bor.

Sätt upp uppföljning från första dagen, inte när första fakturan överraskar.

4. Försumma nätverket under migreringen

Här ligger tyngdpunkten, och här är de tre misstagen som listan brukar klumpa ihop till ett.

Uppströms är riktningen som tar slut. Före migreringen gick den tunga trafiken internt. Efter den går den ut. Varje sparad fil, varje backup, varje videomöte och varje synkronisering belastar den utgående riktningen, och i en asymmetrisk anslutning är det den smalare. Det märks inte som att internet är långsamt utan som att allt tar längre tid än det brukade. Hur ni räknar fram vad ni faktiskt behöver, med utgångspunkt i samtidighet snarare än i toppfart, går vi igenom i texten om hur mycket bandbredd företaget behöver.

Delad kapacitet blir synlig först efter flytten. Så länge arbetet skedde mot en server i huset spelade det ingen roll hur mycket marginal operatören hade byggt in i sitt nät. Efteråt gör det det, varje timme. Det är därför frågan om dedikerad eller delad förbindelse blir relevant just i samband med en molnmigrering — inte för att delat är dåligt, utan för att ni efter flytten är beroende av en marginal ni tidigare inte behövde bry er om.

Latens och jämnhet slår hårdare än hastighet. Ett system som bygger på många små anrop mellan klient och server blir långsamt av fördröjning, inte av för lite kapacitet. Ett affärssystem som kändes direkt när det stod i serverrummet kan kännas trögt i molnet trots att linan har gott om utrymme. Samma sak gäller telefoni: när växeln flyttar ut är det jämnheten i förbindelsen som avgör om samtalen håller, inte mängden bandbredd.

Till detta kommer själva flytten. Den initiala överföringen av data är ofta den största enskilda belastning nätet kommer att utsättas för, och den sker samtidigt som verksamheten ska fungera som vanligt. Planera den som en egen post: när på dygnet, under hur lång tid, och vad som händer med resten av arbetet under tiden.

5. Brist på kompetens och förändringsledning

En migrering är inte bara ett tekniskt projekt. Det kräver nya arbetssätt, nya rutiner och ofta nya roller. Den som drev det gamla serverrummet har inte automatiskt kunskapen att driva en molnmiljö, och de som ska arbeta i den nya lösningen behöver veta varför något ändrats.

Den detalj som oftast glöms är felanmälan. I det gamla upplägget var felet antingen i huset eller hos operatören. I det nya kan det ligga i molntjänsten, hos operatören, i er egen utrustning eller hos en integration däremellan — och ingen av parterna ser hela kedjan. Bestäm i förväg vem som gör vad, och se till att den som anmäler kan svara på om felet gäller alla eller bara en, allt eller bara en tjänst, trådlöst eller även kabel. Ordningen att felsöka i innan ni ringer är en bra grund att utgå från.

Det sjätte misstaget: att ingen äger linan

Om vi fick lägga till en punkt på listan är det den här. I en molnmigrering har plattformen en ansvarig och applikationerna har en ansvarig, men uppkopplingen hamnar ofta mellan stolarna — den finns ju redan, och den har fungerat.

Två följder av det är värda att nämna. Den första är redundansen: när verksamheten låg i huset kunde man arbeta vidare en stund utan internet. Efter migreringen kan man inte det, och ett avbrott är ett totalstopp i stället för en olägenhet. Vad som krävs för att en andra väg ut faktiskt ska vara oberoende av den första — inte bara en till kabel från samma leverantör — går vi igenom i texten om redundant internet för företag. Vad ett stopp kostar är värt att räkna på innan ni bestämmer hur mycket redundans som är rimlig: så tar ni fram er egen siffra.

Den andra är adresseringen. Integrationer, VPN-tunnlar och motparter som låser åtkomst mot en känd avsändare slutar fungera den dag adressen ändras, och det är en fråga som behöver vara löst före flytten snarare än efter. Se fast IP-adress för företag.

Har ni flera kontor blir det dessutom en fråga om hur de ska nå molnet: var för sig eller genom ett gemensamt, styrt nät där viktig trafik prioriteras och platser med olika förutsättningar ändå beter sig lika. Det är vad SD-WAN löser, och det är lättare att bygga in från början än att lägga till i efterhand.

Sju frågor att besvara innan projektet startar

1. Vilken trafik lämnar huset efter migreringen som inte gör det i dag?
2. Vad har vi i den utgående riktningen, och räcker det i vår värsta timme?
3. Är vår nuvarande förbindelse delad, och vet vi var delningen sker?
4. Vilka system är känsliga för fördröjning snarare än för kapacitet?
5. Hur lång tid tar den initiala överföringen, och när ska den ske?
6. Vad händer med verksamheten vid ett avbrott när allt ligger ute?
7. Finns det integrationer som är låsta mot vår nuvarande IP-adress?

Vad vi gör och inte gör

Vi genomför inte migreringen, väljer inte molnplattform och driftar inte era system. Det vi gör är uppkopplingen och nätverket under dem: utreda vad som går att leverera på er adress, dimensionera efter vad trafiken faktiskt kommer att se ut som efter flytten, och bygga in redundans där verksamheten inte tål stopp. Vi är operatörsoberoende och har egen svensk kundtjänst, så felanmälan går till oss och vi tar ärendet vidare mot nätägaren.

Vad vi inte gör: vi anger ingen leveranstid innan adressen är utredd, och servicenivåer regleras i avtalet. Behöver molndrift och plattformsarbete ingå sker det via partner — mer om hur den delen hänger ihop finns på sidan om molntjänster. Skicka adressen och en beskrivning av vad som ska flytta, så återkommer vi med ett förslag. Begär offert.

Vill ni gå vidare hittar ni mer om molntjänster och uppkoppling för molnet, uppkoppling för kontor och co-working och nätverk på plats.