Mitä tehdä verkkosivustolle, jossa on vanha PHP- tai Node.js-versio?

Lyhyt vastaus on tämä: sivustolla, jolla on vanha PHP- tai Node.js-versio, on kolme polkua — sovittaa koodi tuettuun versioon, rakentaa sivusto uudelleen tai pitää se toistaiseksi alustalla, joka yhä tekee vanhaan runtimeen backportin tietoturvakorjauksista, ja suunnitella siirto sillä välin rauhassa. Neljättä polkua, jossa kaiken jättää ennalleen siksi, että sivusto kerran toimii, ei oikeastaan ole, koska PHP 8.1 ja sitä vanhemmat release branchit eivät enää saa korjauksia PHP-projektilta, eikä Node.js:n 18. eikä 20. release line myöskään, ja lokakuu 2026 näytti molemmissa, mitä se käytännössä tarkoittaa.

Sivusto, jolla on vanha PHP-versio, ei tavallisesti ole poikkeus eikä mikään erityinen huolimattomuus. Se tehtiin viisi tai kahdeksan vuotta sitten, sen rakentanut kehittäjä on jo kauan työskennellyt muualla, ja sivusto on kaikki nämä vuodet palvellut ilman suuria ongelmia: ottanut vastaan hakemuksia, näyttänyt hintoja ja lähettänyt laskuja. W3Techsin tietojen mukaan lokakuussa 2026 PHP:tä käyttävistä sivustoista 26,8 % toimi PHP 7:llä ja vielä 7,7 % PHP 5:llä, eli yli kolmannes niistä käyttää PHP:tä, jonka elinkaari on päättynyt (EOL) jo vuosia sitten. Kysymys nousee tavallisesti vasta sitten, kun hosting-palveluntarjoaja lähettää varoituksen tai kun jokin haavoittuvuus päätyy uutisiin.

Milloin PHP- tai Node.js-versiosta tulee vanha

”Vanha” ei tässä ole makukysymys, sillä sekä PHP että Node.js julkaisevat aikataulun, jossa kerrotaan, mihin päivään asti kukin release branch tai release line saa korjauksia. PHP antaa kullekin release branchille kaksi vuotta Active supportia ja vielä kaksi vuotta, jolloin ilmestyy vain tietoturvakorjauksia, ja sen jälkeen release branchin elinkaari on päättynyt eikä sitä tueta enää millään tavalla. Node.js:n pitkäaikaisen tuen (LTS) release lineille tulee lopuksi Maintenance LTS -vaihe, ja kun se päättyy, release line ei saa enää yhtään julkaisua, ei silloinkaan, kun uusi haavoittuvuus koskee juuri sitä.

Taulukossa ovat ne release branchit ja release linet, joita nykyisin kohtaa useimmin, ja niiden tila lokakuussa 2026. Päivämäärät on otettu PHP:n elinkaaren päättymisten luettelosta ja Node.js:n julkaisuaikataulusta, ja molemmat lähteet on syytä tarkistaa jatkossakin, koska niihin ilmestyy joka vuosi uusia rivejä.

Kaksi riviä tässä taulukossa kannattaa lukea uudelleen. PHP 8.2:n elinkaari päättyy 31. joulukuuta 2026, joten sivusto, joka syksyllä 2026 näyttää ajanmukaiselta, on tammikuussa 2027 samassa tilanteessa kuin sivusto, jolla on PHP 7.4, ja siirto kannattaa suunnitella jo nyt, kun sen voi tehdä ilman kiirettä. Node.js:n 20. release line oli vielä vuoden 2024 syksyllä Active LTS -vaiheessa, siinä pitkäaikaisen tuen vaiheessa, jolle aloitettiin monia uusia projekteja, mutta 30. huhtikuuta 2026 sen elinkaari päättyi. Vanhentuminen ei tapahdu vähitellen: yhtenä tiettynä päivänä runtime siirtyy tilasta ”saa korjauksia” tilaan ”ei saa enää mitään”, eikä sivustolla sillä hetkellä muutu mikään, minkä voisi huomata.

