Hur man kör WordPress-databasmigreringar utan att förstöra din webbplats 

En migrering av en WordPress-databas låter enkelt: exportera databasen, importera den någon annanstans, klart. I praktiken är det steget där fler WordPress-webbplatser går sönder än någon annan.

Anledningarna är specifika. WordPress lagrar serialiserade PHP-objekt i sin databas. En enkel sök-och-ersätt-funktion på en URL bryter tyst den serialiserade datan, vilket gör att din webbplats ser trasig ut på sätt som är svåra att spåra. Plugin-uppdateringar utlöser migreringar av databasscheman som inte kan rullas tillbaka med en filåterställning. Fel databasprefix, en saknad tabell eller en osynkroniserad wp-config.php -fil kan alla producera olika fel som pekar i olika riktningar.

Den här guiden täcker alla scenarier där du behöver köra en WordPress-databasmigrering, hur du gör vart och ett utan dataförlust och hur du åtgärdar de fel som vanligtvis uppstår när något går fel.

Typer av WordPress-databasmigreringar

Alla databasmigreringar är inte likadana. Metoden, risken och förberedelserna skiljer sig åt beroende på migreringstyp.

Flytta databasen till en ny värd eller domän

Detta är det vanligaste scenariot. Du byter webbhotellsleverantör, går från HTTP till HTTPS eller byter varumärke med en ny domän. Databasinnehållet är intakt, men alla URL:er som lagras i databasen måste uppdateras för att återspegla den nya platsen.

Utmaningen: WordPress lagrar URL:er på flera ställen i databasen, inklusive serialiserade arrayer i tabellerna wp_options och wp_postmeta. En manuell sök-och-ersätt-funktion i dessa tabeller som inte tar hänsyn till serialisering kommer att skada informationen i tysthet.

Övergång från staging till produktion

När du bygger en webbplats i staging och skickar den till produktion måste databasen följa med den, och alla staging-URL:er måste ersättas med produktions-URL:er. Detta är en av de vanligaste källorna till problem med migrering från staging till live eftersom utvecklare ofta skickar en fil utan att uppdatera databasen.

Plugin-utlösta schemamigreringar

När plugins modifierar databasstrukturen under en uppdatering kör de en schemamigrering: en ändring av databasstrukturen snarare än bara data inuti den. WooCommerces HPOS-migrering (High-Performance Order Storage) är ett aktuellt exempel. Medlemskapsplugins som flyttar medlemsdata till nya tabellstrukturer är ett annat.

Dessa migreringar körs som en del av plugin-uppdateringsprocessen. Du utlöser dem inte manuellt. Det är därför de kräver förberedelse av staging innan uppdateringen tillämpas på produktion.

  

Vad du behöver innan du migrerar en databas?

Slutför alla alternativ på den här listan innan du kör ett enda kommando eller klickar på exportera.

Fullständig säkerhetskopia av databasen. Exportera hela MySQL-databasen från din nuvarande miljö med hjälp av phpMyAdmin, WP-CLI eller din webbhotellleverantörs säkerhetskopieringsverktyg. Verifiera att säkerhetskopian öppnas och innehåller data innan du fortsätter. En skadad exportfil som upptäcks efter att du redan har skrivit över den ursprungliga databasen kan inte återställas utan en säkerhetskopia på webbhotellsnivå.

Fullständig säkerhetskopia av filer. Din databas kan inte fungera utan motsvarande WordPress-filer. Säkerhetskopiera hela din WordPress-installation tillsammans med säkerhetskopian av databasen.

wp-config.php-information för destinationen. Notera databasnamn, användarnamn, lösenord och värd för destinationsmiljön. Dessa krävs för att ansluta dina WordPress-filer till den importerade databasen.

En staging-miljö. All databasmigrering bör testas i staging innan den körs i produktion. Detta gäller både värd-till-värd-migreringar och migreringar av plugin-uppdateringsscheman.

Kompatibilitet med PHP-versionen är bekräftad. Om du migrerar till en ny värd som kör en annan PHP-version, kontrollera att dina plugin-program och teman är kompatibla med den nya versionen innan migreringen. PHP-versionsavvikelser efter migreringen ger fel som ser ut att vara databasproblem men i själva verket är kompatibilitetsproblem.

Hur man migrerar en WordPress-databas: 3 metoder

Rätt metod beror på din tekniska kunskapsnivå och storleken på din databas. Alla tre hanterar serialiserad data korrekt när de används enligt beskrivningen nedan.

Metod 1: Migreringsplugin (enklast)

Migrerings-plugins hanterar export, import, filöverföring och URL-ersättning i en enda process. De är rätt val för de flesta webbplatsägare utan kommandoradserfarenhet.

Rekommenderade plugins:

