Att migrera en WordPress-sajt till ny hosting kan göras på två sätt: snabbt och fult (med några timmars downtime och hopp om att inget går sönder), eller ordentligt (med korrekt staging-test, DNS-cutover med låg TTL och under 5 minuter nedtid). Den här guiden går igenom det andra alternativet.

Kort svar

En “korrekt” WordPress-migration tar typiskt 4–24 timmar planeringstid och har 4 faser:

  1. Förberedelse (1–3 dagar i förväg): sänk DNS-TTL, ta full backup, dokumentera nuvarande setup
  2. Staging-migration: kopia till ny hosting, testning av allt funktionellt
  3. Sync + cutover: slutgiltig databas-sync, DNS-byte, SSL-omkopplade
  4. Post-migration: validering, monitoring, rensning av gamla servern

Med rätt verktyg och plan ger detta <5 minuter faktisk downtime, eller ofta noll om man gör det riktigt.

När behöver ni migrera?

Vanliga skäl 2026:

  • Prestanda: nuvarande hosting är långsam, ni vill ha snabbare TTFB
  • Säkerhet: nuvarande hosting saknar WAF/backup/managed updates
  • GDPR: ni vill flytta från amerikansk hosting (WP Engine, Kinsta) till EU/Sverige
  • Kostnad: ni har växt ur ett enterprise-paket eller vill minska kostnad
  • Support: ni vill ha svensktalande support i stället för 24h-ticketsvar från Singapore
  • Konsolidering: flera sajter ska samlas hos en leverantör

Om ingen av dessa stämmer — migrera inte. Den största risken vid migration är att något subtilt går sönder och ni inte märker det förrän en kund klagar.

Fas 1: Förberedelse (1–3 dagar innan)

Sänk DNS-TTL

Det här är kritiskt. Standard-TTL för WordPress-domäner är ofta 3600s (1 timme) eller 14400s (4 timmar). När ni byter A-record kommer cachade DNS-svar att fortsätta peka på gamla servern tills TTL går ut.

Sänk TTL till 60 sekunder minst 24h innan migrationen. Då hinner DNS-cachar globalt uppdatera sig.

# Före: A    www    300    192.0.2.10
# Efter:  A    www    60     192.0.2.10

Efter migrationen återställer ni till t.ex. 3600.

Full backup av nuvarande sajt

Två oberoende backuper:

  • En filsystem-backup (tar.gz av hela wp-content/, wp-config.php, .htaccess)
  • En databasdump (mysqldump eller phpMyAdmin export)

Spara båda lokalt och kopia på extern lagring. Om något går fel ska ni alltid kunna rulla tillbaka.

Dokumentera nuvarande setup

Lista som ska finnas innan ni rör något:

  • PHP-version på nuvarande server
  • MySQL/MariaDB-version
  • Aktiva plugins + versioner (wp plugin list om WP-CLI finns)
  • Cron-jobb (WP Cron eller server-cron)
  • Symlinks och custom .htaccess-regler
  • Externa integrationer (Stripe, Klarna webhooks, Mailchimp, Fortnox m.fl.)
  • SSL-certifikat — Let’s Encrypt eller köpt? Var ligger nycklarna?

Sätt sajten i underhållsläge — eller inte

För ren content-sajt: nej, inte än. Vi gör det vid cutover.

För e-handel eller forum med många skrivande användare: kortvarigt underhållsläge under databasdump kan vara värt det för att undvika att nya orders/posts hamnar mellan stolarna.

Fas 2: Staging-migration

Kopiera filer

Snabbaste sättet: rsync mellan servrarna om båda har SSH.

# Från gamla servern
rsync -avz --progress /var/www/site/web/ user@nya-server:/var/www/site/web/

Om SSH saknas på gamla servern: ladda ner via SFTP, ladda upp till nya. Långsammare men funkar.

Importera databasen

# På gamla servern
mysqldump -u wpuser -p sajt_db | gzip > sajt_db.sql.gz

