Organisaatiot epäonnistuvat harvoin järjestelmän ostamisessa. Valinta on hyvin ymmärretty, toimittajat ovat harjaantuneita esityksissä, ja liiketoimintaperustelut käydään tarkasti läpi. Ohjelmat hajoavat käsiin käyttöönoton hetkellä, kun suunnittelun ja rakentamisen kertynyt optimismi kohtaa tuotantodatan, todellisten käyttäjien ja armottomien alavirran riippuvuuksien konkreettisen todellisuuden. Tämän epäonnistumisen kustannukset eivät jakaudu tasaisesti aikataululle. Ne keskittyvät vaihtoa ympäröiviin tunteihin tai päiviin, ja ne osuvat suoraan operatiiviseen liiketoimintaan: tilauksiin, joita ei voida toimittaa, laskuihin, joita ei voida laatia, potilaisiin tai asiakkaisiin, joiden tiedot ovat hetkellisesti tavoittamattomissa.

Kaksi muutosta on tehnyt tästä pikemminkin akuutimpaa kuin vähäisempää. Ensimmäinen on integraatioiden tiheys. Nykyaikainen sovellus ei ole saareke vaan solmu rajapintojen, tapahtumavirtojen ja jaetun perustiedon verkostossa, joten yhden järjestelmän siirtäminen häiritsee monia muita. Toinen on huoltoikkunan romahtaminen. Yritykset, jotka aikoinaan sietivät viikonlopun mittaisen katkoksen, toimivat nyt jatkuvasti, yli aikavyöhykkeiden ja kanavien, ja siedettävä katkos on kutistunut päivistä minuutteihin. Seurauksena migraatiota ei voida enää käsitellä teknisenä jälkiajatuksena, joka ajoitetaan hiljaiselle sunnuntaille. Se on vaihe, jossa ohjelma joko kunnioittaa tai pettää sen liiketoiminnan, jota sen oli tarkoitus palvella, ja se ansaitsee saman suunnittelun tarkkuuden kuin itse järjestelmä.

Vaihtostrategia on joukko tietoisia vastauksia pieneen määrään vaikeita kysymyksiä, ja ne strategiat, jotka ammattilaiset tunnistavat, ovat todellisuudessa pisteitä näiden vastausten määrittelemällä janalla. Ensimmäinen kysymys on, tapahtuuko siirtymä yhdellä ratkaisevalla liikkeellä vai vaiheittain. Big bang -vaihto siirtää koko käyttäjäkunnan ja tietoaineiston uuteen järjestelmään yhdellä sovitulla hetkellä. Se on käsitteellisesti selkeä ja välttää kahden järjestelmän rinnakkaisen ajamisen taakan, mutta se keskittää kaiken riskin yhteen peruuttamattomaan hetkeen ja tarjoaa vähän tilaa oppimiselle. Vaiheittainen lähestymistapa siirtää organisaation yli erissä, maantieteen, liiketoimintayksikön, tuotelinjan tai toiminnon mukaan, vaihtaen yksittäisen tapahtuman yksinkertaisuuden asteittaisen altistumisen turvallisuuteen ja sellaisen välitilan monimutkaisuuteen, jossa molemmat järjestelmät ovat käytössä.

Toinen kysymys on, mitä datalle tapahtuu. Migraatio ei ole pelkkä kopio: se on poiminta lähdemallista, muunnos kohdemalliin, jonka rakenne ja säännöt eivät lähes koskaan täsmää, sekä lataus, jonka on kunnioitettava kohteen validointia ja viite-eheyttä. Kolmas kysymys on vanhan järjestelmän kohtalo. Jotkin siirtymät poistavat sen käytöstä välittömästi, toiset pitävät sen käynnissä rinnakkain, jotta tuloksia voidaan verrata, ja toiset jättävät sen paikoilleen toistaiseksi vain luettavana arkistona. Viimeinen ja eniten laiminlyöty kysymys on, kuinka organisaatio tietää vaihtohetkellä, onnistuiko migraatio todella. Ilman nimenomaista, mitattavaa onnistumisen määritelmää ja sitä vastaavaa epäonnistumisen määritelmää vaihtoa ei voida ohjata. Sen läpi voi vain toivoa, eikä toivo ole strategia, joka selviää kosketuksesta tuotantoon.