Miksi toimiva sivusto on silti uhattuna

Versio, jonka elinkaari on päättynyt, ei muutu vaaralliseksi sinä päivänä, jona elinkaari päättyy, vaan sinä päivänä, jona julkistetaan haavoittuvuus, joka koskee sitäkin. Tuettuihin release brancheihin korjaus ilmestyy yhdessä kuvauksen kanssa, ja heti kun se on julkinen, hyökkääjät voivat verrata korjattua koodia korjaamattomaan ja nähdä, missä aukko on. Node.js sanoo tämän suoraan elinkaaren päättymistä käsittelevällä sivullaan: jos haavoittuvuus koskee myös release lineä, jonka elinkaari on päättynyt, sille ei ilmesty uutta julkaisua, ja ne, jotka jäävät sellaiselle release linelle, ovat heti suojattomia hyökkäyksiä vastaan, jotka käyttävät julkistettua haavoittuvuutta.

Lokakuussa 2026 juuri näin kävi molemmille alustoille lähes samaan aikaan. 21. lokakuuta PHP julkaisi hätäkorjaukset kahteen kriittiseen haavoittuvuuteen, jotka tunnetaan nimellä PHP2Shell, ja viralliset julkaisut saivat vain release branchit 8.2:sta 8.5:een, mutta release brancheille 7.4, 8.0 ja 8.1 tietoturvatiimi valmisteli poikkeuksellisesti vain pienimmät lähdekoodikorjaukset niille, jotka rakentavat PHP:n itse. Samana päivänä Node.js julkaisi korjaukset kymmeneen haavoittuvuuteen, eikä 18. eikä 20. release line saanut niitä itse projektilta lainkaan. Molemmat tapaukset olemme kuvanneet tarkemmin erikseen: PHP2Shell-artikkelissa ja Node.js:n tietoturvapäivitystä käsittelevässä artikkelissa.

Toinen riski näkyy vähemmän, mutta on pitkällä aikavälillä suurempi. Vanha runtime ei anna päivittää mitään siitä, mikä on sen päällä: WordPressin lisäosat, Composer- ja npm-paketit ja itse ohjelmistokehys lakkaavat uusissa julkaisuissaan vähitellen tukemasta vanhaa PHP:tä ja Node.js:ää, joten sivusto ei voi saada niidenkään korjauksia. WordPress itse suosittelee PHP 8.3:a tai uudempaa ja kirjoittaa vanhemmista release brancheista, että niiden elinkaari on virallisesti päättynyt ja että ne voivat tehdä sivustosta suojattoman. Näin vanha runtime ei enää ole yksi erillinen ongelma vaan kerros, joka estää ratkaisemasta kaikki muut.

Kun jotain tapahtuu, hinta on selvästi korkeampi kuin suunnitellussa päivityksessä. Murrettu sivusto merkitsee puhdistamista, palautusta varmuuskopiosta, salasanojen ja avainten vaihtamista ja, jos asiakkaiden henkilötietoja on koskettu, myös arviota siitä, pitääkö henkilötietojen tietoturvaloukkauksesta ilmoittaa valvontaviranomaiselle, ja kaikki tämä tapahtuu kiireessä, kun sivusto ei toimi tai näyttää kävijöille vierasta sisältöä. Siirto on tässä tilanteessa tehtävä joka tapauksessa, mutta nyt se on tehtävä murron jälkeen eikä ennen sitä, eikä kaikkea voi rauhassa tarkistaa testiympäristössä.

Miksi vanhaa PHP-versiota ei voi vain vaihtaa hallintapaneelissa

