Legacy C2 -modernisointi: strangler fig -malli ja migraatiostrategiat

Jokainen puolustusorganisaatio, joka käyttää C2-ohjelmistoja, kohtaa lopulta saman ongelman: järjestelmä, joka voitti käyttöoikeutensa (Authority to Operate) vuosikymmen sitten, jonka ympärille operaattorit ovat rakentaneet menettelyt ja lihasmuistin, ja joka toimii luotettavasti ympäristöissä, joihin se suunniteltiin, ei laajennu helposti nykyisiin operatiivisiin vaatimuksiin. Uudet vaatimukset — avoimet API:t, pilveen käyttöönotettavat komponentit, moderni todennus, reaaliaikainen datan jako koalitiokumppaneiden kanssa — ovat arkkitehtuurikategorioita, joihin legacy-järjestelmää ei koskaan suunniteltu vastaamaan. Järjestelmän korvaaminen kokonaan yhden vaihtopäivän (flag day) siirrolla on operatiivisesti mahdotonta hyväksyä. Jättämällä sitä korvaamatta organisaatio kerryttää teknistä velkaa, joka kasvaa korkoineen joka vuosi. Insinöörivastaus on strangler fig: joukko malleja, joilla modernisoidaan vaiheittain, validoidaan jatkuvasti ja poistetaan vanha käytöstä vasta, kun korvaaja on todistanut itsensä todellisessa operatiivisessa kuormassa. Kaikki mitä tämä edellyttää — puolustusohjelmistojen kehityselinkaaresta ATO-strategiaan ja operaattorien muutoksenhallintaan — on vaativampaa kuin useimmat ohjelmat alkuvaiheessa odottavat.

Miksi legacy-C2-järjestelmät säilyvät

Legacy-C2-järjestelmien säilyminen puolustuksessa ei ole ensisijaisesti rahoitus- tai kulttuuriongelma, vaikka molemmat vaikuttavat osaltaan. Kyse on riskivaroitteluongelmasta, joka on juurtunut operatiiviseen todellisuuteen. C2-järjestelmä, joka pyörittää koalition ilmatilannekuvaa, tulitoiminnan koordinointisolua tai merialusten seurantatietokantaa, ei ole taustajärjestelmä, joka voidaan viedä pois käytöstä migraatioviikonlopun ajaksi. Se pyörii jatkuvasti, heikentyneissä ympäristöissä, todellisen operatiivisen tahdin paineessa. Järjestelmävika väärällä hetkellä ei ole myyntiraportin menetys — se on aukko ilmatilannekuvaan hetkellä, jolloin päätös on tehtävä.

Käyttöoikeussykli (Authority to Operate) vahvistaa tätä varovaisuutta. ATO ei ole vain tietoturvasertifikaatti; se on valtuuttavan viranomaisen (Authorizing Official) lausuma siitä, että järjestelmän riskiasema on hyväksyttävä määritellyssä operatiivisessa kontekstissa. ATO-paketit edustavat vuosien turvallisuuskontrollidokumentaatiota, tunkeutumistestausta ja riskin hyväksymistä. Järjestelmän korvaaminen merkitsee tämän luottamuksen hankkimista uudelleen tyhjästä, mikä vie tyypillisesti 18–36 kuukautta ja edellyttää, että korvaava järjestelmä on olennaisesti valmis ennen ATO-prosessin aloittamista. Tästä syntyy paradoksi: ohjelman on rakennettava korvaaja kykenemättä ottamaan sitä tuotantoon, eli rakennettava se ilman operatiivista palautetta, joka paljastaisi sen tärkeimmät viat.

Erikoislaitteistoriippuvuudet moninkertaistavat ongelmaa entisestään. Legacy-C2-järjestelmät ohjaavat usein vahvistettuja näyttöterminaaleja, laitteistoturvallisuusmoduuleja omisteisilla ajuripinoilla, MIL-STD-1553-väyläohjaimia ja sarjarajapintoja asejärjestelmiin ja sensoreihin. Näitä rajapintoja ei suunniteltu abstraktoitaviksi; ne on kovakytketty vanhan sovelluksen arkkitehtuuriin. Korvaavan järjestelmän on joko jäljennettävä nämä laitteistorajapinnat — mikä voi edellyttää kumppanuuksia alkuperäisten laitevalmistajien kanssa — tai tarjottava abstraktiokerros, jota laitteisto voi käyttää ilman muutoksia. Kumpikaan polku ei ole nopea tai halpa.