Migraatiotyön painopiste on siirtynyt kertaluonteisesta massalatauksesta kohti jatkuvaa, harjoiteltavaa ja yhä automatisoidumpaa siirtymää. Selkein ilmaus tästä on muutosdatan talteenoton (change data capture) ja lähes reaaliaikaisen replikoinnin yleistyminen. Sen sijaan, että lähde jäädytettäisiin, poimittaisiin ja ladattaisiin uudelleen yhdessä jännittävässä ikkunassa, tiimit pystyttävät nyt kohdejärjestelmän, siementävät sen tietyn ajankohdan tilannevedoksesta ja virtauttavat sitten jatkuvat muutokset lähteestä kohteeseen, kunnes kaksi ovat samassa tahdissa. Kun hetki koittaa, jäljellä oleva ero on pieni ja katkos mitataan minuutteina. Tämä tekniikka, jota kutsutaan joskus trickle- eli online-migraatioksi, on hiljaa syrjäyttänyt perinteisen viikonloppulatauksen monissa korkean käytettävyyden ympäristöissä.

Cloud-kohteet ovat vahvistaneet tätä suuntausta. Migraatio hallittuun tietokantaan tai software as a service -alustaan poistaa osan infrastruktuurin vaivasta mutta kiristää rajoituksia sille, miten dataa voidaan ladata ja kuinka paljon kontrollia tiimi säilyttää kohteesta, mikä siirtää kurin takaisin poimintaan ja täsmäytykseen. Samaan aikaan migraation ympärillä oleva työkalusto on kypsynyt: profilointityökalut, jotka kartoittavat lähdedatan laadun ennen kuin ainoatakaan mäppäysriviä on kirjoitettu, muunnosputket, joita pidetään versionhallinnassa ja testataan kuten mitä tahansa muuta koodia, sekä automatisoidut täsmäytyskokonaisuudet, jotka vertaavat lähdettä ja kohdetta laajassa mittakaavassa otannan sijaan. Tärkein muutos on kulttuurinen. Johtavat tiimit harjoittelevat nyt koko vaihdon toistuvasti tuotannonkaltaista dataa vasten, kohdellen ensimmäistä, toista ja kolmatta pääharjoitusta tavanomaisena insinöörityönä eikä ylellisyytenä, jotta live-tapahtuma on esitys jo monta kertaa suoritetusta rutiinista.

Hyvä migraatioarkkitehtuuri on järjestetty yhden vaatimuksen ympärille: jokaisen sen esittämän väitteen on oltava todistettavissa. Tämä alkaa poiminnan, muunnoksen ja latauksen kolmen huolenaiheen erottamisesta, jotta kutakin voidaan tarkastella ja testata itsenäisesti. Poiminnan tulisi tallentaa johdonmukainen, aikaleimattu näkymä lähteestä, koska lähteen vielä muuttuessa otettu tilannevedos tuottaa tietoaineiston, jota ei koskaan todella ollut olemassa ja jota ei koskaan voida täsmäyttää. Muunnoksen tulisi olla nimenomainen ja tarkastettavissa, mäppäyssäännöt pidettyinä artefakteina eikä satunnaisiin skripteihin hautautuneina, jotta vastaus siihen, miksi tietty kenttä pitää sisällään tietyn arvon, on aina saatavilla. Latauksen tulisi kunnioittaa kohteen omia sääntöjä eikä ohittaa niitä, koska data, joka pakotetaan validoinnin ohi määräajan vuoksi, muuttuu virheeksi, joka nousee pintaan myöhemmin, huonompana hetkenä ja kauempana syystään.