Hallintapaneelissa siirtyminen uudempaan PHP-versioon vie yhden napsautuksen, ja juuri siksi se on petollinen: jos koodi ei ole siihen valmis, sivusto lakkaa toimimasta seuraavassa sekunnissa, usein tyhjänä sivuna tai virheilmoituksena. Siirryttäessä seuraavaan pääversioon PHP poistaa tarkoituksella funktioita, jotka ovat olleet vanhentuneita vuosia. PHP 7.0 poisti vanhan mysql PHP extensionin, jolle monet vanhemmat sivustot rakentuivat, ja PHP 8.0 poisti yhteensopimattomien muutosten luettelossaan muun muassa funktiot each() ja create_function(), joita vanhemmassa koodissa yhä esiintyy.

Node.js:n maailmassa klassinen esimerkki on 17. release line, jossa runtime siirtyi OpenSSL 3.0:aan. Julkaisutiedotteessa Node.js varoitti, että sovellus, joka itse tai jonka moduulit käyttävät algoritmia tai avaimen pituutta, jonka OpenSSL 3.0 oletuksena kieltää, saa virheen ERR_OSSL_EVP_UNSUPPORTED, ja väliaikaiseksi ratkaisuksi se tarjosi käynnistysparametrin --openssl-legacy-provider. Virheen aiheutti usein jokin sen riippuvuuksista, ei projektin oma koodi, joten se oli korjattava koodissa, jota projektin oma tiimi ei ollut lainkaan kirjoittanut.

Siksi siirto on kehitystyötä, ei asetus. Koodi on tarkistettava uutta runtimea vasten, vanhentuneet funktiot on korvattava, riippuvuudet on päivitettävä julkaisuihin, jotka sitä tukevat, ja kaikki on kokeiltava testiympäristössä, ennen kuin asiakkaat sen näkevät. Pienelle sivustolle, joka on ylläpidetyllä alustalla, se voi olla muutaman tunnin työ, mutta järjestelmälle, jonka ohjelmistokehyksen elinkaari on päättynyt jo vuosia sitten, siirto merkitsee usein myös ohjelmistokehyksen vaihtamista, ja silloin se on jo projekti, jolla on oma budjetti ja aikataulu, eikä tehtävä, jonka voi hoitaa muiden töiden välissä.

Kolme polkua: päivitä, rakenna uudelleen tai pidä suojattuna

Polun määräävät kaksi asiaa: kuinka kauas koodi on jäänyt tuetusta versiosta ja kuinka kauan sivuston on vielä palveltava. Jos sivusto on joka tapauksessa tarkoitus korvata uudella vuoden kuluttua, suurta siirtoa vanhassa koodissa ei kannata tehdä, mutta jos se on yrityksen jokapäiväinen työkalu, jota käytetään vielä vähintään viisi vuotta, väliaikainen ratkaisu vain lykkää väistämätöntä ja tekee siitä kalliimman. Taulukossa on kolme polkua, jotka ovat oikeasti käytettävissä, ja se, minkä kukin niistä ratkaisee ja minkä ei.

Päivittäminen on oikea valinta, jos sivusto rakentuu ylläpidetylle alustalle, kuten WordPress tai Laravel, ja tuetusta release branchista sen erottaa yksi tai kaksi suurta askelta. Silloin työ on ennakoitavissa: ohjelmistokehys ja lisäosat päivitetään, tarkistustyökalujen löytämä korjataan ja PHP vaihdetaan. Uudelleenrakentaminen on rehellisin polku, jos ohjelmistokehys itse on ilman tukea, jos sivusto on kirjoitettu PHP 5.x:llä ilman minkäänlaista ohjelmistokehystä tai jos koodia ei enää kukaan ymmärrä, sillä silloin päivittämisen kustannukset lähestyvät nopeasti uuden sivuston kustannuksia, mutta tulos on yhä vanhaa koodia.