Lopuksi institutionaalinen tieto on upotettu vanhaan järjestelmään tavoilla, joita ei ole täysin dokumentoitu. Operaattorit ovat kehittäneet kiertoteitä tunnettuihin omituisuuksiin. Ylläpitäjät tietävät, mitkä prosessit on käynnistettävä uudelleen missäkin järjestyksessä minkä vikamallin jälkeen. Integraatiotiimit ovat koodanneet käsin kompensoivaa logiikkaa käsittelemään reunatapauksia, joita alkuperäinen spesifikaatio ei ennakoinut. Tämä tieto elää kokeneen henkilöstön päissä ja dokumentoimattomissa konfiguraatiotiedostoissa, ja se on saatettava esiin ja siirrettävä, ennen kuin vanha järjestelmä voidaan poistaa käytöstä — tehtävä, jonka modernisointiohjelmien suunnittelu aliarvioi johdonmukaisesti.

Strangler fig -malli C2-modernisointiin

Martin Fowler nimesi strangler fig -mallin trooppisen kasvin mukaan, joka kasvaa isäntäpuun ympärille ja ottaa hitaasti haltuunsa sen rakenteellisen roolin, kunnes isännän voi poistaa ilman että mikään romahtaa. Malli osuu täsmälleen C2-modernisointiongelmaan: rakennat uutta järjestelmää vaiheittain vanhan ympärille ja ohjaat yhä suurempaa osuutta liikenteestä uusiin komponentteihin sitä mukaa, kun kukin validoidaan, kunnes vanha järjestelmä ei käsittele mitään ja se voidaan poistaa käytöstä. Vaihtoehto — järjestelmän täydellinen uudelleenkirjoitus ja vaihto määriteltynä päivänä — epäonnistuu C2-ympäristöissä, koska uutta järjestelmää ei voida validoida todellisella operatiivisella kuormalla ennen kuin siitä tulee ainoa operatiivinen järjestelmä.

Ensimmäinen päätös strangler fig -migraatiossa on pilkoontumisakseli: miten vanhan järjestelmän kyvykkyydet jaetaan itsenäisesti migratoitaviin viipaleisiin. C2-järjestelmissä luonnollinen pilkoontuminen on kyvykkyysalueittain — seurannan hallinta, joukon tilanhallinta, viestintä, raportointi, tehtävänosoitus, näyttö — eikä arkkitehtuurikerroittain. Pystyviipaleet koko pinon läpi (tietokanta, liiketoimintalogiikka, API, näyttö) tuottavat itsenäisesti käyttöönotettavia ja itsenäisesti validoituja työyksiköitä. Vaakaviipaleet (migroi ensin tietokantakerros, sitten liiketoimintalogiikka, sitten näyttö) houkuttelevat arkkitehtuurin näkökulmasta, mutta ovat erittäin vaikeita validoida vaiheittain, koska mikään vaakakerros ei ole itsenäisesti käyttökelpoinen.

Liikenteen reititystä vanhan ja uuden järjestelmän välillä hallinnoi fasaadi — sieppaava kerros, joka istuu molempien järjestelmien edessä ja ohjaa jokaisen pyynnön yhteen tai molempiin. Varhaisissa migraatiovaiheissa fasaadi lähettää kaiken liikenteen vanhaan järjestelmään ja varjostaa lukuja uuteen järjestelmään vertailua varten. Luottamuksen kasvaessa fasaadi siirtyy ensisijaiseen reititykseen uuteen järjestelmään vanhan toimiessa varajärjestelmänä. Fasaadin on oltava tilaton ja erittäin saatavilla; se ei saa muodostua yksittäiseksi häiriöpisteeksi järjestelmässä, jossa vanha järjestelmä ei ennestään tarjonnut sellaista.

