Palvelimen siirto (migraatio) askel askeleelta – Näin siirrät verkkosivuston ilman tietojen menetystä

Palvelimen siirto eli migraatio tarkoittaa verkkosivuston tiedostojen, tietokannan, sähköpostitilien, DNS-tietueiden ja sovellusasetusten suunnitelmallista siirtämistä nykyiseltä palvelimelta uudelle palvelimelle. Perusperiaate sivuston siirtämiseksi ilman tietojen menetystä on seuraava: ensin otetaan täydellinen varmuuskopio, uusi palvelin varustetaan samoilla tai uudemmilla ohjelmistoversioilla, tiedostot ja tietokanta siirretään, hosts-tiedoston tai väliaikaisen URL-osoitteen avulla testataan, DNS-ohjaus vaihdetaan matalalla TTL-arvolla ja siirron jälkeen seurataan lokitietoja, lomakkeita, maksuprosesseja, sähköpostin toimitusta ja SEO-signaaleja.

Palvelimen siirto ei ole yksinkertainen kopioi-liitä -prosessi. Erityisesti WordPressin, WooCommercen, Laravelin, räätälöityjen PHP-sovellusten, runsaasti liikennettä saavien uutissivustojen tai yrityssähköpostia käyttävien yritysten kohdalla virheellinen siirto voi johtaa tilausten menetykseen, skandinaavisten erikoismerkkien (å, ä, ö) rikkoutumiseen, 500-virheisiin, SSL-varoituksiin, sähköpostikatkoksiin ja hakukonenäkyvyyden laskuun. Siksi migraatio on toteutettava suunnitelman, teknisen tarkistuslistan ja palautussuunnitelman avulla.

Tässä oppaassa käymme läpi hosting-palvelun tai palvelimen vaihdon vaihe vaiheelta vuoden 2026 SEO- ja suorituskykyvaatimusten mukaisesti. Käsittelemme erilaisia skenaarioita, kuten cPanelia, Pleskiä, VPS:ää, pilvipalvelinta ja manuaalista siirtoa, sekä jaamme käytännönläheisiä suosituksia DNS-viiveeseen, varmuuskopioinnin laajuuteen, tietokantayhteensopivuuteen, SSL-asennukseen ja siirron jälkeisiin SEO-tarkistuksiin.

Milloin palvelimen siirto on tarpeellinen?

Verkkosivuston siirtäminen uudelle palvelimelle johtuu yleensä suorituskyvyn, tietoturvan, kustannusten tai skaalautuvuuden tarpeesta. Esimerkiksi 5 000 kuukausittaista kävijää palveleva yrityssivusto voi toimia ongelmitta jaetulla hostingilla, kun taas 20 000 päivittäistä kävijää keräävä verkkokauppa voi kohdata suorittimen rajoituksia, hitaita kyselyitä ja maksusivun aikakatkaisuongelmia. Tällöin valitaan tehokkaampi hosting-paketti, VPS tai pilvi-infrastruktuuri.

Yleisiä merkkejä palvelimen siirtotarpeesta ovat:

• Sivun latausaika ylittää 3 sekuntia ja Core Web Vitals -mittarit heikkenevät.
• Hosting-paneelin suorittimen, muistin, inode- tai levytilan käyttörajat täyttyvät usein.
• Tarve päivittää PHP, MySQL, MariaDB, Node.js tai ionCube uudempaan versioon.
• Toistuvat ongelmat SSL-uusinnassa, sähköpostin toimituksessa tai DNS-hallinnassa.
• Nykyisen palveluntarjoajan tuen laatu, varmuuskopiointi tai tietoturvan taso on riittämätön.
• Sivuston liikenne kasvaa äkillisesti kampanjoiden, mainonnan tai sesongin aikana.

Jos sivustosi kasvaa ja lähestyy nykyisen paketin rajoja, on paljon turvallisempaa laatia hallittu migraatiosuunnitelma kuin tehdä siirto kriisin hetkellä. Voit valita oikean infrastruktuurin vertailemalla tarpeisiisi sopivia web hosting -paketit, VPS-palvelinratkaisut tai yrityshosting -vaihtoehtoja.