Kolmatta polkua käsitellään harvemmin. Vanhan sivuston voi pitää alustalla, joka yhä tekee sen runtimeen backportin tietoturvakorjauksista, eristää sen muista sivustoista ja estää tunnetut hyökkäysmallit jo ennen korjausta. Se ei korvaa siirtoa, ja Node.js itse kutsuu tällaista tukea väliaikaiseksi ratkaisuksi, mutta se on rehellinen tapa saada aikaa: siirron voi tehdä suunnitellussa tahdissa eikä viikon sisällä seuraavasta tietoturvatiedotteesta. Tärkein sana tässä on ”määräaika”, sillä ilman sitä väliaikaisesta ratkaisusta tulee pysyvä.

Mikä on backport ja miksi versionumero ei kerro siitä mitään

Backport tarkoittaa, että tietoturvakorjaus, joka on tehty uudempaan versioon, sovitetaan ja rakennetaan vanhempaan versioon, jota käyttäjä jo käyttää. Red Hat, joka ylläpitää Linux-jakelunsa paketteja näin, kirjoittaa, että pelkän versionumeron perusteella asiakas ei voi päätellä, onko hänen järjestelmänsä haavoittuva, koska korjaus muuttaa pakettia mutta ei versionumeroa. Juuri siksi haavoittuvuusskannerit, jotka katsovat vain numeroa, ilmoittavat tällaisissa järjestelmissä usein virheellisesti ongelmista, jotka on jo korjattu.

PHP:n ja Node.js:n tapauksessa näin tekee useampi toimittaja. Linux-jakelut tekevät backportin omiin PHP- ja Node.js-paketteihinsa koko jakelun tukiajan. CloudLinux tekee backportin omiin alt-php-paketteihinsa, joita CloudLinuxia käyttävät hosting-palvelimet käyttävät, myös niille release brancheille, joiden elinkaari on päättynyt jo kauan sitten: PHP2Shellin tapauksessa sen tilasivu ilmoitti 21. lokakuuta, että se valmistelee korjattuja paketteja kaikille alt-php:n release brancheille 5.2:sta 8.5:een, ja seuraavan yön aikana ne olivat saatavilla. Nämä paketit ovat nyt osa yrityksen TuxCaren laajennettua tukea, jonka ehdoissa korkean ja kriittisen vaaran haavoittuvuuksien tavoitteeksi mainitaan korjaus 14 päivän kuluessa haavoittuvuuden julkistamisesta.

Ilman tukea oleville Node.js:n release lineille saman palvelun tarjoavat kaupalliset kumppanit, jotka Node.js itse nimeää elinkaaren päättymisen sivullaan: HeroDevs, NodeSource ja TuxCare. Node.js lisää heti, että tällaista tukea on pidettävä väliaikaisena ratkaisuna ja että tavoitteena on aina oltava siirto tuettuun versioon. CloudLinux teki lokakuun 2026 Node.js-julkaisun yhteydessä backportin myös omiin 16., 18. ja 20. release linen paketteihinsa, jotka hosting-asiakkaat valitsevat cPanelin osiossa Setup Node.js App.

Sitä ei voi tarkistaa versionumerosta. Komento php -v tai node -v näyttää backportin jälkeen täsmälleen saman kuin ennen sitä, ja CloudLinux kirjoittaa tämän avoimesti Node.js-tiedotteessaan: ilman tukea olevilla release lineillä numero ei muutu päivityksen jälkeen. Paketin release number sen sijaan muuttuu, ja sen näkee vain palvelimen ylläpitäjä, joten webhotellissa vastauksen voi antaa vain hosting-palveluntarjoaja.

Raja on sanottava yhtä selvästi. Backport suojaa itse PHP:tä tai Node.js:ää, mutta ei suojaa WordPress-lisäosaa, jonka tekijä lakkasi päivittämästä sitä, itse kirjoitettua koodia, jossa on SQL-injektio, tai npm-pakettia, jonka uudemmat julkaisut eivät enää tue vanhaa Node.js:ää. Lisäksi toimittajat tekevät backportin kullekin release linelle erikseen, joten kustakin on tarkistettava, onko se ylipäätään luettelossa, ja TuxCare pidättää ehdoissaan oikeuden tarjota korjauksen sijaan riskiä pienentävän toimenpiteen.