Feature parity -portti on muodollinen mekanismi, joka ohjaa sitä, milloin liikenne siirtyy. Ennen kuin mikään kyvykkyysalue voidaan siirtää kokonaan uuteen järjestelmään, sen on läpäistävä dokumentoitu joukko hyväksymiskriteerejä: toiminnallisen testikattavuus kaikille kyvykkyyden operaattorityönkuluille, suorituskykyvertailut, jotka osoittavat uuden järjestelmän saavuttavan vanhat vasteajat edustavassa kuormassa, ja datan täsmäytysmittarit, jotka osoittavat tilojen eron pysyvän sallituissa rajoissa jatkuvan havaintoikkunan yli. Portit ilman dokumentoituja kriteerejä muuttuvat epämuodollisiksi tarkistuspisteiksi, jotka ohjelmajohtajat läpäisevät arviolla näytön sijaan — juuri näin C2-ohjelmat tuottavat järjestelmiä, jotka kaatuvat operatiivisessa stressissä.

API-kääreet legacy-C2-komponenttien ympärille

Ensimmäinen konkreettinen insinöörityötuote kaikissa strangler fig -C2-migraatioissa on API-yhdyskäytäväkääre. Ennen kuin yhtään vanhaa kyvykkyyttä korvataan, vanha järjestelmä on kääritävä standardipohjaisen API:n taakse, jota uudet komponentit voivat kuluttaa tietämättä vanhan toteutuksen yksityiskohtia. Tämä kääre on sauma, joka tekee koko migraatiosta palautettavan: niin kauan kuin kääre on paikallaan, vanhaa järjestelmää voidaan kutsua minkä tahansa vielä siirtämättömän kyvykkyyden osalta, ja uusia järjestelmäkomponentteja voidaan rakentaa puhdasta sopimusta vasten eikä vanhan järjestelmän omalle liittymälle.

Kääreen suunnittelu riippuu suuresti siitä, mitä vanha järjestelmä tarjoaa. 1990-luvun ja 2000-luvun alun vanhemmat C2-järjestelmät tarjoavat tyypillisesti omisteisia sarjaprotokollia — valmistajakohtaisia binäärikomentokehyksiä RS-232-, RS-422- tai MIL-STD-188-114-piirien yli. Kääreen on toteutettava sarjakehyksen dekoodaaja ja enkoodaaja, kuvattava komentojen merkityssisältö HTTP- tai gRPC-metodeiksi ja hallittava vanhan protokollan pyyntö–vastaus-mallin sisältämä tilakone. Tämä ei ole loistavaa työtä, mutta juuri siellä suurin osa varhaisen migraation riskistä asuu: sarjadekoodaajan vika, joka hiljaisesti vioittaa komennon, on paljon vaikeampi havaita kuin kahden JSON-skeeman välinen ero.

Järjestelmissä, joissa on omisteisia verkkoprotokollia tai valmistajakohtaisia väliohjelmisto-API:ita, kääre on käsitteellisesti samanlainen, mutta toteutuspinta on eri. Kääreen on sisällytettävä valmistajan asiakaskirjasto riippuvuuspuihinsa, hallittava istunnon elinkaari valmistajan yhteytmallin mukaan ja käännettävä virhekoodit valmistajan nimiavaruudesta uuden API:n määriteltyyn virhetaksonomiaan. API-yhdyskäytävät puolustusjärjestelmissä -arkkitehtuurin on myös ratkaistava suorituskykyvaran kysymys: vanhat järjestelmät on usein suunniteltu käsittelemään tietty viestitahti ilman varaa. Käärekerroksen lisääminen, joka multipleksoi useiden uusien komponenttien kutsut saman vanhan liittymän läpi, voi kyllästyttää vanhan järjestelmän kuormissa, jotka eivät ennen stressanneet sitä. Vanhan järjestelmän läpäisykatkaisun profilointi on kääresuunnittelun edellytys, ei jälkikäteen tullut ajatus.

Kääreen sisällä olevan viestikäännöskerroksen on oltava eksplisiittinen siitä, mitä se ei pysty kääntämään. Jotkin vanhat C2-kentät kantavat merkityksiä, joilla ei ole vastinetta modernissa API:ssa — tilakoodit, jotka koodaavat useita toisiinsa nähden ortogonaalisia tiloja yhteen tavuun, ajoituskentät, jotka olettavat tietyn laitteistokellon, tai dataelementit, jotka ovat merkityksellisiä vain saman viestin muiden kenttien kontekstissa. Nämä epäsuhtaerot on dokumentoitava kääreen liittymäspesifikaatiossa ja tuotava esiin uuden järjestelmän API:ssa eksplisiittisinä nolla- tai tuntemattomina arvoina, ei hiljaisesti pakotettuina oletusarvoiksi, jotka näyttävät uskottavilta mutta ovat vääriä.

