IT-migraatio ilman turhaa käyttökatkoa, 8 asiaa ennen siirtoa

IT-migraation onnistumista ei mitata sillä, siirtyikö ympäristö lopulta uuteen paikkaan. Liiketoiminnalle onnistuminen tarkoittaa, että katko pysyi sovitussa rajassa, data säilyi, integraatiot toimivat, käyttäjät jatkoivat työtään ja ongelmatilanteessa olisi voinut palata hallitusti takaisin. Siksi hyvin suunniteltu migraatio alkaa kauan ennen siirtoiltaa.

Soforin IT-migraatio etenee vaiheittain. Ympäristö ja sen riippuvuudet kartoitetaan ensin, ja vanhasta luovutaan vasta, kun uusi on todettu toimivaksi. Sama periaate toimii myös silloin, kun siirron tekee oma tiimi tai usea toimittaja yhdessä.

1. Miten nykytila dokumentoidaan ennen migraatiota?

Kartoita ympäristö sellaisena kuin se oikeasti on, ja varmista dokumentaatio todellista ympäristöä vasten. Migraation ensimmäinen riski syntyy oletuksesta, että ympäristö tunnetaan jo.

Vuosien aikana palvelimia on lisätty, integraatioita rakennettu, verkkosääntöjä muutettu ja väliaikaisia ratkaisuja jätetty pysyviksi. Nykytilan kartoituksessa kannattaa tunnistaa ainakin:

• palvelimet, alustat ja niiden versiot
• sovellukset ja tietokannat
• verkkoyhteydet ja palomuurisäännöt
• käyttöoikeudet ja tunnistautuminen
• varmistukset
• integraatiot ja tiedonsiirrot
• kriittiset ajastukset ja eräajot
• palveluiden omistajat
• palveluita käyttävät liiketoimintaprosessit.

Kartoitus kertoo samalla, mitä muutoksessa ei saa kadota.

2. Miksi riippuvuudet pitää piirtää näkyviin?

Pieni palvelu voi olla edellytys monen muun toiminnalle, ja tunnistamaton riippuvuus näkyy vasta käyttöönotossa. Ympäristön kriittisin komponentti ei aina ole se, joka näyttää tärkeimmältä.

Tunnistautumis-, DNS-, integraatio- tai tiedonsiirtopalvelu voi pysäyttää usean järjestelmän, jos sitä ei siirretä oikeassa järjestyksessä. Kysy jokaisesta kriittisestä palvelusta yksi kysymys.

Mitä muuta lakkaa toimimasta, jos tämä palvelu ei ole käytettävissä?

Ota riippuvuuksien kartoitukseen teknisten asiantuntijoiden lisäksi järjestelmien todellisia käyttäjiä. He tuntevat työnkulkuja, joita arkkitehtuurikaavio ei paljasta.

3. Mikä data siirretään ja mikä jätetään?

Päätä siirrettävä data tarkasti ja sovi, miten sen eheys tarkistetaan. ”Siirretään kaikki” ei aina ole turvallisin eikä järkevin ratkaisu.

Vanhassa ympäristössä voi olla tarpeetonta aineistoa, vanhoja versioita ja dataa, jonka säilyttämiselle ei ole enää perustetta. Toisaalta yhdenkin liiketoimintakriittisen aineiston puuttuminen voi estää käyttöönoton. Sovi ennen siirtoa:

• mitä dataa siirretään
• mistä se siirretään ja mihin
• milloin viimeinen synkronointi tehdään
• miten lähteen ja kohteen eheys tarkistetaan
• miten siirtoikkunan aikana syntyvä data käsitellään
• milloin vanha data poistetaan käytöstä
• mitä säilytetään arkistona.

Datan hyväksymiskriteerien pitää olla yhtä selkeät kuin teknisen ympäristön.

4. Kuka päättää migraation aikana?

Nimeä vetovastuu, hyväksyjät ja palautuspäätöksen tekijä ennen siirtoikkunaa. Migraatioon osallistuu usein oman IT-tiimin lisäksi nykyinen toimittaja, uusi kumppani, verkkotoimittaja ja sovellusten toimittajat, ja mitä enemmän osapuolia on, sitä tärkeämpää on tietää, kuka saa päättää.

Nimeä ennen siirtoa vähintään:

• migraation vetovastuu
• tekninen toteutusvastuu
• liiketoiminnan hyväksyjä
• viestintävastuu
• tietoturvavastuu
• henkilö, joka voi päättää palautuksesta
• kolmansien osapuolten yhteyshenkilöt.

Siirtoilta ei ole oikea hetki selvittää, kuka saa hyväksyä poikkeaman. Jos vastuunjako on epäselvä jo arjessa, se kannattaa korjata ennen migraatiota.

5. Miten migraatio testataan käyttäjän näkökulmasta?

Testaa tekninen toimivuus ja käyttäjän työ erikseen. Palvelin voi olla käynnissä ja sovellus silti käyttökelvoton.

Teknisessä testissä varmistetaan, että palvelut ovat käynnissä, portit auki ja yhteydet toimivat. Liiketoimintatestissä varmistetaan, että käyttäjä pystyy tekemään oikean työn alusta loppuun. Testaa esimerkiksi:

