Legacy-migraation alussa aikataulu näyttää aina uskottavalta. Vanha järjestelmä ymmärretään, ainakin sen rakentaneiden ihmisten toimesta. Uusi järjestelmä on suunniteltu. Laajuus on määritelty. Kuusi kuukautta on optimistinen arvio, mutta ei absurdi. Kaksitoista kuukautta on varovainen. Kahdeksantoista kuukautta olisi noloa myöntää johdolle.
Kolme vuotta myöhemmin migraatio on joko yhä käynnissä, se on kaikessa hiljaisuudessa peruttu, tai se on valmistunut muodossa, joka vaati niin monia kompromisseja, että osa alkuperäisistä ongelmista yksinkertaisesti toisinnettiin uuteen koodipohjaan. Tämä ei ole epätavallinen lopputulos. Se on kaikkein yleisin.
Selitys, johon useimmat tiimit tukeutuvat, on tekninen: vanha järjestelmä oli odotettua monimutkaisempi, uudella alustalla oli odottamattomia rajoitteita, datamalli ei kääntynyt puhtaasti. Nämä asiat pitävät paikkansa, ja ne vaikuttavat aikatauluun. Mutta ne eivät ole syy siihen, miksi migraatiot kestävät kolme vuotta. Syyt ovat lähes täysin organisatorisia.
Korvattavaa järjestelmää ei koskaan ymmärretä täysin
Legacy-järjestelmiin kertyy liiketoimintalogiikkaa samaan tapaan kuin vanhoihin rakennuksiin kertyy kantavia seiniä. Jotain lisättiin käsittelemään edge case -tapausta vuonna 2009. Jotain muuta paikattiin asiakaspoikkeuksen hoitamiseksi vuonna 2013. Laskutoimitusta säädettiin hieman vuonna 2017, koska joku huomasi lukujen olevan väärin tavalla, jota kukaan ei osannut täysin selittää. Kunkin muutoksen tehnyt henkilö ei välttämättä ole enää yrityksen palveluksessa. Syytä sille, miksi se toimii kuten se toimii, ei usein ole kirjattu ylös mihinkään.
Migraation discovery-vaihe — se osa, jossa selvitetään mitä vanha järjestelmä todellisuudessa tekee — on lähes aina alimitoitettu. Tiimit käyttävät kaksi viikkoa discovery-vaiheeseen ennen suunnittelun aloittamista, eivät löydä ilmeisiä yllätyksiä ja päättelevät, että järjestelmä ymmärretään hyvin. Sitten he viettävät seuraavat kahdeksantoista kuukautta löytäen yllätyksiä.
Rehellisempi lähestymistapa on olettaa, että legacy-järjestelmä sisältää karkeasti kolme kertaa enemmän dokumentoimatonta liiketoimintalogiikkaa kuin kukaan tällä hetkellä uskoo, ja suunnitella discovery-vaihe sen mukaisesti. Käytännössä tämä tarkoittaa vanhan ja uuden järjestelmän ajamista rinnakkain pidempään kuin tuntuu mukavalta, sen hyväksymistä, että jotkin edge case -tapaukset nousevat esiin vasta kun todelliset käyttäjät kohtaavat ne tuotannossa, ja legacy-järjestelmän käyttäytymisen pitämistä spesifikaationa vaatimusmäärittelydokumentin sijaan.
Ihmiset, jotka tuntevat vanhan järjestelmän, eivät koskaan ole täysin käytettävissä
Legacy-migraation asiantuntijat — ihmiset, jotka ymmärtävät miksi järjestelmä käyttäytyy kuten se käyttäytyy — ovat lähes aina samoja ihmisiä, jotka ovat vastuussa päivittäisen liiketoiminnan pyörittämisestä. Heitä ei voida siirtää täysipäiväisesti migraatioprojektiin ilman, että projektia rahoittava operatiivinen toiminta kärsii.
Tyypillisesti päädytään kompromissiin: asiantuntijat osallistuvat työpajoihin, vastaavat kysymyksiin tarpeen mukaan ja katselmoivat toimituksia silloin kun ehtivät. Tämä toimii riittävän hyvin alkuvaiheessa, kun kysymykset ovat strategisia. Siitä tulee pullonkaula implementaation aikana, kun kysymykset ovat yksityiskohtaisia: mitä pitäisi tapahtua, kun tämä kenttä on null? Onko tämä käyttäytyminen tarkoituksellista vai bugi? Mitä tämä status code tarkoittaa juuri tämän workflow'n kontekstissa?
Nämä kysymykset eivät ole vaikeita. Jokaiseen vastaaminen vie kymmenen minuuttia. Mutta niitä on tuhansia, ne ilmenevät ennalta-arvaamattomasti, ja jokainen niistä voi blokata sprintin, jos oikea henkilö ei ole tavoitettavissa. Migraatioon kertyy odotusaikaa pätkissä, jotka eivät koskaan näy yksittäisinä esteinä statusraportissa, mutta jotka yhdessä muodostavat kuukausien edestä kulunutta kalenteriaikaa.
Sidosryhmien tuki rapautuu
Migraatiota sponsoroinneella johtajalla oli selkeä peruste: vähentää operatiivisia kuluja, eliminoida teknistä velkaa, mahdollistaa kyvykkyyksiä, joita vanha järjestelmä ei pystynyt tukemaan. Tämä peruste oli tarpeeksi vakuuttava budjetin ja aikataulun turvaamiseksi. Kahdeksantoista kuukautta projektin alkamisen jälkeen kyseinen johtaja on siirtynyt uuteen rooliin. Hänen seuraajansa peri projektin perimättä kuitenkaan sitä vakaumusta, joka toimi sen liikkeellepanevana voimana.
Tämä ei ole yksilöiden epäonnistuminen. Se on rakenteellinen ominaisuus, joka johtuu siitä, kuinka kauan migraatiot kestävät suhteessa organisaatioiden muuttumisnopeuteen. Kolmivuotinen projekti kestää keskimäärin kauemmin kuin sen tilaajan toimikausi. Kun näin tapahtuu, projekti menettää organisaatiotason tukijansa juuri sillä hetkellä, kun se todennäköisimmin sellaista tarvitsee — vaikean keskivaiheen aikana, jolloin vanha järjestelmä on yhä käynnissä, uusi järjestelmä ei ole vielä valmis, ja tiimi pyytää lisää aikaa ja rahaa kuroakseen umpeen näiden välisen kuilun.
Tästä siirtymästä selviytyvät ne migraatiot, joilla on hajautettu sponsorointi — joissa tarpeeksi moni ihminen riittävän monella tasolla ymmärtää miksi projekti on olemassa, jotta se voi selvitä kenen tahansa yksittäisen puolestapuhujan lähdöstä. Tämän luominen on vaikeampaa kuin yhden johtajatason sponsorin löytäminen, ja se syntyy harvoin luonnostaan. Se on rakennettava tarkoituksella, yleensä säännöllisen viestinnän avulla ydinprojektitiimiä laajemmalle yleisölle.
Kahdeksankymmenen prosentin valmiusaste on ansa
Migraation vaarallisin virstanpylväs on kahdeksankymmenen prosentin valmiusaste. Siinä vaiheessa uusi järjestelmä käsittelee kaikki yleiset tapaukset. Pääasialliset workflow't toimivat. Kohtuullinen demo on mahdollista antaa. Jäljelle jäävä kaksikymmentä prosenttia on lista edge case -tapauksista, poikkeuksista ja epätavallisista skenaarioista, joiden käsittelyä on lykätty, jotta pääpolku on saatu pidettyä liikkeessä.
Tuo kaksikymmentä prosenttia edustaa vuosien tuotantokäytön kerryttämää kompleksisuutta. Jokainen listan kohta on siellä, koska todellinen käyttäjä kohtasi todellisen tilanteen, jota standardi workflow ei osannut käsitellä. Yhdessä ne koodaavat sisäänsä suurimman osan siitä institutionaalisesta tiedosta, joka koskee sitä, miten liiketoiminta todellisuudessa toimii, vastakohtana sille miten sen oletetaan toimivan.
Niiden läpikäyminen on hidasta, koska jokainen kohta vaatii saman syklin: ymmärrä alkuperäinen skenaario, suunnittele sen käsittely, implementoi se, ja validoi se domainin tuntevien ihmisten kanssa. Mittakaavaetuja ei ole. Sadas edge case ei ole nopeampi käsitellä kuin ensimmäinen. Eikä lista kutistu tasaisesti — sillä on taipumus kasvaa, kun uutta järjestelmää käytetään laajemmin ja esiin nousee skenaarioita, joiden olemassaolosta ei aiemmin tiedetty.
Kahdeksankymmentä prosenttia aikataulussa saavuttavat tiimit huomaavat usein, että jäljellä oleva kaksikymmentä prosenttia vie yhtä kauan kuin ensimmäiset kahdeksankymmentä. Tämä ei ole suunnittelun epäonnistuminen. Se on matemaattinen ominaisuus sille, missä näiden järjestelmien kompleksisuus piilee.
Mitä yhteistä on migraatioilla, jotka saadaan valmiiksi
Legacy-migraatioilla, jotka todella saadaan valmiiksi, on muutamia yhteisiä piirteitä, jotka eivät ole ilmeisiä alussa.
Ne kohtelevat cutoveria suunniteltavana tapahtumana, ei kynnyksenä joka on ylitettävä. Hetki, jolloin vanha järjestelmä sammutetaan ja uudesta järjestelmästä tulee system of record, on koko projektin riskialttein piste. Organisaatiot, jotka suunnittelevat tämän tapahtuman eksplisiittisesti — kuka voi tehdä rollbackin, millä ehdoilla, kuka tekee päätöksen, mikä määrittelee onnistuneen ensimmäisen viikon — navigoivat sen todennäköisemmin läpi ilman kriisiä, joka nollaa aikataulun jälleen kuudella kuukaudella.
Ne ajavat vanhaa ja uutta järjestelmää rinnakkain pidempään kuin oli suunniteltu. Tämä on kallista ja operatiivisesti epämukavaa. Se tuo myös esiin edge case -tapaukset, joita automaattinen testaus ei havaitse, ennen kuin niistä tulee tuotantohäiriöitä järjestelmässä, jolla ei ole enää fallback-vaihtoehtoa.
Ne rajaavat migraation laajuuden toimittamaan arvoa inkrementaalisesti sen sijaan, että se vietäisiin päätökseen yhdellä cutoverilla. Huonoimmat migraatiot ovat niitä, joissa mitään ei voida poistaa käytöstä ennen kuin kaikki on valmista. Parhaat tunnistavat, mitkä osat vanhasta järjestelmästä voidaan ajaa alas itsenäisesti, ja vaiheistavat työn tuottaakseen näkyviä voittoja ennen kuin projekti on kolme vuotta vanha.
Ja ne ovat rehellisiä jo varhaisessa vaiheessa siitä, mikä todellinen aikataulu on. Ei siksi, että haluttaisiin pelata varman päälle, vaan koska organisaatio, joka tietää projektin kestävän kolme vuotta, voi rakentaa itsensä ylläpitämään sitä. Organisaatio, joka uskoo projektin kestävän kuusi kuukautta ja jolle kerrotaan toistuvasti sen olevan melkein valmis, menettää kärsivällisyytensä vauhdilla, josta projekti ei voi selviytyä.