// Example: REST facade over proprietary serial C2 command interface
// POST /api/v1/tracks/{trackId}/status
{
  "status": "HOSTILE",              // mapped from legacy 3-bit identity code
  "confidence": "HIGH",             // derived from legacy quality indicator
  "lastUpdated": "2026-06-25T09:14:32Z",
  "legacyRaw": {                    // passthrough for audit/debug
    "systemId": "C2-LEGACY-01",
    "frameType": 0x4A,
    "identityCode": 6,
    "qualityWord": 255
  },
  "_translation": {
    "unmappedFields": ["correlation_index"],  // legacy field with no v1 equivalent
    "warnings": []
  }
}

Datan migraatio vanhasta tallennuksesta

Legacy-C2-järjestelmät kattavat poikkeuksellisen laajan kirjon datan säilytysteknologioita, ja poimintalähestymistapa on räätälöitävä kuhunkin. Vanhimmat järjestelmät käyttävät IMS-hierarkiatietokantoja tai COBOL-määriteltyjä tasatiedostotietuemäärittelyjä — muotoja, jotka olivat valtavirrassa järjestelmiä suunniteltaessa mutta jotka edellyttävät tänään erikoistyökaluja. IMS-segmentin poimijoita on kaupallisina apuohjelmina, mutta ne vaativat alkuperäiset IMS-tietokantamäärittelyt (DBD) ja ohjelmamääritysblokit (PSB), jotka saattavat olla olemassa vain painettuna kansiossa, jonka jonkun on löydettävä ja skannattava. COBOL-tasatiedostorakenteet edellyttävät binääritietuerakenteen tulkintaa COBOL-copybookeilla; jos copybookit ovat kadonneet, rakenteen käänteissuunnittelu datasta itsestään ja sovelluslähdekoodista on mahdollista mutta aikaa vievää.

Keskipolven järjestelmät käyttävät tyypillisesti Oracle- tai Sybase-relaatiotietokantoja, joiden skeemat heijastavat vuosikymmenten kehitystä — tauluja, jotka on lisätty ilman normalisointia; sarakkeita, jotka on otettu uudelleenkäyttöön alkuperäisestä merkityksestään; viiteehtoja, jotka on poistettu käytöstä erälatausten sallimiseksi; ja yhdistettyjä perusavaimia, jotka koodaavat useita liiketoimintakäsitteitä. Näiden järjestelmien poimintavaihe on skeema-arkeologian harjoitus: sovelluslähdekoodin lukeminen ymmärtääkseen, miten kenttiä oikeasti tulkitaan — ei vain sitä, mitä niiden sarakenimet vihjaavat — ja semanttisen kartoituksen rakentaminen vanhasta kentästä tarkoitettuun liiketoimintakäsitteeseen.

Datalaadun korjaus on vaihe, jonka useimmat migraatio-ohjelmat aliarvioivat. Legacy-C2-sovellukset sisältävät kompensoivaa koodia, joka hiljaisesti korjaa tai ohittaa datalaatuongelmia — puuttuvien arvojen käsittelyn, arvojen rajauksen, duplikaattien tukahduttamisen — joita tietokanta itse ei pakota. Kun tämä data migratoidaan uuteen järjestelmään tiukemmalla validoinnilla, laatuongelmat nousevat esiin migraatiovirheinä. Korjausputken on luetteloitava nämä ongelmat systemaattisesti, luokiteltava ne juurisyyn mukaan ja sovellettava muunnoksia, jotka säilyttävät datan operatiivisen tarkoituksen sen sijaan, että hylättäisiin tietueet, jotka eivät läpäise validointia. Tietue, jossa on tyhjä sijaintikenttä ja kelvollinen seurannan tunniste, tulisi migratoida seurannaksi, jonka sijainti on tuntematon, ei hylätä.