# Överför till nya servern
scp sajt_db.sql.gz user@nya-server:/tmp/

# På nya servern
gunzip -c /tmp/sajt_db.sql.gz | mysql -u newuser -p newsajt_db

Anpassa wp-config.php

På nya servern, uppdatera:

define( 'DB_NAME',     'newsajt_db' );
define( 'DB_USER',     'newuser' );
define( 'DB_PASSWORD', '...' );
define( 'DB_HOST',     'localhost' );

Lägg också till om de inte finns:

define( 'WP_HOME',    'https://temporär-staging-url.adminor.net' );
define( 'WP_SITEURL', 'https://temporär-staging-url.adminor.net' );

Detta gör att WordPress fungerar via en temporär URL för testning utan att rörda produktions-domänen.

Sätt staging-URL i hosts-filen för testning

I stället för att ändra DNS, lägg in i din egen /etc/hosts (eller C:\Windows\System32\drivers\etc\hosts):

192.0.2.20    er-sajt.se
192.0.2.20    www.er-sajt.se

Nu pekar din lokala maskin på nya servern, men resten av världen ser fortfarande gamla. Detta är kritiskt för korrekt testning av SSL, kassa, login etc.

Testa allt

Checklista som faktiskt fångar problem:

  • Startsidan laddar utan fel
  • Admin-inlogg fungerar
  • Permalinks är korrekt rendererade (gå till Settings → Permalinks och spara)
  • Sökfunktion fungerar
  • Kontaktformulär skickar mail
  • E-handel: lägg en testorder med testbetalning (Klarna sandbox eller Stripe test-mode)
  • Caching-plugins skickar korrekt cache-headers (kolla med curl -I)
  • WP Cron körs (eller server-cron om det är så ni gör)
  • Bilder laddas
  • Custom .htaccess-regler eller nginx-rewrites fungerar
  • Externa integrationer (Mailchimp, Klarna webhooks) når servern

Fas 3: Sync + cutover

Slutgiltig databas-sync

Mellan staging-test och cutover går det typiskt 1–7 dagar. Under den tiden har data förändrats på gamla servern (nya orders, posts, kommentarer).

Lösning: ny databasdump och re-import precis innan DNS-bytet.

# 5 minuter innan cutover, på gamla servern
mysqldump -u wpuser -p sajt_db | gzip > sajt_db_final.sql.gz
scp sajt_db_final.sql.gz user@nya-server:/tmp/

# På nya servern
gunzip -c /tmp/sajt_db_final.sql.gz | mysql -u newuser -p newsajt_db

För riktigt höga skrivvolymer: använd MySQL replikation från gamla till nya servern, så att skillnaden är 0 vid cutover. Det är overkill för 99% av WP-sajter.

Search-replace för URLer i serialized data

Om ni har testat med temporär staging-URL, måste den nu bytas till riktiga domänen. Använd WP-CLI (aldrig en rå MySQL UPDATE — det förstör serialized data i wp_options och postmeta):

wp search-replace 'https://temporär-staging-url.adminor.net' 'https://er-sajt.se' --all-tables --skip-columns=guid

--skip-columns=guid är viktigt — guid är historisk identifierare och ska aldrig ändras.

--all-tables säkerställer att även custom tabeller (WPML, WooCommerce, ACF) får sina URLer uppdaterade.

Uppdatera wp-config tillbaka till live-domän

define( 'WP_HOME',    'https://er-sajt.se' );
define( 'WP_SITEURL', 'https://er-sajt.se' );

DNS-cutover

Ändra A-record (eller AAAA för IPv6) hos er DNS-leverantör:

A    er-sajt.se       192.0.2.20  (nya servern)
A    www.er-sajt.se   192.0.2.20

Med 60s TTL börjar besökare nå nya servern inom 1 minut. Inom 5–10 minuter är >95% av världen på nya.

SSL-certifikat