Siirtoa edeltävä valmistelu: Kriittisin vaihe

Suurin osa epäonnistuneista migraatioprojekteista, joissa tietoja menetetään, ei johdu itse siirtovaiheesta vaan puutteellisesta valmistelusta. Ennen siirron aloittamista on kartoitettava nykyisen sivuston kokoonpano ja selvitettävä, mitkä tiedot siirretään ja mitkä palvelut ovat herkkiä katkoksille.

1. Kartoita sivuston kokoonpano

Ensimmäinen askel on luoda verkkosivuston tekninen kartta. Muistiin on merkittävä käytössä oleva CMS tai sovelluskehys, PHP-versio, tietokantatyyppi, levytilan koko, sähköpostitilit, cron-työt, DNS-tietueet, SSL-sertifikaatti, erityiset uudelleenohjaukset ja kolmannen osapuolen integraatiot. Esimerkiksi WordPress-sivustossa pelkän wp-content-kansion siirtäminen ei riitä; on tarkistettava myös .htaccess-säännöt, wp-config.php-asetukset, tietokannan taulujen etuliitteet, välimuistilisäosat ja mediatiedostot.

Verkkokaupassa on lisäksi tutkittava maksuinfrastruktuuri, toimitusintegrointi, varastosynkronointi, ERP-yhteys, SMTP-palvelu ja webhook-URL-osoitteet. Jos tilauksia ei tule siirron jälkeen, ongelma ei yleensä ole tiedostojen siirrossa vaan unohtuneessa API-IP-rajoituksessa tai vanhalle palvelimelle määritellyssä tietoturvasäännössä.

2. Ota täydellinen varmuuskopio ja varmista sen eheys

Palvelimen siirrossa pelkkä varmuuskopion ottaminen ei riitä; on myös varmistettava, että varmuuskopio on palautettavissa. Täydellisen varmuuskopion tulee kattaa seuraavat osat:

• Verkkosivuston tiedostot: public_html, sovelluskansiot, upload-hakemistot, teema- ja lisäosatiedostot.
• Tietokannat: MySQL, MariaDB, PostgreSQL tai muut sovelluksen käyttämät tietokannat.
• Sähköpostidata: postilaatikot, edelleenohjaukset, suodattimet, autoresponder-asetukset.
• DNS-tietueet: A, AAAA, CNAME, MX, TXT, SPF, DKIM, DMARC -tietueet.
• Konfiguraatiot: .htaccess, nginx.conf, php.ini, cron-työt, ympäristötiedostot.
• SSL-sertifikaatit ja erityiset tietoturvasäännöt.

Käytännönläheisenä lähestymistapana ota ennen siirtoa vähintään kaksi kopiota varmuuskopiosta: yksi säilytetään nykyisellä palvelimella, toinen eri sijainnissa. Suurilla sivustoilla tiedostojen varmuuskopiointiin voidaan käyttää rsynciä, tietokantaan mysqldumpia tai paneelin varmuuskopiointityökaluja. Yli 10 gigatavun tietokannoissa pakatut ja ositetut varmuuskopiot voivat olla turvallisempia kuin yksi suuri dump-tiedosto.

3. Pienennä DNS:n TTL-arvo etukäteen

Jotta DNS-muutos leviää nopeasti, on hyvä käytäntö pienentää TTL-arvoa 24 tuntia ennen siirtoa. Jos TTL-arvo on esimerkiksi 14 400 sekuntia, osa käyttäjistä voi ohjautua vanhalle palvelimelle vielä tuntien ajan. TTL-arvon laskeminen 300 sekuntiin ennen siirtoa tekee DNS-siirtymästä hallitumman. Kun siirto on valmis ja kaikki on varmistettu, TTL voidaan nostaa takaisin 3 600 tai 14 400 sekuntiin.

Verkkotunnuksen DNS-hallinnan säännöllinen ylläpito vaikuttaa suoraan migraation onnistumiseen. Verkkotunnuksen ja DNS-asetusten hallintaan voit tutustua verkkotunnuksen haku ja hallinta -oppaiden avulla.

Palvelimen siirtomenetelmien vertailu