Skeemankehityskartoitus kääntää korjatun vanhan datan kohdeskeemaan. Tämä vaihe edellyttää päätöksiä tietueista, joilla ei ole suoraa vastinetta — vanhat tilakoodit, jotka ulottuvat useisiin kohdekenttiin, historialliset tietueet muodoissa, joita uusi järjestelmä ei tue, ja dataelementit, jotka olivat kelvollisia vanhan järjestelmän sääntöjen mukaan mutta ovat merkitykseltään monitulkittisia uudessa skeemassa. Nämä päätökset on dokumentoitava, asiantuntijoiden arvioitava ja hyväksyttävä ennen migraatioajoja, koska ne vaikuttavat siihen tilannekuvaan, jonka operaattorit näkevät uudessa järjestelmässä rinnakkaisajon ensimmäisenä päivänä.

Rinnakkaisajostrategia

Rinnakkaisajo on vaihe, jonka aikana vanha ja uusi järjestelmä pyörivät samanaikaisesti ja molemmat ovat auktoritatiivisia — tai tarkemmin: vaihe, jonka aikana vanha järjestelmä pysyy ainoana totuuden lähteenä, kun uuden järjestelmän tarkkuutta validoidaan sitä vastaan. Mahdollistava mekanismi on kaksoiskirjoitus: jokainen fasaadille saapuva tilaa muuttava komento suoritetaan molempiin järjestelmiin ennen vastauksen palauttamista. Tämä tarkoittaa, että jokainen operaattorin toimenpide, jokainen saapuva datasyöte ja jokainen automatisoitu tilanmuutos kirjoitetaan vanhan tietokannan ja uuden järjestelmän tietokannan samaan transaktioikkunaan, jolloin uudella järjestelmällä on jatkuvasti ajan tasalla oleva kopio operatiivisesta tilasta, johon sitä voidaan verrata.

Täsmäytyspalvelu on väline, joka muuttaa kaksoiskirjoituksen toiminnalliseksi laadundataksi. Se ajaa säädettävällä aikavälillä — tyypillisesti muutaman minuutin välein validoinnin aikana, tunneittain vakaassa tilassa — ja vertaa kahden järjestelmän tietokantoja tietue kerrallaan raportoiden kenttätason erot kaikkien entiteettityyppien osalta. Täsmäytystulokset kerätään aikasarjavarastoon ja esitetään laadun ohjausnäkymässä, joka näyttää eromäärät entiteettityypin, kentän ja ajanjakson mukaan. Nouseva eromäärä tietyssä kentässä tietyn ajan hetken jälkeen on diagnostinen signaali: operatiivisessa ympäristössä tai migraatiokonfiguraatiossa tapahtui muutos, joka rikkoi kyseisen kentän käännöksen. Täsmäytystyökalu ei ole valinnainen infrastruktuuri; se on ensisijainen näytteistö feature parity -portille ja myöhemmin ATO-muutospaketille.

Operaattorien kaksipaneelikäyttöliittymä on rinnakkaisajon operatiivinen ilmentymä. Nimitetyillä operaattoreilla — tyypillisesti pienellä ryhmällä kokeneita käyttäjiä, jotka vapaaehtoisesti ottavat validointiroolin — on käytössään rinnakkaisnäkymä vanhasta ja uudesta järjestelmästä omalla operatiivisella alueellaan. He käyttävät uutta järjestelmää ensisijaisena käyttöliittymänään ja turvautuvat vanhaan näkymään ristiintarkistukseen epävarmojen tietojen kohdalla. Havaitessaan eroavaisuuden he lähettävät jäsennellyn raportin kaksipaneelinäyttöön integroidun palautemekanismin kautta: entiteettityyppi, kenttä, vanha arvo, uusi arvo ja operatiivinen vakavuusluokitus. Nämä operaattoriraportit syöttävät suoraan defektiseurantaan ja osallistuvat feature parity -portin arviointiin automaattisen täsmäytysdatan rinnalla. Kaksipaneelikäyttöliittymä on nimenomaisesti väliaikainen ja se on poistettava heti, kun pariteetti on muodostettu — sen ylläpitäminen loputtomiin luo kognitiivista kuormaa ja viestii operaattoreille, ettei uuteen järjestelmään voi luottaa ilman varanäkymää.

ATO-strategia modernisointiin