Duplicator Pro hanterar databaser på upp till flera gigabyte, stöder schemalagda migreringar och genererar en installationsfil som automatiskt hanterar URL-ersättning. Det är det mest pålitliga alternativet för stora eller komplexa webbplatser.

All-in-One WP Migration skapar en enda arkivfil som innehåller hela din WordPress-installation, inklusive databasen. Gratisversionen har en importstorleksgräns på 512 MB. Premiumversionen tar bort denna gräns. Plugin hanterar serialiserad dataersättning under import.

WP Migrate (tidigare WP Migrate DB) är specifikt utformat för databasmigreringar och push/pull mellan miljöer. Den hanterar serialiserad data korrekt och stöder selektiv tabellmigrering, vilket är användbart när du bara vill hämta innehållsdatabasen från produktion till staging utan att skriva över dina staging-plugin-inställningar.

Steg-för-steg med allt-i-ett WP-migrering:

• Installera och aktivera All-in-One WP Migration på din källwebbplats

• Gå till Allt-i-ett WP-migrering > Exportera

• Välj Exportera till > Fil

• Vänta tills exporten är klar och ladda ner .wpress-filen

• Installera All-in-One WP Migration på din destinationswebbplats

• Gå till Allt-i-ett WP-migrering > Importera

• Dra och släpp .wpress-filen eller klicka för att bläddra efter den

• Bekräfta importen när du uppmanas. Plugin-programmet varnar dig om att detta kommer att skriva över allt befintligt innehåll

• När importen är klar går du till Inställningar > Permalänkar och klickar på Spara ändringar utan att ändra något. Detta rensar omskrivningsreglerna och åtgärdar de flesta 404-fel som uppstår efter migreringen

Metod 2: phpMyAdmin (Manuell)

phpMyAdmin är rätt metod när du behöver full kontroll över migreringen, migrerar en stor databas som plugin-verktyg inte kan hantera, eller behöver migrera en databas oberoende av WordPress-filerna.

Exportera databasen:

• Logga in på phpMyAdmin i din källmiljö för webbhotell via din kontrollpanel

• Välj din WordPress-databas från vänster sidofält

• Klicka på fliken Exportera

• Välj Anpassad exportmetod

• Se till att alla tabeller är markerade

• Under Formatspecifika alternativ, markera Lägg till DROP TABLE / VIEW / PROCEDURE / FUNCTION / EVENT / TRIGGER-sats. Detta säkerställer att importen skriver över befintliga tabeller på ett snyggt sätt, snarare än att orsaka dubbletter av fel

• Under Alternativ för dataskapande, markera Kompletta infogningar och Utökade infogningar

• Klicka på Exportera och spara .sql-filen

Importera databasen:

• Logga in på phpMyAdmin i din destinationshostingmiljö

• Välj eller skapa måldatabasen

• Klicka på tabellen Importera

• Klicka på Välj fil och välj din .sql-fil

• Klicka på Gå för att köra importen

Uppdatering av webbadresserna:

Efter importen måste du uppdatera webbplatsens URL som lagras i databasen. Den enklaste metoden för icke-tekniska användare är att köra följande SQL-frågor i phpMyAdmins SQL-flik och ersätta old-domain.com och new-domain.com med dina faktiska domäner:

UPDATE wp_options SET option_value = replace(option_value, 'https://old-domain.com', 'https://new-domain.com') WHERE option_name = 'webbplatsurl' ELLER option_name = 'hem';

Kör inte en fullständig sök-och-ersätt-funktion över alla tabeller med enbart SQL. Detta kommer att skada serialiserad data. Använd WP-CLI-metoden nedan för den fullständiga ersättningen.

Metod 3: WP-CLI (mest pålitlig för tekniska användare)

WP-CLI är WordPress kommandoradsgränssnitt. Dess search-replace-kommando är den mest pålitliga metoden för att ersätta URL:er i en WordPress-databas eftersom den hanterar serialiserad data korrekt som standard.

Förutsättningar: SSH-åtkomst till din server och WP-CLI installerat. De flesta hanterade WordPress-värdar (Kinsta, WP Engine, Cloudways) har WP-CLI tillgängligt som standard.

Exportera databasen:

wp db export backup-$(datum +%Y%m%d).sql

Detta exporterar hela databasen till en daterad .sql-fil i din nuvarande katalog.

Importera databasen till destinationen:

wp db import backup-20260101.sql

Ersätt backup-20260101.sql med ditt faktiska filnamn.

Kör URL-ersättningen:

wp search-replace 'https://old-domain.com' 'https://new-domain.com' --precise --all-tables

Flaggan –precise säkerställer att serialiserad data hanteras korrekt. Flaggan –all-tables tillämpar ersättningen på alla tabeller i databasen, inklusive tabeller som skapats av plugins.