Täsmäytys on koko suunnitelman kantava elementti, ja se toimii useilla tasoilla. Karkein on tarkistussummat: tietuemäärät sekä talous- tai määräsummat, joiden on täsmättävä lähteen ja kohteen välillä määriteltyjen toleranssien puitteissa. Hienompi on rivi- ja kenttätason vertailu, joka nappaa kiinni muunnoksen, joka hiljaa katkaisi arvon tai mappasi tilakoodin virheellisesti. Hienoin on liiketoimintasääntöjen täsmäytys, joka vahvistaa ei sitä, että data siirtyi, vaan että se merkitsee edelleen samaa asiaa, että avoin tilaus on edelleen avoin ja asiakassaldo edelleen täsmää. Oikeellisuuden todistamisen ohella arkkitehtuurin on suunniteltava rinnakkaiseloa ja perääntymistä varten. Rinnakkaiselo tarkoittaa päättämistä sille ajalle, jona molemmat järjestelmät ovat käytössä, kumpi omistaa kunkin tietoyksikön ja kuinka muutokset virtaavat niiden välillä, koska vaiheittainen käyttöönotto ilman määriteltyä omistajuutta tuottaa hajontaa, jota on hyvin vaikea purkaa. Perääntyminen tarkoittaa palautumisen suunnittelemista ensiluokkaisena kyvykkyytenä: määritelty laukaisin, tunnetusti kelvollinen palautuspiste, harjoiteltu menettely ja ratkaisevasti päätös siitä, mitä tapahtuu niille tapahtumille, joita liiketoiminta suoritti vaihdon jälkeen ja ennen päätöstä perääntyä. Palautussuunnitelma, joka ei osaa ottaa huomioon näitä tapahtumia, on suunnitelma vain nimeltään.

Migraation epäonnistuminen on kaavamaista eikä satunnaista, ja kaavat kannattaa nimetä, koska kullakin on erityinen vastatoimensa. Aliarvioitu datan laatu on yleisin ja syövyttävin. Lähdejärjestelmiin kertyy vuosien mittaan kaksoiskappaleita, orpoja tietueita, väärään kenttään syötettyjä arvoja ja koodeja, joiden merkitys on ajautunut ajan myötä. Mikään tästä ei näy esityksessä, ja kaikki tästä nousee pintaan sillä hetkellä, kun todellinen data kohtaa kohteen validoinnin. Vastatoimi on varhainen profilointi ja puhdistustyö, joka alkaa kauan ennen latausta, lähteessä, jossa liiketoiminta yhä ymmärtää datan.

Harjoittelematon vaihto on se epäonnistuminen, joka olettaa paperille kirjoitetun ajokäsikirjan suoriutuvan puhtaasti aikapaineen alla. Vaiheet, jotka lukevat triviaaleina, osoittautuvat kestävän tunteja, riippuvuus löydetään kesken ajon, eikä liikkumavaraa ole, koska sitä ei mitattu. Vastatoimi on täysimittainen harjoittelu realistisia volyymejä vasten, jokaisen vaiheen ajoituksen mittaaminen, kunnes ajokäsikirja on kirjaus jo tehdystä eikä toiveikas ennuste. Täsmäytys jälkiajatuksena on päätös todistaa oikeellisuus myöhemmin, mikä käytännössä tarkoittaa ei koskaan, ja mikä antaa hienovaraisen muunnosvirheen levitä jokaiseen alavirran raporttiin ja rajapintaan ennen kuin kukaan huomaa. Aavepalautuminen on suunnitelma, joka on olemassa asiakirjassa mutta jota ei koskaan testattu, joten kun sitä tarvitaan, palautuspiste on vanhentunut, menettely on virheellinen tai vaihdon jälkeisillä tapahtumilla ei ole mihinkään mennä. Lopuksi jäätynyt laajuus rinnakkaiselon aikana on organisatorinen epäonnistuminen, jossa välivaihe annetaan venyä loputtomiin molempien järjestelmien ollessa ylläpidossa, mikä kaksinkertaistaa operatiiviset kustannukset ja moninkertaistaa hajonnan pinnan. Jokainen näistä on vältettävissä, mutta vain kohtelemalla migraatiota insinöröitynä toimintana, jolla on omat testinsä, harjoituksensa ja hyväksymiskriteerinsä, eikä jonkun toisen projektin viimeisenä metrinä.

Nashua kohtelee ylitystä suunniteltuna tapahtumana alusta alkaen eikä tehtävänä, joka improvisoidaan lähellä käyttöönottoa. Toimeksiannot alkavat todellisen IT-ympäristön kartoituksesta: ei idealisoidusta arkkitehtuurikaaviosta vaan todellisista rajapinnoista, dokumentoimattomista syötteistä, järjestelmien välillä jaetusta perustiedosta ja lähdedatan todellisesta tilasta profiloinnin paljastamana. Tästä kuvasta valitsemme vaihtostrategian tietoisesti, punniten liiketoiminnan sietokykyä katkoksille, sen integraatioiden tiheyttä ja halukkuutta rinnakkaiseloon, ja kirjoitamme sen valinnan seurauksineen ylös emmekä oletusarvoisesti valitse sitä lähestymistapaa, joka on toimitustiimille kätevin.