Oikea siirtomenetelmä ei ole sama kaikille sivustoille. Pieni yrityssivusto voidaan siirtää helposti paneelin kautta, kun taas vilkkaasti liikennöity verkkokauppa saattaa vaatia vaiheittaista synkronointia ja huoltotilaa.

Uutta infrastruktuuria valitessa pelkkä levytilan tuijottaminen on harhaanjohtavaa. PHP-workerien määrä, suoritinydinten määrä, keskusmuisti, NVMe-levy, varmuuskopioinnin tiheys, palvelinkeskuksen sijainti, LiteSpeed- tai Nginx-tuki, WAF ja DDoS-suojaus määrittävät suorituskyvyn. Siksi halvimpaan pakettiin vaihtaminen ilman tarveanalyysiä voi johtaa uuteen siirtotarpeeseen jo lyhyen ajan sisällä.

Palvelimen siirto askel askeleelta

Vaihe 1: Valmistele uusi palvelin

Uudelle palvelimelle on asennettava käyttöjärjestelmä, web-palvelin, PHP-versio, tietokantapalvelu ja tarvittavat moduulit. WordPressille suositellaan PHP 8.2:ta tai 8.3:a, ajantasaista MariaDB:tä, OPcachea ja sopivaa memory_limit-arvoa. Laravelin kaltaisissa sovelluskehyksissä on lisäksi määritettävä Composer, cron, queue worker ja storage-oikeudet. Jos vanhalla palvelimella toimineita PHP-laajennuksia ei ole uudella palvelimella, sivusto voi siirron jälkeen näyttää valkoista ruutua tai 500-virheen.

Tietoturvan osalta on määritettävä SSH-porttikäytäntö, vahvat salasanat, palomuuri, haittaohjelmaskannaus ja automaattiset päivitykset. Tietoturvaperustan rakentaminen ennen siirtoa, kun uusi palvelin on vielä tyhjä, on helpompaa kuin jälkikäteen puuttuminen. Jos tarvitset SSL:ää, muista lisätä SSL-sertifikaatin asennus siirtosuunnitelmaasi.

Vaihe 2: Siirrä tiedostot

Tiedostojen siirtoon voidaan käyttää sivuston koosta riippuen FTP:tä, SFTP:tä, SSH:ta, rsynciä tai paneelin varmuuskopiointia. Pienillä sivustoilla pakatun arkiston luominen ja purkaminen uudella palvelimella riittää. Suurilla sivustoilla suositellaan ensimmäisen kopion ottamista rsyncillä ja toisen synkronoinnin tekemistä juuri ennen DNS-muutosta. Tämä menetelmä säästää aikaa erityisesti sivustoilla, joiden upload-kansio muuttuu jatkuvasti.

Tiedostojen siirron jälkeen tarkista oikeudet. Yleisesti kansiot toimivat 755-oikeuksilla ja tiedostot 644-oikeuksilla, mutta jokaisen sovelluksen tarpeet voivat vaihdella. wp-config.php:n, .env:n tai vastaavien arkaluontoisten tiedostojen ei tule olla kaikkien luettavissa. Varmista myös, että piilotetut tiedostot, kuten .htaccess ja .user.ini, ovat kopioituneet mukaan.

Vaihe 3: Siirrä tietokanta

Tietokannan siirto on arkaluonteisin osa tietojen menetyksen estämisessä. Ensin otetaan dump vanhalta palvelimelta, sitten luodaan tietokanta ja käyttäjä uudelle palvelimelle. Merkistöksi kannattaa asettaa utf8mb4, jos mahdollista. Jotta skandinaaviset erikoismerkit (å, ä, ö) eivät rikkoudu, on viennin ja tuonnin aikana säilytettävä sama kollaatiorakenne.

Sivustoilla, jotka tuottavat reaaliaikaista dataa, kuten WooCommerce tai jäsenjärjestelmät, voidaan siirron aikana käyttää huoltotilaa. Muuten DNS:n leviämisen aikana osa käyttäjistä saattaa kirjoittaa dataa vanhalle palvelimelle ja osa uudelle. Tämä aiheuttaa epäjohdonmukaisuuksia tilauksiin, kommentteihin, lomaketietoihin tai jäsenyyksiin. Kriittisillä sivustoilla viimeinen tietokannan dump-tiedosto tulee ottaa vasta huoltotilan avaamisen jälkeen.