Kun vanha ei ole runtime vaan itse alusta

Joskus ongelma ei ole runtimessa vaan itse alustassa, jolle sivusto on rakennettu, ja silloin PHP:hen tehty backport auttaa vain osittain. Paras esimerkki on Drupal 7: sen tietoturvatuki päättyi 5. tammikuuta 2025, eikä Drupal-projekti itse ole sen jälkeen julkaissut sille tietoturva- eikä yhteensopivuuspäivityksiä. Drupal 7 -sivusto voi toimia täysin korjatulla PHP:llä, mutta sen ydin, moduulit ja teema jäävät silti kaikkiin niihin haavoittuvuuksiin, jotka niistä vielä löydetään, koska maksutta niitä ei enää kukaan korjaa.

Tässäkin on tarjolla maksullinen väliaikainen ratkaisu: Drupal Association on luonut laajennetun tietoturvatuen ohjelman, jossa maksullista tukea tarjoavat tarkistetut toimittajat, esimerkiksi HeroDevs ja Tag1 Consulting. Se on sama periaate kuin PHP:hen tehty backport, vain kerrosta ylempänä, ja sillä on samat rajat: se lykkää siirtoa mutta ei ratkaise sitä, ja jokainen vuosi vanhalla alustalla tekee siirrosta kalliimman, koska etäisyys nykyiseen versioon kasvaa ja niiden kehittäjien määrä, jotka vanhan alustan vielä tuntevat, pienenee.

Siksi ennen minkään päätöksen tekemistä kannattaa tarkistaa kaikki kerrokset eikä vain PHP: runtime, alusta tai ohjelmistokehys, lisäosat tai moduulit ja itse kirjoitettu koodi. Jos vanhentunut on vain PHP, mutta WordPress, Laravel tai muu alusta on ylläpidetty, siirto on tavallisesti ennakoitavaa työtä. Jos vanha on itse alusta, kysymys ei enää koske PHP:n release branchia vaan sitä, siirretäänkö sivusto alustan uuteen versioon vai rakennetaanko se uudelleen, ja juuri tässä backportin tehtävä on antaa aikaa tehdä tämä päätös ilman kiirettä.

Miten pidämme vanhaa PHP:tä ja Node.js:ää omalla palvelimellamme

Hallittu hostingimme on paikka omalla palvelimellamme, joka toimii CloudLinuxilla, ja kullekin sivustolle PHP-versio valitaan erikseen hallintapaneelissa. Tällä hetkellä siinä on saatavilla PHP 5.4:stä 8.4:ään, ja Node.js-sovelluksille sekä tuetut 22. ja 24. release linet että vanhat 16., 18. ja 20. release linet. Se tarkoittaa, että vanhan sivuston voi siirtää meille sillä samalla PHP:llä tai Node.js:llä, jolla se toimii nyt, ja vakauttaa se ensin, sen sijaan että siirtopäivänä vaihdettaisiin samalla myös koodi, mikä on varmin tapa olla rikkomatta mitään siirron aikana.

Miten tämä toimii käytännössä, sen pystyimme lokakuussa 2026 mittaamaan itse. PHP2Shell-korjaukset ilmestyivät 21. lokakuuta iltapäivällä, ja palvelimellamme kaikki vanhat PHP:n release branchit 5.4:stä 8.1:een toimivat nyt paketeilla, jotka CloudLinux rakensi uudelleen saman päivän yönä, alle vuorokausi PHP-julkaisun jälkeen, ja joihin korjaus on tehty backportina. Release branchit 8.2:sta 8.4:ään siirtyivät virallisiin korjattuihin julkaisuihin 8.2.35, 8.3.36 ja 8.4.27, ja Node.js:n 16., 18. ja 20. release line sai 22. lokakuuta CloudLinux-paketit, joihin on tehty backport, vaikka Node.js-projekti itse ei niille korjauksia julkaissut. Vanhoilla release brancheilla numero ei muuttunut, joten emme tarkistaneet sitä numerosta vaan siitä, milloin suoritettavat tiedostot oli rakennettu uudelleen.