ATO-dimensio on C2-modernisointiohjelman osa, jossa strangler fig -malli vaatii huolellisinta koordinaatiota valtuuttavan virkamiehen (Authorizing Official, AO) organisaation kanssa. Uuden C2-järjestelmän täysi ATO-uudelleenvaltuutus kestää 18–36 kuukautta ja edellyttää, että järjestelmä on olennaisilta osin valmis ja vakaassa konfiguraatiossa, ennen kuin arviointiprosessi voi alkaa. Tämä aikataulu ei sovi yhteen vaiheittaisen migraation kanssa, jossa uusia komponentteja otetaan käyttöön jatkuvasti usean vuoden ajan. Ratkaisu on vaiheittainen ATO-muutosstrategia, mutta se on sovittava AO:n kanssa ennen migraation alkua — sen esittäminen toteennäytettynä tosiasiana käyttöönoton jälkeen on suhteita vaurioittava virhe, joka hidastaa jokaista myöhemmää siivua.

Vaiheittaista muutosmenettelyä sovelletaan seuraavasti: vanhan järjestelmän voimassa oleva ATO säilytetään koko migraation ajan. Jokainen strangler-siivu toimitetaan turvallisuusvaikutusanalyysiin (Security Impact Analysis, SIA) täyttä uudelleenvaltuutusta sen sijaan. SIA arvioi vain uuden komponentin tuoman muutoksen turvallisuusasemassa: lisääntyneen hyökkäyspinnan (uudet verkkoliitynnät, uudet todennusvirrat, uudet tietovirrat), olemassa olevan valtuutusrajan turvallisuuskontrollit, joiden varaan komponentti nojaa, sekä kaikki uudet riskit, joita se tuo. Jos SIA katsoo, että siivu pysyy olemassa olevan valtuutusrajan sisällä eikä tuo riskejä, jotka edellyttävät täyttä uudelleenarviointia, AO myöntää ATO-muutoksen uuden ATO:n sijaan. Tämä lyhentää siivukohtaisen turvallisuusvaltuutussyklin kuukausista viikkoihin, kunhan siivut suunnitellaan puhtailta turvallisuusrajoiltaan alusta alkaen.

SIA-käsittelyn helpottamiseksi suunnittelu tarkoittaa, että jokaisella siivulla on oltava nimenomaiset turvallisuusrajat: määritellyt verkon sisääntulo- ja ulosmenopisteet, dokumentoitu tietovirta siivusta vanhaan järjestelmään API-kääreen kautta sekä selkeä lausunto siitä, mitkä turvallisuuskontrollit siivu perii olemassa olevasta rajasta ja mitkä se toteuttaa itsenäisesti. Siivut, jotka ulottuvat syvälle vanhan järjestelmän turvallisuusarkkitehtuuriin — koskien todennusta, avainten hallintaa tai luokittelun käsittelyä — ovat ehdokkaita täyteen uudelleenvaltuutukseen muutoksen sijaan. Tunnista nämä ajoissa ja suunnittele niiden ATO-aikataulu sen mukaisesti. Puolustusorganisaatioiden digitaalista transformaatiota käsittelevä käsikirja nostaa johdonmukaisesti ATO-syklin hallinnan modernisaatioaikataulun pisimpään kestäväksi tekijäksi.

Jatkuva ATO-malli — jatkuvan valtuutusprosessin ylläpitäminen jatkuvalla valvonnalla ajankohdan arviointien sijaan — on modernisoitujen C2-järjestelmien lopullinen tavoite. Se edellyttää kypsää turvallisuustietojen ja tapahtumien hallintakyvykkyyttä, automatisoitua kontrollien arviointityökalustoa sekä AO-organisaatiota, joka on resursoitu jatkuvaan sitoutumiseen kausittaisen katselmuksen sijaan. Useimmat ohjelmat saavuttavat jatkuvan ATO:n tavoitteena vanhan järjestelmän jälkeiselle tilalle, ei migraation edellytyksenä, mutta valvontainfrastruktuurin rakentaminen jo migraatiovaiheessa on sekä mahdollista että hyödyllistä.

Ihmisten ja prosessien muutoksenhallinta