Vaihe 4: Päivitä konfigurointitiedostot

Tietokannan nimi, käyttäjätunnus, salasana, palvelimen osoite ja tiedostopolut on muokattava uuden palvelimen mukaisiksi. WordPressissä tarkistetaan wp-config.php, Laravelissa .env, räätälöidyissä sovelluksissa config.php tai vastaavat tiedostot. Jos vanhan palvelimen absoluuttisia tiedostopolkuja, IP-osoitteita, SMTP-asetuksia tai välimuistihakemistoja jää jäljelle, sivusto saattaa näyttää toimivan, mutta tuottaa virheitä taustalla.

Lisäksi PHP:n memory_limit, upload_max_filesize, post_max_size ja max_execution_time -arvot on säädettävä sovelluksesi tarpeiden mukaan. Jos esimerkiksi hallintapaneeliin ladataan 200 megatavun tuotekuvia, mutta upload-raja on jätetty 32 megatavuun, operointi ei voi jatkua, vaikka siirto olisi onnistunut.

Vaihe 5: Testaa ennen DNS-muutosta

Turvallisin siirtokäytäntö on testata sivusto uudella palvelimella ennen DNS-muutosta. Voit tehdä tämän yhdistämällä tietokoneesi hosts-tiedostossa verkkotunnuksesi uuden palvelimen IP-osoitteeseen. Näin kävijät näkevät edelleen vanhan palvelimen, kun sinä testaat uutta palvelinta oikealla verkkotunnuksella.

Testilistan tulee sisältää seuraavat tarkistukset:

• Avautuvatko etusivu, kategoriat, tuotteet, blogi ja yhteystiedot?
• Toimivatko lomakkeen lähetys, jäsenkirjautuminen, salasanan nollaus ja maksuprosessi?
• Latautuvatko kuvat, CSS- ja JavaScript-tiedostot täydellisesti?
• Avautuuko hallintapaneeli virheittä?
• Onko SSL-sertifikaatti asennettu oikealle verkkotunnukselle?
• Esiintyykö 404-, 500-virheitä, sekasisältöä (mixed content) tai uudelleenohjaussilmukoita?
• Ovatko robots.txt, sitemap.xml ja canonical-tagit oikein?

Vaihe 6: Asenna SSL-sertifikaatti

Nykyaikaisilla verkkosivustoilla SSL ei ole vain tietoturvaa, vaan myös SEO:ta ja käyttäjien luottamusta koskeva vaatimus. Jos DNS vaihdetaan ennen SSL:n asentamista uudelle palvelimelle, käyttäjät voivat nähdä "ei turvallinen" -varoituksen. Siksi SSL-sertifikaatti on valmisteltava juuri ennen DNS-siirtymää tai sen kanssa samanaikaisesti. Ilmaiset sertifikaatit, kuten Let’s Encrypt, voivat riittää monille sivustoille; maksuja käsittelevissä yritysprojekteissa voidaan suosia korkeamman vahvistustason SSL-vaihtoehtoja.

SSL:n jälkeen varmista, että HTTP-osoitteet ohjataan 301-uudelleenohjauksella HTTPS:ään, ettei sekasisältövirheitä (mixed content) esiinny ja että sivustokartta sisältää HTTPS-URL-osoitteet. SSL-tuotteisiin ja asennusvaihtoehtoihin voit tutustua SSL-sertifikaatit -sivulla.

Vaihe 7: Vaihda DNS-tietueet

Kun testit on suoritettu onnistuneesti, DNS-puolella A-tietue ohjataan uuden palvelimen IP-osoitteeseen. Jos sähköpostipalvelu siirretään samalle palvelimelle, myös MX-, SPF-, DKIM- ja DMARC-tietueet on päivitettävä. Jos sähköposti jää eri palveluntarjoajalle, MX-tietueisiin ei tule koskea. Yksi yleisimmistä virheistä on muuttaa vahingossa sähköpostitietueita, kun tarkoituksena on siirtää vain verkkosivusto, ja katkaista näin sähköpostiliikenne.