Tämä ei ole kaikki, mitä alusta tekee. CloudLinux sijoittaa kunkin hosting-tilin erilliseen eristettyyn ympäristöön, jonka nimi on CageFS, ja siinä käyttäjät eivät näe muita palvelimen käyttäjiä eivätkä edes heidän käyttäjätunnuksiaan, mikä vaikeuttaa murron leviämistä tililtä toisille. Imunify360:n verkkosovelluspalomuuri (WAF) alkoi PHP2Shellin tapauksessa estää tunnettuja hyökkäysmalleja 21. lokakuuta, useita tunteja ennen korjatun PHP:n julkaisua. Mikään näistä kerroksista ei tee vanhasta sivustosta haavoittumatonta, mutta yhdessä ne kaventavat ajan, jona tunnettu haavoittuvuus on hyödynnettävissä, ja rajoittavat, kuinka laajalle murron seuraukset voivat ulottua.

Siksi vanhan sivuston siirtoa meille suosittelemme pitämään väliaikaisena ratkaisuna, jolla on määräaika, ei päämääränä. Siirrämme sivuston samalla runtimella, tarkistamme, että kaikki toimii kuten ennen, ja sovimme sen jälkeen kanssasi, mihin päivään mennessä ja missä järjestyksessä se siirtyy tuettuun versioon, jotta väliaikaisesta ratkaisusta ei tule pysyvää. Hallittu hostingimme alkaa 45 €:sta kuukaudessa, ja ylläpidetyt runtimet, account isolation ja palomuuri ovat osa sitä, mistä tässä summassa maksetaan. Jos sinulla on sivusto, jolla on vanha PHP- tai Node.js-versio, lähetä meille sen osoite, niin kerromme, mikä kolmesta polusta sille sopii ja mistä aloittaa.

Miten selvität, mikä PHP- tai Node.js-versio verkkosivustollasi on

Nopein reitti on hallintapaneeli. CloudLinuxia käyttävässä cPanel-webhotellissa osio Select PHP Version näyttää version, joka on valittu koko tilille, ja MultiPHP Manager näyttää version kullekin verkkotunnukselle erikseen, ja jos verkkotunnukselle on siellä merkitty oma versio, se ratkaisee. Node.js-sovelluksille saman näyttää osio Setup Node.js App, jossa kullakin sovelluksella on oma rivinsä. Katsoa kannattaa jokaista sivustoa eikä vain pääsivustoa, koska samalla tilillä on usein useita sivustoja eri PHP:n release brancheilla, ja unohdettu testikopio tai vanha kampanjasivu on yhä usein tavoitettavissa internetistä.

WordPress-sivustolla sen näkee myös hallintapaneelissa: kohdassa Työkalut → Sivuston eheys (Tools → Site Health), välilehdellä Tiedot (Info), lohkossa Palvelin (Server) on ilmoitettu PHP-versio, jolla sivusto toimii. Jos paneelia ei ole, voi luoda tiedoston, jossa on funktio phpinfo(), ja avata sen selaimessa, mutta sen jälkeen tiedosto on ehdottomasti poistettava, koska se näyttää jokaiselle kävijälle palvelimen asetukset. Komento php -v auttaa tässä vähemmän kuin näyttää, koska se näyttää komentorivin PHP:n, mutta verkkopyyntöjä palvelee usein toinen release branch, joka on valittu hallintapaneelissa. Node.js-projektissa haluttu release line ilmoitetaan usein package.json-tiedoston kentässä engines tai tiedostossa .nvmrc, mutta se on vain toive, ja sitä, mikä Node.js sovellusta todella ajaa, on katsottava siellä, missä prosessi käynnistetään.