Verifiera ersättningen:

wp search-replace 'https://old-domain.com' 'https://new-domain.com' --precise --all-tables --dry-run

Att köra med –dry-run visar hur många ersättningar som skulle göras utan att de faktiskt gjordes. Kör detta först för att verifiera att antalet ser korrekt ut innan du kör live-ersättningen.

Töm cachen och skriv om reglerna:

wp cache-tömning

wp omskrivning flush

Hur hanterar man serialiserad data under migrering?

Detta är den mest missförstådda delen av WordPress-databasmigrering och den vanligaste orsaken till avbrott efter migrering.

Varför stoppar enkel sök-ersätt WordPress?

WordPress lagrar viss data i ett serialiserat PHP-format. En serialiserad sträng ser ut så här:

a:2:{s:4:"hem";s:22:"https://gammal-domän.com";}

s:22-delen betyder "sträng med 22 tecken". Om du kör en sök-och-ersätt-funktion som ändrar old-domain.com till new-domain.com, ändras stränglängden, men antalet s:22 uppdateras inte. WordPress försöker läsa en sträng med 22 tecken, hittar en med en annan längd och producerar ett fel.

Felet manifesterar sig ofta som en tom vit skärm, trasiga widgetområden eller plugin-inställningar som verkar tomma efter migreringen. Det är svårt att spåra utan att känna till serialiserad data.

Hur kör man en säker sökning och ersättning?

Använd någon av dessa serialiseringsmedvetna metoder:

WP-CLI (rekommenderas):

wp search-replace 'https://old-domain.com' 'https://new-domain.com' --precise --all-tables

Better Search Replace-plugin: Installera Better Search Replace-pluginet i WordPress. Det hanterar serialiserad data som standard och erbjuder ett testalternativ för att förhandsgranska ändringar innan de tillämpas. Detta är rätt alternativ om du inte har WP-CLI-åtkomst.

Interconnect/it Search Replace DB: Ett PHP-skript som du laddar upp till din serverrot, kör via webbläsaren och raderar efter användning. Det hanterar serialiserad data och stöder live- eller torrkörningslägen.

Hur verifierar man att Sök-Ersätt fungerade?

Kontrollera dessa platser efter att du har utfört utbytet:

• Gå till Inställningar > Allmänt i din WordPress-instrumentpanel. Bekräfta att WordPress-adressen och webbplatsadressen visar din nya domän

• Besök webbplatsens användargränssnitt och kontrollera webbläsarens utvecklarkonsol för varningar om blandat innehåll (HTTP-resurser som laddas på en HTTPS-domän)

• Kontrollera ditt mediebibliotek: visas rätt URL om du klickar på en bild

• Kör en Screaming Frog-genomsökning eller använd Broken Link Checker för att söka efter återstående URL:er från gamla domäner.

Plugin-utlösta databasmigreringar i WordPress

Till skillnad från värd-till-värd-migreringar utlöser du inte dessa manuellt. De körs som en del av plugin-uppdateringsprocessen, vilket är anledningen till att staging-förberedelser är viktigare här än någon annanstans.

Hur fungerar WooCommerce-databasmigreringar?

WooCommerce introducerade HPOS (High-Performance Order Storage) som en stor strukturell förändring av hur ordrar lagras. När du migrerar till HPOS skapar WooCommerce nya dedikerade ordertabeller och flyttar all historisk orderdata till dem.

Denna migrering körs automatiskt när du aktiverar HPOS i WooCommerce-inställningarna eller när du uppdaterar WooCommerce på en webbplats med migreringen väntande. Den kan inte ångras genom att återställa filer. Om migreringen körs på en webbplats där vissa plugins inte är HPOS-kompatibla, kommer dessa plugins att sluta fungera korrekt.

Så här förbereder du dig: Innan du aktiverar HPOS eller uppdaterar WooCommerce i större versioner, kör WooCommerces kompatibilitetskontroll genom att gå till WooCommerce > Status > HPOS. Den listar alla installerade plugins och om de är HPOS-kompatibla. Åtgärda inkompatibiliteter innan migreringen körs.

Hur fungerar migreringar av medlemskapsplugins?

Medlemskaps-plugins, inklusive MemberPress, Paid Memberships Prooch Restrict Content Pro, skapar sina egna anpassade databastabeller för medlemsregister, prenumerationsdata och transaktionshistorik. När dessa plugins uppdateras mellan större versioner ändrar de ibland dessa tabellstrukturer.

Eftersom medlemsdata lagras i anpassade tabeller snarare än vanliga WordPress-tabeller, inkluderar migrerings-plugins inte alltid dessa data i sina exporter som standard. Verifiera uttryckligen att ditt säkerhetskopieringsverktyg täcker anpassade plugin-tabeller innan du migrerar en medlemswebbplats.