DNS:n leviäminen kestää yleensä muutamasta minuutista 24 tuntiin. Jos TTL-arvoa on pienennetty etukäteen, useimmat käyttäjät ohjautuvat uudelle palvelimelle nopeasti. Älä sulje vanhaa palvelinta heti tämän prosessin aikana. On turvallista pitää se tavoitettavissa vähintään 48 tuntia, mieluiten 72 tuntia.

Vaihe 8: Suorita viimeinen synkronointi ja lokitarkistus

DNS-muutoksen jälkeen on tarkistettava, onko vanhalle palvelimelle kirjoitettu uutta dataa. Erityisesti tilauksia, yhteydenottolomakkeita, käyttäjärekisteröintejä ja kommentteja on verrattava. Web-palvelimen access.log- ja error.log-tiedostot auttavat ymmärtämään, mitkä IP-osoitteet lähettävät pyyntöjä millekin palvelimelle.

Ensimmäisten 24 tunnin aikana siirron jälkeen on seurattava 500-virheitä, 404-virheiden kasvua, hitaita kyselyitä, suorittimen piikkejä ja sähköpostijonoja. Jos näitä tarkistuksia ei tehdä, sivusto saattaa näyttää toimivan, mutta konversioita voidaan menettää taustalla.

Ammattilaisen tarkistuslista sivuston siirtämiseksi ilman tietojen menetystä

Seuraava tarkistuslista kattaa käytännössä eniten ongelmia aiheuttavat kohdat. Listan läpikäyminen ennen siirtoa ja sen jälkeen vähentää migraatioriskiä merkittävästi.

• Siirto on aikataulutettu vähäisen liikenteen ajankohtaan.
• Täydellinen varmuuskopio tiedostoista, tietokannasta, sähköpostista ja DNS:stä on otettu.
• Varmuuskopion avattavuus ja palautettavuus on testattu.
• DNS:n TTL-arvoa on pienennetty vähintään 24 tuntia etukäteen.
• Uudelle palvelimelle on valmisteltu PHP, tietokanta ja tarvittavat moduulit.
• Tiedostot on siirretty täydellisesti ja oikeudet tarkistettu.
• Tietokannan merkistön ja kollaation yhteensopivuus on varmistettu.
• Config-tiedostot on päivitetty uuden palvelimen tietojen mukaisiksi.
• Testaus on tehty hosts-tiedoston avulla ennen tuotantoon siirtoa.
• SSL on asennettu ja HTTPS-uudelleenohjaukset tarkistettu.
• DNS:n A-, AAAA-, MX- ja TXT-tietueet on päivitetty oikein.
• Vanha palvelin on pidetty aktiivisena vähintään 48 tuntia.
• Google Search Consolea, Analyticsia ja lokitietoja on seurattu.

Siirron jälkeiset tarkistukset SEO-menetyksen välttämiseksi

Palvelimen siirron ei teoriassa pitäisi aiheuttaa SEO-menetyksiä, kunhan URL-rakenne ei muutu. Käytännössä kuitenkin hitaus, 404-virheet, väärä robots.txt, puuttuva SSL tai uudelleenohjausvirheet voivat vaikuttaa sijoituksiin. Siksi siirron jälkeinen SEO-tarkistus on yhtä tärkeä kuin tekninen migraatio.

URL-osoitteiden ja uudelleenohjausten tarkistus

Jos et muuta URL-rakennetta sivustoa siirtäessäsi, 301-uudelleenohjausten tarve on minimaalinen. Jos kuitenkin samanaikaisesti vaihtuu verkkotunnus, permalinkkirakenne tai kansiorakenne, vanhat URL-osoitteet on ohjattava 301-uudelleenohjauksella uusiin vastineisiinsa. Väliaikainen 302-uudelleenohjaus ei sovellu SEO-signaalien pysyvään siirtämiseen. Jos esimerkiksi vanha /tuote/abc-sivu on siirretty uuteen /kauppa/abc-osoitteeseen, on tehtävä täsmällinen uudelleenohjaus; kaikkien vanhojen URL-osoitteiden ohjaaminen etusivulle heikentää käyttökokemusta ja SEO-suorituskykyä.