• kirjautuminen ja käyttöoikeudet
• kriittiset haku- ja tallennustoiminnot
• integraatiot
• tulostus ja tiedostosiirrot
• raportointi
• suorituskyky
• ajastetut prosessit
• varmistusten käynnistyminen uudessa ympäristössä.

Rakenna hyväksyntä todellisten käyttötapausten ympärille.

6. Kuinka pitkä käyttökatko on hyväksyttävä?

Hyväksyttävän katkon määrittää liiketoiminta, ja tekninen suunnitelma tehdään sen mukaan. Täysin katkoton migraatio ei ole aina teknisesti tai taloudellisesti järkevä tavoite. Parempi tavoite on poistaa tarpeeton katko ja hallita se osa, jota ei voi välttää.

Kysy liiketoiminnalta:

• kuinka pitkä käyttökatko voidaan hyväksyä
• mihin vuorokaudenaikaan vaikutus on pienin
• mihin prosesseihin katko ei saa osua
• kuinka paljon dataa voidaan pahimmillaan menettää
• tarvitaanko käyttäjille väliaikainen toimintamalli.

RTO eli tavoiteltu palautumisaika ja RPO eli hyväksyttävä tietohävikki muuttavat vastaukset teknisiksi tavoitteiksi. Niiden määrittelystä kerromme tarkemmin oppaassa IT-infran toimintavarmuudesta.

7. Mitä toimiva palautussuunnitelma sisältää?

Toimiva palautussuunnitelma kertoo, missä kohdassa siirto keskeytetään, kuka päättää ja miten vanha ympäristö otetaan takaisin käyttöön. ”Palataan tarvittaessa vanhaan” ei vielä ole suunnitelma.

Kirjaa suunnitelmaan:

• missä kohdassa jatkaminen keskeytetään
• kuka tekee päätöksen
• miten vanha ympäristö otetaan takaisin käyttöön
• kuinka kauan palautuksen arvioidaan kestävän
• miten siirron aikana syntynyt data käsitellään
• mitä käyttäjille viestitään
• milloin uusi yritys tehdään.

Palauttamisen mahdollisuus heikkenee usein migraation edetessä, joten määritä päätöspisteet etukäteen. Harjoittele palautus, jos se on mahdollista. Kokeilematon suunnitelma sisältää aina oletuksia.

8. Milloin migraatio on valmis?

Migraatio on valmis, kun sovitut liiketoimintapalvelut toimivat hyväksytysti uudessa ympäristössä. Viimeisen virtuaalikoneen kopioiminen on vasta välivaihe.

Hyväksymiskriteereihin voivat kuulua:

• kriittisten palveluiden saavutettavuus
• datan eheys
• integraatioiden toimivuus
• käyttäjien kirjautuminen ja käyttöoikeudet
• sovittu suorituskyky
• varmistusten toiminta
• valvonnan ja hälytysten toiminta
• keskeisten liiketoimintaprosessien onnistunut testaus.

Kun kriteerit on kirjoitettu ennen siirtoa, päätöstä ei tarvitse tehdä kiireessä tunteen perusteella.

Mitä tehdään ennen siirtoa, sen aikana ja sen jälkeen?

Migraatio päättyy vasta, kun uusi ympäristö on vakaa ja vanhan ympäristön riippuvuudet voidaan purkaa turvallisesti. Avaaminen käyttäjille on vasta yksi vaihe.

Ennen siirtoa

• vahvista nykytila ja riippuvuudet
• ota ja tarkista tarvittavat varmistukset
• testaa siirtomenetelmä
• sovi vastuut ja päätöspisteet
• hyväksytä käyttökatkoikkuna
• valmistele käyttäjien ja johdon viestintä
• varmista palautuspolku.

Siirron aikana

• kirjaa muutokset ja poikkeamat
• käy läpi ennalta sovitut kontrollipisteet
• tee tekniset testit ja liiketoiminnan hyväksyntätestit
• pidä viestintäkanava auki
• tee jatko- tai palautuspäätös sovittujen kriteerien perusteella.

Siirron jälkeen

• tehosta valvontaa
• tarkista suorituskyky, integraatiot ja varmistukset
• kerää käyttäjien havainnot
• dokumentoi tehdyt muutokset
• sulje poikkeamat ja avoimet tehtävät
• pura vanha ympäristö vasta, kun palautustarve on poistunut.

Miltä hyvä migraatio näyttää käyttäjälle?

Hyvin toteutettu migraatio näyttää käyttäjälle tylsältä. Tekninen työ voi olla suuri, mutta liiketoiminnan kokema häiriö pidetään mahdollisimman pienenä.

”Selkeä yhteinen tavoite ja Soforin vahva projektinhallinta mahdollistivat saumattoman siirtymän ilman yllätyksiä.”

Miksi viestintä kuuluu tekniseen onnistumiseen?

Hyvä viestintä vähentää tukipyyntöjä ja epävarmuutta juuri silloin, kun tekninen tiimi tarvitsee keskittymistä. Käyttäjille ei tarvitse selittää arkkitehtuuria. Heidän pitää tietää:

• mitä palvelua muutos koskee
• milloin vaikutus alkaa ja päättyy
• mitä heidän pitää tehdä ennen muutosta
• mistä he saavat apua
• milloin seuraava tilannepäivitys tulee.

Johdon pitää tietää, onko projekti aikataulussa, ovatko riskit hallinnassa ja mitä tapahtuu, jos suunnitelma ei toteudu.