Hur förbereder man sig innan ett plugin utlöser en migrering?

• Konfigurera en staging-miljö som exakt speglar din produktionsdatabas

• Tillämpa plugin-uppdateringen på staging först

• Verifiera alla berörda funktioner (kassa, medlemsinloggning, prenumerationshantering) vid uppstart efter uppdateringen

• Om staging godkänns, tillämpa samma uppdatering på produktionen under ett fönster med låg trafik

• Spara en verifierad säkerhetskopia från omedelbart före produktionsuppdateringen

Checklista för databas efter migrering

Gå igenom varje objekt efter en databasmigrering innan du berättar för någon att migreringen är klar.

• WordPress-admin laddas utan fel vid den nya URL:en

• Webbplatsens frontend laddas korrekt vid den nya URL:en

• Alla mediefiler laddas korrekt (inga trasiga bilder)

• Kontaktformulär skickar och bekräftar via e-post

• Användarinloggning fungerar för alla kontotyper

• Om WooCommerce: genomför en testutcheckning från början till slut

• Om medlemswebbplats: logga in som medlem och verifiera åtkomst till innehållet

• Google Search Console visar inga indextäckningsfel efter att webbplatskartan har skickats in igen

• Inga varningar om blandat innehåll (HTTP-resurser på en HTTPS-webbplats) i webbläsarkonsolen

• Inga gamla domän-URL:er syns i sidkällan eller webbläsarens nätverksflik

• Cachning av plugin- cache rensad

• Permalänkstruktur rensad: Inställningar > Permalänkar > Spara ändringar

Vanliga fel vid migrering av WordPress-databas och hur man åtgärdar dem

Försök inte att köra migreringen igen innan du har identifierat felet. Varje fel nedan visar exakt vad som gick fel och vad du ska ändra innan du försöker igen.

Fel 1062: Duplicerad post för nyckel PRIMARY

Det här felet visas när du importerar en databas till en destination som redan innehåller data. Importskriptet försöker infoga en rad med ett ID som redan finns.

Åtgärd: Innan du importerar, ta antingen bort alla befintliga tabeller i destinationsdatabasen eller se till att din exportfil innehåller DROP TABLE-satser. I phpMyAdmin, när du exporterar, markera alternativet att inkludera DROP TABLE-satser. I WP-CLI: wp db reset –yes, sedan wp db import backup.sql.

Fel 2002: Kan inte ansluta till MySQL-servern

Det här felet indikerar att WordPress inte kan ansluta till databasservern. Det visas vanligtvis efter en migrering när databasens värdnamn i wp-config.php inte matchar det faktiska värdnamnet på den nya servern.

Åtgärd: Öppna wp-config.php och kontrollera DB_HOST-värdet. På de flesta delade webbhotell är det localhost. På hanterade WordPress-webbhotell kan det vara ett specifikt värdnamn som anges i din webbhotellsöversikt. Uppdatera DB_HOST-värdet så att det matchar din destinationsservers MySQL-värdnamn.

Fel 1045: Åtkomst nekad för användare

Det här felet betyder att databasens användarnamn eller lösenord i wp-config.php inte matchar inloggningsuppgifterna för databasen på destinationsservern.

Åtgärd: Öppna wp-config.php och verifiera att DB_USER och DB_PASSWORD matchar användaruppgifterna för databasen på din destinationsserver. Gå till MySQL-databaser i cPanel och bekräfta att användaren är tilldelad rätt databas med alla behörigheter.

Slutliga tankar om WordPress-databasmigreringar

WordPress-databasmigreringar går oftast sönder på grund av två saker: serialiserad data som en enkel sök-och-ersätt-funktion korrumperar i tysthet, och plugin-utlösta schemamigreringar som körs automatiskt under uppdateringar på oförberedda webbplatser.

Båda problemen har tydliga lösningar. Använd WP-CLI eller ett serialiseringsmedvetet sök-ersätt-verktyg istället för SQL-sök-och-ersätt. Förbered en staging-miljö innan du tillämpar plugin-uppdateringar som utlöser schemamigreringar. Ta en verifierad säkerhetskopia före varje migreringssteg och testa den innan du förlitar dig på den.

De tre migreringsmetoderna som tas upp ovan täcker alla färdighetsnivåer: plugins för de som vill ha en guidad process, phpMyAdmin för de som behöver detaljerad kontroll och WP-CLI för de med kommandoradsåtkomst. Välj den metod som bäst passar din miljö och följ checklistan efter migreringen innan du avslutar projektet.

Om du behöver en WordPress-databasmigrering som hanteras av ett erfaret team har Seahawk hanterat migreringar för hundratals WordPress-webbplatser på alla komplexitetsnivåer.

Vanliga frågor om WordPress-databasmigreringar