Robots.txt- ja sivustokartan tarkistus

Jos testauksen aikana käytettiin robots.txt:ssä Disallow-määritystä hakukoneiden estämiseksi, se on poistettava tuotantoon siirryttäessä. Tämä virhe on yksi klassisimmista syistä indeksoinnin menetykseen siirron jälkeen. Sivustokartan on sisällettävä uudet HTTPS-URL-osoitteet, ja se on lähetettävä uudelleen Google Search Consolen kautta.

Suorituskyky ja Core Web Vitals

Vaikka uusi palvelin olisi tehokkaampi, väärä välimuistiasetus voi heikentää suorituskykyä. LiteSpeed Cache, Redis, OPcache, CDN ja kuvien optimointi on määritettävä oikein. Ensimmäisen viikon aikana siirron jälkeen on seurattava PageSpeed Insightsia, Chrome UX Reportia ja palvelimen lokeja ja tarkistettava, ovatko LCP-, INP- ja CLS-mittarit heikentyneet. Voit hyödyntää WordPressin nopeusoptimointi -sisältöjä hosting-suorituskyvyn parantamiseksi.

Sähköpostin siirrossa huomioitavaa

Monissa sivuston siirroissa verkkotiedostot siirtyvät ongelmitta, mutta sähköpostipuoli unohtuu. Jos sähköposteja säilytetään nykyisellä palvelimella, postilaatikot, käyttäjien salasanat, edelleenohjaukset ja suodattimet on siirrettävä. IMAP-synkronointi on luotettava menetelmä vanhan laatikon sähköpostien siirtämiseksi uuteen laatikkoon.

DNS-puolella MX-tietue määrittää sähköpostipalvelimen, SPF lähetysoikeuden, DKIM allekirjoittamisen ja DMARC verkkotunnuksen politiikan. Jos nämä tietueet määritetään väärin, sähköpostit voivat päätyä roskapostikansioon tai ne voidaan hylätä kokonaan. Siirron jälkeen on tehtävä testilähetyksiä Gmailiin, Outlookiin ja yrityssähköpostitileille ja tarkistettava sähköpostien otsikkotiedot.

Yleisimmät palvelimen siirtovirheet

Onnistuneiden migraatioprojektien yhteinen piirre on yksinkertaisten virheiden ennaltaehkäisy. Seuraavat virheet ovat yleisimpiä ongelmia:

• Siirron tekeminen ilman varmuuskopiota tai varmuuskopion testaamista.
• IP-osoitteen vaihtaminen pienentämättä DNS:n TTL-arvoa.
• Vanhan palvelimen sulkeminen ennen DNS:n leviämisen päättymistä.
• Tietokannan merkistön virheellinen siirto ja skandinaavisten merkkien rikkoutuminen.
• .htaccess- tai nginx-uudelleenohjaussääntöjen unohtaminen.
• HTTPS-liikenteen ohjaaminen uudelle palvelimelle ilman SSL:n asentamista.
• Sähköpostin MX- ja TXT-tietueiden virheellinen päivittäminen.
• Välimuistilisäosan jättäminen vanhan palvelimen polkuihin.
• Search Consolen ja lokien seurannan laiminlyönti siirron jälkeen.

Erityisesti reaaliaikaisilla myyntisivustoilla siirtoa ei tule tehdä arkipäivän ruuhka-aikaan, vaan ajankohtana, jolloin liikenne ja tilausmäärät ovat alhaisimmillaan. Suurissa verkkokauppaprojekteissa 15–30 minuutin huoltoikkunan suunnittelu estää taustalla mahdollisesti syntyvät tietojen epäjohdonmukaisuudet.

Milloin kannattaa hankkia ammattimaista migraatiotukea?

Yksinkertaisen esittelysivuston manuaalinen siirtäminen voi olla mahdollista, mutta joissakin tapauksissa ammattiavun hankkiminen on edullisempaa ja turvallisempaa. Tähän ryhmään kuuluvat kuukausittain suurta liikevaihtoa tuottavat verkkokaupat, yritykset, joilla on paljon sähköpostitilejä, räätälöityjä ohjelmistoja käyttävät portaalit, vilkkaasti liikennöidyt mediasivustot ja säänneltyä dataa säilyttävät yritykset.