Jos pääsyä ei ole lainkaan, kysymys on esitettävä hosting-palveluntarjoajalle tai kehittäjälle, joka sivustoa ylläpitää. Muotoilu, joka säästää kirjeenvaihtoa: ”Mikä PHP- tai Node.js-versio palvelee sivustoamme? Jos sen elinkaari on päättynyt, saako se tietoturvakorjauksia, joihin on tehty backport, mistä ne tulevat ja milloin paketti on viimeksi päivitetty? Mihin päivään mennessä suosittelette siirtymistä?” Vastaus viimeiseen kysymykseen kertoo paljon myös itse tarjoajasta, sillä jos päivämäärää ei ole, ei tavallisesti ole suunnitelmaakaan.

Siirtymä tuettuun versioon: miten se tehdään ilman yllätyksiä

Siirto alkaa inventoinnista, ei version vaihtamisesta. Kirjataan, mikä PHP:n release branch ja mitkä PHP extensionit sivusto tarvitsee, mitkä ajastetut tehtävät pyörittävät sitä taustalla, minkä ulkoisten järjestelmien kanssa se viestii ja mitkä sen osat ovat liiketoiminnalle kriittisiä, esimerkiksi tilauslomake, maksut tai laskujen lähettäminen. Tavoiteversio kannattaa valita niin, että tukiaikaa jää reilusti: PHP 8.4 saa tietoturvakorjauksia 31. joulukuuta 2028 asti, PHP 8.3 vuoden 2027 loppuun, mutta siirto PHP 8.2:een, jonka elinkaari päättyy jo vuoden 2026 lopussa, merkitsisi vielä yhtä siirtoa aivan pian. Node.js:n tapauksessa tavoite on useimmiten 24. release line.

Toinen askel on koodin tarkistus, ja PHP-koodille sen voi suurelta osin automatisoida. PHPCompatibility on PHP_CodeSnifferin sääntöjoukko, joka tarkistaa, onko koodi yhteensopiva tietyn PHP-version kanssa, ja Rector voi tehdä osan tarvittavista muutoksista automaattisesti. Kumpikaan ei korvaa ihmisen tarkistusta, mutta ne näyttävät nopeasti, mitataanko työ tunneissa vai viikoissa, ja juuri sitä tarvitaan, jotta voi päättää päivittämisen ja uudelleenrakentamisen välillä. WordPress-sivustolla on ensin päivitettävä lisäosat ja teema, ja vasta sen jälkeen vaihdettava PHP.

Kolmas askel on testiympäristö, eli sivuston kopio uudella PHP:llä tai Node.js:llä, jossa kokeillaan kaikki kriittiset toiminnot: lomakkeet, maksut, sähköpostin lähettäminen, tuonti ja vienti. Virheloki on tässä vaiheessa tärkeämpi kuin silmämääräinen tarkistus, koska varoitukset vanhentuneista funktioista ilmestyvät sinne kauan ennen kuin jokin pysähtyy. Neljäs askel on version vaihtaminen pienen kuorman aikana ja mahdollisuus palata takaisin: hostingissa, jossa version voi valita, paluu on sama yksi napsautus, jolla vaihto tehtiin, joten riski on pieni, kunhan varmuuskopio on tuore ja joku seuraa virhelokia ensimmäisen viikon.

Node.js-sovelluksessa logiikka on sama, vain työkalut ovat toiset. Siirto suurten release linejen välillä kannattaa tehdä yksi kerrallaan, ja jokaisen jälkeen ajetaan sovelluksen testit, ja erityistä huomiota on kiinnitettävä paketteihin, joissa on käännettyä koodia, koska ne rakennetaan tietylle Node.js:n release linelle ja ne on siirron jälkeen rakennettava uudelleen. Ensin on päivitettävä riippuvuudet, jotka eivät vielä tue uutta release lineä, ja vasta sen jälkeen vaihdettava itse runtime, sillä muuten virheet molemmilta puolilta sekoittuvat ja on vaikea ymmärtää, mikä niistä minkäkin aiheutti.