Strangler fig -malli ratkaisee C2-modernisoinnin teknisen riskin, mutta ihmisriski on vähintään yhtä suuri, eikä yksikään yllä kuvatuista suunnittelumalleista käsittele sitä. Operaattorit, jotka ovat työskennelleet vanhan C2-järjestelmän kanssa vuosia, ovat rakentaneet kognitiivisia malleja sen käyttäytymisestä — miten se näyttää maalitiedot, miten se vastaa komentoihin, miten se käyttäytyy tietyissä vikatiloissa — eivätkä nämä mallit siirry uuteen järjestelmään automaattisesti. Uusi järjestelmä, jossa on erilainen näyttöparadigma, erilaiset pikanäppäimet ja erilaiset virheilmoitukset, hidastaa operaattoreita juuri niillä hetkillä, jolloin nopeus merkitsee eniten. Uudelleenkoulutus ei ole koulutustapahtuma; se on jatkuvaa valvottua harjoittelua operatiivisissa olosuhteissa.

Paluun laukaisimet ja kriteerit on sovittava ja dokumentoitava ennen rinnakkaiskäyttöjakson alkua, neuvottelematta jälkeenpäin silloin, kun ohjelma on paineessa julistaa onnistumista. Paluun laukaisimet jakautuvat kahteen luokkaan: määrälliset (automaattisen täsmäytyksen ero ylittää kynnyksen, operaattorien virhetahti nousee perustason yli, kriittisen operaation viive ylittää vaatimuksen) ja laadulliset (muodollinen operaattorien luottamusäänestys jää kynnyksen alle, uuteen järjestelmään liitetty turvallisuuspoikkeama, AO peruuttaa valtuutusmuutoksen). Jokaisella laukaisimella on oltava määritelty mittausmenetelmä, määritelty kynnys ja määritelty eskalointipolku. Itse paluumenettely on harjoiteltava ennen rinnakkaiskäyttöjakson alkua, ja harjoituksen on katettava koko vaihejaksot laukaisimen toteamisesta vanhan järjestelmän ensisijaisuuden palauttamiseen, aikapaineessa, henkilöstön kanssa, joka käytännössä sen toteuttaa.

Auringonlaskun aikataulun hallinto on viimeinen mekanismi, joka estää migraatio-ohjelmia venymästä loputtomiin. Vanhalla järjestelmällä on oltava muodollinen hallintorakenne — sunset-lautakunta, johon kuuluu edustajia operaattoreista, ohjelmajohtamisesta, AO:n organisaatiosta ja kaikista ulkoisista järjestelmistä, jotka integroituvat vanhaan — joka kokoontuu säännöllisesti arvioimaan edistymistä suhteessa sunset-aikatauluun ja tekemään sitovia päätöksiä yksittäisten komponenttien käytöstäpoistopäivistä. Ilman tätä hallintoa vanha järjestelmä pysyy hengissä, koska kenelläkään ei ole valtaa sammuttaa sitä, ja reunaintegraatiot, joille ei koskaan budjetoitu migraatiota, muuttuvat pysyviksi syiksi pitää se käynnissä. Sunset-lautakunnalla on oltava valta asettaa kovat määräajat reunaintegraatioiden migraatiolle ja panna ne täytäntöön tarjoamalla resursseja, ei vain vaatimalla noudattamista.

Ensimmäisestä strangler-siivusta vanhan järjestelmän täydelliseen käytöstäpoistoon kuluu tyypillisesti kolmesta seitsemään vuotta monimutkaisessa C2-järjestelmässä. Ohjelmat, jotka suunnittelevat kaksi vuotta ja kohtaavat kolme, menestyvät hyvin; ohjelmat, jotka suunnittelevat kaksi vuotta ja kohtaavat seitsemän, ovat yleensä epäonnistuneet ottamaan huomioon reunaintegraatiot, ATO-syklien kestot ja sen kognitiivisen kuorman, jonka migraatio-ohjelman ylläpito henkilöstön kiertojen läpi aiheuttaa. Realististen odotusten asettaminen ohjelman käynnistyksessä — rahoitusviranomaiset mukaan lukien, joiden on ymmärrettävä, että modernisointi ei ole projekti kiinteällä päättymispäivällä vaan jatkuvaa insinöörityön kuria — on itsessään muutoksenhallintatehtävä, jonka ohjelmapäällikön on toteutettava ennen ensimmäistäkään koodiriviä.