Ammattimaisessa siirtotuessa prosessi koostuu yleensä ennakkoanalyysistä, varmuuskopioinnista, testiympäristön pystytyksestä, siirrosta, DNS-siirtymästä, validoinnista ja seurannasta. Näin ei siirretä vain tiedostoja, vaan myös liiketoiminnan jatkuvuus. Jos suunnittelet siirtymistä Hostragonsin infrastruktuuriin, voit tutustua Hostragonsin hosting-ratkaisut -sivuun arvioidaksesi yhdessä tarpeisiisi sopivat hosting-, domain- ja SSL-vaihtoehdot.

Yhteenveto: Suunnitelmallinen palvelimen siirto estää katkokset ja tietojen menetyksen

Palvelimen siirto ei ole pelottava toimenpide, kun se suunnitellaan oikein. Onnistumisen avain on siinä, ettei ohiteta täydellistä varmuuskopiota, oikeaa palvelinvalmistelua, DNS:n TTL-suunnitelmaa, testiympäristöä, SSL-asennusta, sähköpostitarkistuksia ja siirron jälkeistä seurantaa. Erityisesti sivustoilla, joiden tietokanta muuttuu jatkuvasti, viimeinen synkronointi ja huoltotila ovat kriittisessä roolissa.

Lyhyesti sanottuna, jotta voit siirtää sivuston ilman tietojen menetystä, älä kiirehdi, varmista jokainen vaihe ja älä sulje vanhaa palvelinta heti. Jos haluat uudistaa infrastruktuurisi ja tarjota nopeamman ja turvallisemman verkkokokemuksen, voit tutustua Hostragonsin hosting-, domain- ja SSL-ratkaisuihin ja laatia tarpeisiisi sopivan siirtymäsuunnitelman rauhallisesti ja hallitusti.

Usein kysytyt kysymykset

Kuinka kauan palvelimen siirto kestää?

Kesto vaihtelee sivuston koon ja monimutkaisuuden mukaan. Pieni WordPress-sivusto voidaan siirtää 30–60 minuutissa, kun taas suurissa verkkokaupoissa tai yritysprojekteissa, joissa on paljon sähköposteja, prosessi valmisteluineen, testauksineen ja DNS:n leviämisineen voi kestää 1–3 päivää.

Sulkeutuuko sivustoni palvelimen siirron aikana?

Oikealla suunnittelulla katkos voidaan minimoida muutamaan minuuttiin tai käyttäjät eivät välttämättä huomaa katkosta lainkaan. Tätä varten DNS:n TTL-arvo on pienennettävä etukäteen, uusi palvelin on testattava ennen tuotantoon siirtoa ja vanha palvelin on pidettävä päällä, kunnes DNS:n leviäminen on valmis.

Mikä on tärkein askel tietojen menetyksen estämiseksi?

Tärkein askel on varmennettu täydellinen varmuuskopio. Tiedostot, tietokanta, sähköposti ja DNS-tietueet on varmuuskopioitava; erityisesti tilaus- tai jäsendataa tuottavilla sivustoilla viimeinen tietokannan varmuuskopio on otettava vasta huoltotilan avaamisen jälkeen.

Vaikuttaako palvelimen siirto SEO-sijoituksiin?

Jos URL-rakenne säilytetään, sivusto toimii nopeasti ja SSL sekä uudelleenohjaukset on tehty oikein, pelkkä palvelimen siirto ei aiheuta SEO-menetyksiä. Sen sijaan 404-virheet, väärä robots.txt, hidas palvelin tai virheelliset 301-uudelleenohjaukset voivat vaikuttaa sijoituksiin negatiivisesti.

Siirtyvätkö sähköpostitilitkin palvelimen siirrossa?

Jos sähköposteja säilytetään vanhalla hostingilla, ne on siirrettävä erikseen. Postilaatikot, edelleenohjaukset, suodattimet ja MX-, SPF-, DKIM- ja DMARC-tietueet on tarkistettava. Jos sähköposti jää eri palveluntarjoajalle, MX-tietueita ei tule muuttaa.