I svallvågorna av skandalen på Transportstyrelsen är det nog många som har funderat på vilken information som hanteras på det egna företaget. Det är ofta svårt att veta det, eftersom ett otal databaser har tagits i bruk under årens lopp, för att sedan sjunka i glömska trots kontinuerlig användning.

Ett tillfälle att se över vilka databaser som finns yppar sig vid molnmigreringar. När man ändå ska ta reda på vilka databaser som ska flyttas till en publik, eller privat, molnplattform så är det läge att även inventera vilken information som finns i databaserna. Då finns till exempel chansen att upptäcka känslig information som kanske inte bör lagras utanför Sverige eller som bör hanteras av säkerhetsklassad personal.

Inte nog med det, molnmigreringen är också ett tänkbart tillfälle att se över vilka databashanterare och till och med vilka typer av databaser som används, till exempel traditionella relationsdatabaser eller nosql-databaser.

Migreringen är också ett tillfälle att se över hur databaserna är strukturerade, så väl vad gäller databasmodeller som teknisk implementation. Ett exempel på det senare är hur man fördelar belastningen på flera servrar, ett annat hur data delas upp och lagras på olika geografiska platser.

Görs det här?

– Det görs sällan. När vi genomför migreringsprojekt så försöker vi påtala de här sakerna, men många kunder ser inte värdet i dem, säger Anders Eriksson, vd på konsultföretaget Softronic.

Anders Eriksson, Softronic
Anders Eriksson, vd på Softronic.

Varför är det många som inte tar chansen att se över databasanvändningen vid migreringar?

– De flesta prioriterar att hålla tidsplaner och att få fasta priser, förklarar Anders Eriksson.

Christian Landgren som är vd på konsultföretaget Iteam håller med om att många missar chansen att se över databasanvändningen vid migreringar. Men han påpekar att det också finns anledningar att göra det i flera steg:

– Många av våra kunder genomförde molnmigreringar för några år sedan och flyttade då ofta över it-lösningar som de var. Sedan har de steg för steg sett över lösningarna och förändrat dem, berättar Christian Landgren.

Läs ocksåStockholms landstings jätteflytt till Microsofts moln

Han påpekar att en anledning att flytta över it-lösningar intakta till molnet är att det blir enklare att verifiera dem i den nya miljön om det är tänkt att de ska fungera på samma sätt som innan migreringen.

Så här beskriver Christian Landgren hur många migreringsprojekt ser ut i dag:

– Det är vanligt numera att vi gör en hybridmigrering, till exempel med hjälp av Docker, och låter delar av informationen ligga kvar lokalt medan andra delar flyttas till molnet.

Christian Landgren, Iteam
Christian Landgren, vd på Iteam.

Han säger att det ger bättre möjligheter att göra ändamålsenliga teknikval:

– Till exempel Elasticsearch för sökning, RabbitMQ för realtidsinformation och Redis för key-value-databaser. Effekten blir en kombination av pris, prestanda, säkerhet och skalbarhet.

Av allt att döma så är hanteringen av databaser vid molnmigreringar ett av många exempel på när kortsiktiga och långsiktiga mål ställs mot varandra. I det korta loppet kan man få större besparingar genom att flytta databaslösningar intakta till en molntjänst. Men i det långa loppet kanske man missar chanser att se över informationsanvändning och att få till bättre tekniska lösningar.

Läs ocksåDärför misslyckas projekt fortfarande

Risken är att man inte orkar, eller hinner, dra i gång ett projekt med att inventera databaser och att fundera på nya lösningar för dem efter att molnmigreringen har klarats av. Det handlar trots allt om att kraftsamla för en ny projektstart om arbetet delas upp. Om man gör arbetet under molnmigreringen så är projektet redan i gång.