Tre alternativ:

  1. Let’s Encrypt på nya servern: kör certbot --nginx eller motsvarande efter DNS-cutover (Let’s Encrypt verifierar via HTTP-01 challenge). Tar 30s.

  2. Wildcard-cert från gammal hosting: lyft över private key + cert om ni har det.

  3. Cloudflare framför: aktivera “Full (Strict)” SSL och låt Cloudflare hantera publika certet.

Verifiera med curl -I https://er-sajt.se att HTTPS funkar.

Riv ner underhållsläge

Om ni satt på underhåll under sync — stäng av nu.

Fas 4: Post-migration

Validering (första 24 timmarna)

  • Kolla Google Search Console — eventuella crawl errors
  • Verifiera att 301-redirects (om ni hade några URL-strukturändringar) fungerar
  • Kolla att alla e-postmeddelanden från sajten levereras (kontaktformulär, order-bekräftelser). Mail från ny IP kan flaggas som spam första veckan.
  • Granska serverlogg för 500-fel eller PHP-warnings

Återställ DNS-TTL

A    er-sajt.se   3600   192.0.2.20

Riv ner gamla servern

Vänta minst 7 dagar innan ni stänger av gamla. DNS-propagering kan ta längre i randfall. Behåll en kopia av gamla databasen i 30 dagar för säkerhets skull.

Monitor i 2 veckor

  • Performance: TTFB och PageSpeed
  • Search Console: indexerade sidor, crawl rate, errors
  • Konvertering om e-handel: snabb sanity-check att orderflödet inte ändrats

Vanliga problem och hur de undviks

Problem: Mixed content (HTTPS-sidor som laddar HTTP-resurser)

Beror på hårdkodade http://-URLer i databasen. Lösning: search-replace för att byta http://er-sajt.se till https://er-sajt.se förutom guid:

wp search-replace 'http://er-sajt.se' 'https://er-sajt.se' --all-tables --skip-columns=guid

Problem: PHP-fel som inte fanns på gamla servern

Vanligast: olika PHP-version. Gamla server hade PHP 7.4, nya har 8.3. Vissa plugins är inte 8.x-kompatibla.

Lösning: temporärt sätta PHP 7.4 på nya servern (de flesta managed hostings stödjer val), och uppdatera plugins parallellt tills allt fungerar på 8.3.

Problem: WP Cron körs inte

Default WP Cron triggas av besökare. På låg-trafik-sajter eller om ni gjort en optimering som disable WP Cron, måste det köras av server-cron.

*/5 * * * * curl -s https://er-sajt.se/wp-cron.php > /dev/null 2>&1

Problem: bilder visas inte

Vanligast: fil-permissions felaktiga efter rsync. Sätt korrekt:

chown -R www-data:www-data /var/www/site/web/wp-content/uploads
chmod -R 755 /var/www/site/web/wp-content/uploads

Problem: Kunder rapporterar att de blir utloggade

WordPress-sessioner cachas av auth keys i wp-config. Om ni glömde kopiera dem från gamla servern (eller om de roterades), loggas alla ut.

Lösning: kopiera samma AUTH_KEY/SECURE_AUTH_KEY/etc från gamla wp-config. Eller acceptera att alla loggas ut en gång (kommunicera detta i förväg).

Verktyg värda att känna till

  • WP-CLI — standard 2026, allt går snabbare med command-line
  • WP Migrate Pro — premium-plugin med staging-aware migration
  • Duplicator Pro — pakethanterar hela sajten
  • All-in-One WP Migration — fungerar för småsajter, men begränsningar på filstorlek
  • rsync + WP-CLI search-replace — det “manuella” sättet, alltid funkar

Sammanfattning

Korrekt WordPress-migration utan downtime kräver tre saker: sänkt DNS-TTL i förväg, staging-test med hosts-fil, och search-replace via WP-CLI. Allt annat är variationer på detta tema.

På Adminor managed WordPress hosting ingår gratis migration för alla kunder. Vi tar hand om hela kedjan: databasdump, filöverföring, URL-uppdateringar, DNS-cutover och valideringstest. Typiskt klart inom 24h med <5 minuter nedtid.

Vidare läsning