Itse migraatio rakennetaan testattuina, versionhallittuina putkina, joissa on nimenomaiset mäppäykset, ja täsmäytys suunnitellaan rinnakkain latauksen kanssa eikä pultata jälkikäteen kiinni, jotta jokainen vaihe tuottaa näyttöä. Harjoittelemme vaihdon toistuvasti tuotannonkaltaista dataa vasten, ajoitamme jokaisen vaiheen ja hiomme ajokäsikirjaa, kunnes live-tapahtumaan ei sisälly yllätyksiä, ja rakennamme palautumisen todellisena, harjoiteltuna kyvykkyytenä, jolla on määritellyt laukaisimet ja selkeä selvitys vaihdon jälkeisistä tapahtumista. Missä vaiheittainen käyttöönotto on oikea, määrittelemme datan omistajuuden rinnakkaiselon ajalle täsmällisesti ja asetamme järjestelmien välisen täsmäytyksen aikatauluun, jotta hajonta napataan kiinni sen ollessa vielä pieni. Kaiken aikaa pidämme liiketoiminnan lähellä työtä, koska ne ihmiset, jotka ymmärtävät mitä data merkitsee, ovat ainoat, jotka voivat vahvistaa, että se merkitsee edelleen samaa toisella puolella. Tavoite on vaihto, jonka operatiivinen liiketoiminta kokee tapahtumaköyhänä, mikä on korkein kohteliaisuus, jonka migraatio voi saada.

Se ero, jonka Nashua tuo, ei ole yksittäinen työkalu tai patentoitu oikotie vaan vaatimus siitä, että migraatio on valmis vasta, kun se on todistettu, harjoiteltu ja tehty peruutettavaksi, sekä kuri pitää tuo standardi silloin, kun määräaika painaa ja kiusaus ohittaa todistus on voimakkaimmillaan. Olemme ylittäneet tämän ajanjakson riittävän monta kertaa, riittävän monissa ympäristöissä, tietääksemme, että se draama, jota tiimit pelkäävät vaihdossa, on lähes aina viivästynyt kustannus todistuksesta, jota ei koskaan tehty, tai harjoituksesta, jota ei koskaan ajettu, ja järjestämme toimeksiantomme niin, että nuo velat maksetaan aikaisin, päivänvalossa, eikä live-tapahtuman pikkutunneilla.

Tässä on myös käytännöllinen seuraus, joka muuttaa sen, mitä työ saa olettaa. Kun toimeksianto edellyttää kyvykkyyttä, jota ei vielä ole olemassa, sen ei tarvitse odottaa hankintasykliä tai toimittajan tiekarttaa. enterprise platform on rakennettu mukautumaan lähes mihin tahansa ominaisuuteen ripeästi, agenttipohjaisen insinöörityön kautta: tarvittava kuvataan selkokielellä ja generoidaan nopeasti, mutta aina lujien arkkitehtuuriperiaatteiden puitteissa ja tiukan laadunvarmistuksen alaisena, jotta nopeus ei koskaan tule eheyden, tietoturvan tai kontrollin kustannuksella. Vaikutus on strateginen eikä pelkästään kätevä. Se siirtää tee tai osta -rajaa, pitää optionaalisuuden edullisena ja antaa arkkitehtuurin seurata strategiaa sen sijaan, että strategia taipuisi siihen, mitä sattui olemaan hyllyllä.

Mitä tämä käytännössä tarkoittaa, on harkinnan jatkuvuus ensimmäisestä dataprofiilista siihen hetkeen, jolloin vanha järjestelmä lopulta poistetaan käytöstä. Samat ihmiset, jotka suunnittelivat täsmäytyksen, ovat läsnä sen ajossa, palautussuunnitelma on omistettu eikä arkistoitu, ja rinnakkaiseloaikaa ohjataan päätökseen eikä anneta ajautua. Nashuan asiakkaat eivät muista parhaita migraatioitaan, koska kunnolla tehty migraatio ei jätä liiketoimintaan arpea. Tuo tapahtumien puuttuminen on juuri se lopputulos, jonka tuottamiseen meidät palkataan, ja se on varmin mittari siitä, että ylitys oli insinöröity eikä siitä selvitty.