Guide - 24 kapitler - Migrering til Shopify: Praktisk guide

At migrere en webshop er en af de mest krævende opgaver i e-handel. Du ændrer ikke kun design eller system. Du ændrer URL-struktur, produktdata, kategorilogik, betalingsopsætning, feeds, tracking, søgning, filtre, arbejdsgange og ofte også databehandleraftaler og moms-opsætning. Derfor er en migrering både risikofyldt og forretningskritisk.

Bevar først de produkttekster, SEO-titler, beskrivelser, kategoritekster og den navigation, der hjælper kunderne i dag. Flytningen skal give en stabil baseline, før du gennemfører større indholdsændringer eller redesign. Nødvendig oprydning dokumenteres som konkrete undtagelser med begrundelse, ansvarlig og godkendelse.

Guiden samler en proces til at afklare data, integrationer, redirects og lancering. Anbefalingerne skal tilpasses din webshop og kontrolleres med prøveimport og test. Du kan læse guiden fra start til slut eller springe til det kapitel du står med lige nu - din fremgang gemmes lokalt, så du kan vende tilbage senere. Den har en parallel Shopify-migreringstjekliste med alle konkrete kontrolpunkter du kan arbejde dig igennem.

Hvornår skal du migrere

Ikke alle webshops bør migrere. En migrering er ikke et mål i sig selv. Den er rigtig, når den løser reelle begrænsninger i forretningen.

Typiske tegn på at tiden er rigtig

En migrering giver mening, når den nuværende platform holder virksomheden tilbage. Det kan være tung vedligeholdelse, dyre særtilpasninger, dårlig mobiloplevelse, langsom udviklingshastighed, svære integrationer eller en drift hvor for meget afhænger af udviklere og manuelle processer.

Det er også et stærkt signal, hvis du ikke længere kan arbejde hurtigt nok med kampagner, nye kollektioner, merchandising, email flows, markeder eller betalingsopsætning. Platformen skal understøtte forretningen. Bremser den tempoet, bliver den et problem.

Hvornår det er en dårlig idé

En migrering er en dårlig idé, hvis den primært drives af utålmodighed, mode eller intern frustration. Hvis den nuværende shop kan løfte forretningens krav, og problemerne reelt handler om indhold, marketing, sortiment eller organisering, vil et platformskifte sjældent løse det.

Det er også en dårlig idé at migrere midt i højsæson, uden ejerskab, uden datakortlægning og uden klare succeskriterier.

Beslut ud fra gevinster og begrænsninger

Beskriv de problemer, skiftet skal løse, og sammenlign med at forbedre den nuværende løsning. Afprøv afgørende krav, og beregn både omkostningerne ved flytningen og den efterfølgende drift.

Hvem denne guide er til

Jeg har skrevet guiden så den passer til forskellige shop-størrelser og modenhed. Find din profil herunder - så ved du hvor meget af guiden der rammer dig direkte.

Mikroshop (1-2 personer, under 500 produkter)

Lav teknisk kompetence, ofte ejerledet. Typisk scenario: vil væk fra en forældet eller dyr løsning, ønsker standardfeatures og lav drift. Har brug for en meget konkret trin-for-trin proces, leverandørvalg og klare “do/don’t”-lister. Undersøg, om CSV eller en migreringsapp dækker de nødvendige datatyper. Et lille produktkatalog kan stadig have komplekse funktioner. Fokusér på kapitlerne om forberedelse, data, redirects og lancering - resten kan du skim-læse.

SMV-shop (2-10 personer, 500-20.000 produkter)

Moderat teknisk kompetence. Typisk scenario: har flere integrationer (økonomi/ERP, fragt, marketing), flere betalingsformer og ønsker bedre performance og skalering. Har brug for skabeloner til data mapping, testplan og en konkret integrationscheckliste. API-baserede integrationer er ofte relevante. Tidsplanen afhænger af integrationer, datakvalitet og test. Hele denne guide er skrevet til dig.

Webshop i vækst (10-50 personer, flere markeder)

Højere kompleksitet, SEO er kritisk. Typisk scenario: har ofte mange URL’er, flere sprog og avanceret katalog med varianter og attributter. Her er URL-mapping, redirects, canonical/hreflang og langvarig redirect-vedligehold centralt. Afklar arbejdet for hvert marked, før tidsplanen fastlægges. Læs særligt kapitlerne om SEO, tracking, Markets og compliance.

Større virksomhed med en kompleks løsning

Høj teknisk kompetence. Typisk scenario: migrering kræver specialudvikling, staged deploy, avanceret test og kontrollerede releases. API-baseret migrering og partner-setup er ofte nødvendigt. Planlæg særskilt tid til afprøvning af de mest kritiske krav. Denne guide er et udgangspunkt - du får brug for yderligere arkitektur-arbejde og formentlig flere hænder.

Valg af platform

Platformvalget afgør, hvor meget migreringen bliver platformskonfiguration versus systemudvikling. Inden du beslutter dig, skal forretningskravene kobles til driftsmodel, import-muligheder, integrationer og SEO-kontrol.

Sammenligning af platforme

Her er en praksisnær sammenligning af de fire typiske valg:

Hvorfor Shopify ofte er det rigtige valg

Shopify er for mange webshops det mest oplagte valg, fordi platformen kombinerer stabil drift, bred app-understøttelse, et stort temamarked, standardiserede flows og relativt hurtig implementering.

Fordelen er ikke kun teknikken. Den store gevinst er driftsmodellen. Man bruger mindre energi på servere, kerneopdateringer og plugin-konflikter og mere energi på produkter, indhold, kampagner og konvertering.

Hvornår Shopify ikke er svaret

Shopify er ikke perfekt til alle. Er virksomheden stærkt afhængig af meget specialiseret B2B-logik, tung prisdifferentiering, meget komplekse checkout-regler eller dybe specialintegrationer, skal kravene vurderes grundigt før beslutningen. Det gælder især hvis du kommer fra en løsning med mange specialtilpasninger. Her er det afgørende at skelne mellem funktioner der er reelt nødvendige, funktioner der blot er vaner, og funktioner der kan løses enklere på Shopify.

Kend platformens begrænsninger før du vælger

Shopify har nogle konkrete begrænsninger du skal kende tidligt:

• Varianter: Op til 2.048 varianter pr. produkt og maks 3 option-typer. Apps der ikke bruger Shopifys nyere GraphQL produkt-API’er kan få forringet oplevelse ved produkter over 100 varianter.
• CSV-grænser: Produkt-, kunde- og lager-CSV’er må ikke overstige 15 MB per fil. Store kataloger skal splittes.
• Kundeadgang: Adgangskoder kan ikke flyttes via kunde-CSV. Planlæg login efter kontotypen; Shopifys kundekonti bruger som udgangspunkt en engangskode via e-mail.
• Variant-metafields: Understøttes ikke i produkt-CSV. Kræver API eller dedikerede apps.
• Produkt-collections i CSV: Et produkt kan kun tilknyttes én collection via CSV’s Collection-kolonne.
• Ordrehistorik: Ordrer kan ikke importeres med Shopifys indbyggede CSV-import (kun eksporteres). Kræver apps eller API.
• Brugere pr. abonnement: Kontrollér antallet af medarbejderkonti og roller i det valgte abonnement. Det skal passe til dem, der skal drive butikken.
• Ingen undo på import: Når en produktimport er startet, kan den ikke afbrydes, og der er ingen import-historik i admin.

Beslutningsrammen

I praksis stiller jeg tre spørgsmål: Hvor meget specialudvikling kræver dine vigtigste flows? Hvor mange integrationer skal være “must-have” ved lancering? Hvor hurtigt skal teamet kunne arbejde efter lancering? Svarene afgør om du skal på Shopify Basic, Shopify Plus, WooCommerce eller en custom/headless løsning.

Migreringsmetoder - CSV, apps eller API

Shopify beskriver tre hovedveje til at flytte data: kopier/move manuelt, importer via CSV/apps, eller brug Admin API. Valget afgør både tid, risiko og omkostning.

Sammenligning af migreringsværktøjer

CSV: Shopifys indbyggede importmuligheder

CSV er den dokumenterede standardvej for mange butikker. Produkt-CSV’en er nyttig ved skift fra andre platforme, men du skal kende grænserne: 15 MB per fil, ingen undo når importen er startet, og ingen historik over tidligere imports i admin.

CSV har også “data dependencies” - variantrelaterede kolonner kræver option-kolonner, og fejl opstår hvis man fjerner kolonner uden at forstå afhængighederne.

Brug CSV hvis du har en simpel shop, kan leve med begrænsningerne og vil holde omkostningen nede.

Apps: Afklar ansvar og kontrollér resultatet

Shopifys egen Store Migration app er gratis og importerer fra udvalgte platforme via konto-forbindelse eller CSV. Den understøtter pt. Square, WooCommerce, Etsy, Wix, Amazon, eBay, Clover og Lightspeed R/X (Vend). Tjek altid den aktuelle liste i Shopify App Store - den opdateres løbende.

Tredjepartsapps som Matrixify, LitExtension og Cart2Cart kan være relevante, når standardimport ikke dækker datamængde eller felter. Vurder hver løsning på den aktuelle datadækning, mulighed for genkørsel og dokumentation. Test et repræsentativt datasæt, før du vælger værktøj.

Kontrollér, hvilke SEO-felter og redirects den valgte app håndterer. Sammenlign titler, beskrivelser og gamle adresser med kilden, herunder filter-URL’er, paginering og kampagnesider. Data der ikke har et standardfelt i Shopify - som reviews, custom attributter og ikke-standard metafields - kræver typisk separat håndtering via API eller dedikerede apps.

Apps er det rigtige valg når CSV er for stivt men custom-udvikling er overkill.

API - til komplekse migreringer

Shopifys Admin API bruges til programmatisk flytning af data. Her skal du planlægge for rate-limits (GraphQL bruger et cost-baseret point-system, REST bruger faste request-limits per sekund), fejl-håndtering og delta-migrering.

API er det rigtige valg når du har mange ordrer at flytte, brug for variant-metafields, eller særlige datamodeller der ikke passer ind i CSV’ens struktur. Det kræver udviklingskompetence og en testplan.

Beslutningskriterierne

• Data passer i standardformatet: Afprøv CSV med et repræsentativt udsnit.
• Flere datatyper eller gentagne importer: Undersøg apps med den nødvendige datadækning og mulighed for genkørsel.
• Særlige relationer eller forretningsregler: Afklar behovet for API og specialudvikling. Produktantal alene afgør ikke metoden.

Delta-migrering - sådan minimerer du nedetid

Ved større shops er ét problem at data ændrer sig mens migreringen er i gang: nye ordrer kommer ind, lager opdateres, produkter tilføjes, kunder opretter konti. Hvis du tager et snapshot mandag og går live fredag, er snapshot’et fem dage gammelt ved lancering.

Ved en delta-migrering overfører du først hovedparten af data og derefter de ændringer, der er kommet til. Afklar, hvordan dit valgte værktøj identificerer opdaterede poster, undgår dubletter og håndterer sletninger. Metoden skal testes; den følger ikke automatisk med enhver migreringsapp.

For nogle butikker kan et kort, aftalt stop for ændringer være nok. Andre kræver en delta-migrering. Valget afhænger af aktiviteten under flytningen og den nedetid, virksomheden kan acceptere.

Forberedelse og kortlægning

Begynd med at kortlægge data og arbejdsgange, så importmetoden vælges på et konkret grundlag.

Før noget bygges, skal du have et komplet billede af den nuværende shop. Det gælder ikke kun produkter og sider, men hele det tekniske og forretningsmæssige setup omkring webshoppen.

Start med din nuværende løsning

Før du migrerer, skal du have styr på al eksisterende data og alle systemer der er koblet til webshoppen. Mange undervurderer dette trin. Det er en fejl.

Et typisk dansk setup kan se sådan ud: CMS: Magento. ERP: e-conomic. E-mail CRM: Klaviyo. Fragt: GLS. Betaling: Clearhaus, Quickpay og MobilePay. Det afgørende er ikke om dit setup ligner dette præcist. Det afgørende er, at alt bliver dokumenteret så intet vigtigt falder mellem to stole.

Det du skal kortlægge

Kortlæg som minimum:

• URL’er: produkter, kategorier, brand-sider, blog, filter-kombinationer, paginering, downloadfiler, gamle kampagnesider, support-sider
• Produktdata: titel, varianter, SKU, GTIN/EAN, billeder, beskrivelser, tags, brands, kategorier, lagerstatus, metafields
• SEO-data: titler, beskrivelser, headings, canonical, structured data, interne links, indeksstatus
• Indhold: sider, blog, guides, FAQ, manualer, trust-elementer
• Integrationer: betaling, fragt, regnskab, email, CRM, feeds, reviews, consent, tracking, POS
• Forretningslogik: rabatregler, gavekort, bundles, kundetyper, B2B, lager, returflows

Gennemgå løsningen før migreringen

Før du rører noget som helst, skal du etablere en baseline. Audit-arkens vigtigste kolonner:

Denne gennemgang bliver dit før-billede. Gem også ordrer, omsætning og kanalfordeling for sammenlignelige perioder samt kampagner og sæsonudsving.

Krav, feltmapping og accept af prøveimport

For hver datatype noterer du omfang, kildefelt, målfelt, transformationsregel og ansvarlig. Gem relationerne mellem gamle og nye produkt-, variant-, kunde- og ordre-id’er. Download feltmapping-skabelonen, åbn den som UTF-8 med komma som separator, og erstat eksempelrækkerne med egne felter. Den er et arbejdsark, ikke en Shopify-importfil.

Aftal konkrete acceptkriterier før prøveimporten. Et illustrativt testsæt kan være 12 produkter med 28 varianter, 5 kundeprofiler og 8 historiske ordrer, hvis kunder og ordrer er i scope. Optæl både før og efter, og afstem alle forventede relationer. Kontrollér eksempelvis SKU TEST-SORT-M, pris 249,00 DKK, lager 7 på den aftalte lokation, billeder og SEO-tekst samt at en testordre hører til den rigtige kunde og variant. Tallene er eksempler, ikke en grænse for en tilstrækkelig test. Vælg også de svære varer, markeder og undtagelser.

Godkend først fuld import, når antal, stikprøveværdier og relationer stemmer, eller afvigelser er forklaret og godkendt. En importlog uden fejl er ikke alene et acceptkriterium.

Særlige data kræver særskilt beslutning

Når de indgår i aftalt scope, skal anmeldelser, eksisterende gavekort, aktive abonnementer og loyalitetsdata have egne rækker i feltmapping-arket. Vælg for hver datatype: flyt, genskab, arkivér eller udelad. Notér grundlag, navngiven ejer og godkendelse. Eksemplerne i arket er illustrationer, ikke en produkt-CSV eller et løfte om importstøtte.

• Anmeldelser: Bevar relation til produkt/variant, dato og reel afsender. Test, at anmeldelsen vises på det rigtige produkt uden opdigtet tilskrivning.
• Gavekort: Afstem oprindeligt beløb, valuta, indløst beløb og restsaldo mod kilden. Test den aftalte håndtering af et eksisterende kort uden at udstede værdi to gange.
• Aktive abonnementer: Afklar kontrakt, næste opkrævning, udbyder og betalingsadgang. Kontinuitet i betalingstokens kan ikke antages; få udbyderens bekræftelse og test det aftalte forløb uden dobbelt opkrævning.
• Loyalitet: Afstem point, niveau og historik mod kunden. Test, at optjening og indløsning følger de aftalte regler.

Kortlæg, hvordan løsningen skal fungere i Shopify

Når kortlægningen er lavet, skal du oversætte det nuværende setup til Shopify. Et typisk eksempel: CMS bliver Shopify, ERP forbindes via Storebuddy til e-conomic, e-mail kører via Klaviyos egen Shopify-app, fragt via Webshipper eller Shipmondo, betaling via Quickpay og MobilePay direkte i Shopify.

Har virksomheden derimod Navision, Business Central, C5 eller Uniconta, kræver det ofte mere specialiseret integrationsarbejde. Der findes standardiserede løsninger på markedet, men de skal afklares tidligt.

Brug værktøjer, ikke mavefornemmelser

Kortlægning bør ske med crawl-værktøj, analyseværktøjer og datatræk - ikke manuel gennemgang alene. De vigtigste fejl gemmer sig i URL’er som ikke er synlige i frontend: filter-URL’er, paginering, parameter-URL’er, gamle downloadstier og udgåede produktsider med historiske links.

En god migrering har et master-ark hvor alt samles: gammel URL, ny URL, sidetype, trafikværdi, redirect-status, indekseringsstatus, ansvarlig og QA-status. Det lyder administrativt. Det er det også. Men det er netop denne disciplin der skiller et sikkert projekt fra et dyrt genopretningsprojekt.

Projektets organisering, roller og ansvar

Fordel ansvar for beslutninger, test og lancering, før arbejdet starter. Aftal, hvem der godkender ændringer og håndterer fejl.

Roller jeg altid anbefaler

• Projektleder/produktansvarlig: ejer scope, beslutninger, tidsplan og kommunikation
• Teknisk lead: ejer datamapping, integrationer, cutover og rollback
• Frontend/tema: ejer design, checkout-UX og performance
• QA og forretning: ejer testcases, testordrer og UAT
• SEO/analytics: ejer URL mapping, redirects, Search Console og tracking
• Compliance/juridisk: ejer DPA’er, privacy policy, cookies og moms

Små shops kan samle flere roller i samme person. Sørg stadig for, at leverancen bliver kontrolleret, og at forretningen godkender testresultaterne.

Dokumentér beslutninger og aftal projektets omfang

Brug en opgavebeskrivelse med omfang og undtagelser samt en beslutningslog med ændringer og begrundelser. Det gør det lettere at følge konsekvenserne for budget og tidsplan.

Kriterier for, hvornår arbejdet er færdigt

Før lancering skal teamet have underskrevet en konkret “Definition of Done” - målbare succeskriterier fordelt på omsætning/drift (checkout virker, testordrer dækker alle flows), SEO (1:1 mapping af kritiske URL’er, permanente redirects, nyt sitemap indsendt), data (produkter, kunder og lager flyttet korrekt, kendte begrænsninger dokumenteret), og compliance (DPA’er på plads, cookies overholdt, faktura-krav understøttet).

Projektplan og tidslinje

Fastlæg tidsplanen efter afklaring af data, integrationer, indhold og test. Aftal, hvilke resultater der skal være godkendt, før næste fase begynder.

Milepæle og leverancer

Det påvirker tidsplanen

• Datakvalitet og behov for at rense eller berige oplysninger.
• Funktioner og integrationer, der skal tilpasses eller bygges på ny.
• Indhold, sprog, markeder og ændringer i webadresser.
• Adgang til systemer, leverandører og personer, der skal teste og godkende.

Budget opgøres som timer × intern/ekstern timepris plus licens/app-budget som særskilt post. Timepriser, platformabonnementer og app-omkostninger varierer - jeg giver ingen faste priser i denne guide, og en reserve til uforudsete opgaver skal fastsættes efter projektets usikkerheder.

URL-struktur og redirects

Her afgøres meget af resultatet. Hvis en webshop mister synlighed efter migrering, skyldes det ofte redirects, host-fejl, ændret navigation eller svag indeksering.

Det kritiske mange glemmer

Shopifys URL-struktur kan afvige fra den gamle platform. Kortlæg ændrede adresser, og test, om de skal omdirigeres til en relevant erstatning. Adresser, der bevares og fortsat virker, behøver ikke en redirect.

Shopify har en indbygget redirect-manager (Content → Menus → URL redirects) hvor du kan oprette redirects manuelt eller importere/eksportere via CSV.

Eksempel på URL-mapping

Her er et simpelt eksempel på mapping fra en typisk gammel struktur til Shopify:

Fremgangsmåden

1. Lav et ark med to kolonner: Redirect from og Redirect to
2. Kortlæg alle gamle URL’er fra crawl + analytics
3. Prioriter: top landing pages, top kategorier/collections, og alle produkter med inbound links
4. Match med de nye Shopify-URL’er
5. Importer redirects i batches
6. Test automatisk hele det forventede redirect-map, og supplér med manuel test af de vigtigste sider
7. Crawl de nye sider og deres interne links
8. Overvåg Search Console i ugerne efter lancering
9. Opret nye redirects løbende - nye 404’er dukker op i uger

Google anbefaler at holde redirects i mindst et år efter migrering. Det er et minimum, ikke en deadline.

Kontrollér hele URL-planen

Download URL-map-skabelonen. Erstat eksemplerne, og klassificér hver adresse som ændret, uændret eller bevidst udgået. Arbejdsarket har QA-felter og er ikke klar til direkte Shopify-import; lav importfilen med Shopifys Redirect from og Redirect to separat.

Lad et crawl- eller HTTP-værktøj teste alle forventede mappings: direkte 301, eller anden passende permanent redirect, til den aftalte destination uden loops eller kæder. Målet skal svare med 200, kunne indekseres og have den rigtige canonical. Test uændrede sider separat for 200, indhold og canonical. Bevidst udgåede sider uden en relevant erstatning kan give 404 eller 410; registrér beslutningen frem for at sende dem til forsiden. Crawl også interne links, så de peger direkte på de nye sider. Manuel top-sidekontrol supplerer hele kortlægningen.

Shopifys redirect-dokumentation angiver en samlet grænse på 100.000 redirects og 20 millioner på Plus, ikke en CSV-batchgrænse på 20.000. Kildeadressen skal være brudt eller ikke længere eksistere som en gyldig side. Reserverede stier og collection-tagfiltre understøttes ikke af Shopifys URL-redirects. URL’er med query-parametre er en særskilt begrænsning: Shopify skriver, at de muligvis ikke virker som forventet. Test de konkrete parameter-URL’er og deres destinationer. Hvis den ønskede omdirigering ikke understøttes, skal en egnet alternativ håndtering aftales og testes, fx en redirect-løsning uden for Shopifys indbyggede URL-redirects. Test også de konkrete sprog- og markedsadresser med deres destinationer. Dokumentér, hvilke redirects der virker i dit setup, og afklar undtagelser, før planen godkendes.

Hvad du især skal undgå

Redirect aldrig alt til forsiden. Redirects skal pege mod den mest relevante erstatning. Undgå også redirect-kæder - et gammelt produkt må ikke gå via flere hop før det lander det rigtige sted.

De ting der oftest bliver glemt: gamle kampagnesider, downloadfiler, blogindlæg, support-sider, filter-URL’er, paginering og udgåede produkter med trafik.

Domæneskift kræver ekstra trin

Hvis du også skifter domæne, skal du bruge “Change of Address”-værktøjet i Google Search Console. Verificer det nye domæne først, indsend sitemap, og overvåg coverage dagligt de første 72 timer.

Produktdata og kategorier

Data skal ikke bare flyttes. De skal kvalitetssikres. Produkter kan ofte importeres via CSV, men det er en fejl at tro at importen alene løser datalaget.

Kortlægning af produktdata

Før du importerer noget, skal du have et mapping-ark der oversætter hvert kildefelt til Shopifys målfelt:

Hvad du skal validere efter import

Efter import skal du specifikt tjekke: varianter, billeder, prisfelter, sammenhæng mellem SKU og variant, brands, GTIN/EAN, produktkategorier, metafields og SEO-felter. Hver af disse kan se rigtige ud i en stikprøve men være forkerte i detaljen.

Test først et repræsentativt udsnit, fx 10-20 produkter; udvid efter kompleksitet. Find fejlene, juster mapping-reglerne, og kør først den fulde import når subset’et er rent.

Kategoristruktur er et strategisk valg

Bevar som udgangspunkt relevante kategorinavne, tekster, interne links og navigation. Tilpas kun det, Shopify kræver, eller dokumentér en godkendt undtagelse. Større ændringer i kategoritræet bør vente, til drift og måling er stabile.

Arbejd kontrolleret: bevar velfungerende strukturer hvis de virker, ændr kun det der har en klar forretningsmæssig gevinst, gør ændringerne målbare, og sørg for komplet redirect-plan og intern linkopdatering.

Udsolgte og udgåede produkter

Udsolgte produkter skal håndteres bevidst. Midlertidigt udsolgt bør ikke nødvendigvis fjernes. Permanent udgået bør ikke stå som en blind 404 uden plan. Produkter med historisk trafik eller annonceværdi bør vurderes særskilt. Og feed, frontend og produktstatus skal være enige om status - ellers får du annoncer der peger på sider der ikke findes.

Kundedata og blogindhold

Kundedata kan flyttes - men ikke alt

Mange tror at en migrering betyder at hele kundeoplevelsen kan flyttes 1:1. Det kan den ikke. Navn, adresse, e-mail og ordrehistorik kan ofte flyttes. Kundernes adgangskoder kan ikke flyttes med Shopifys kunde-CSV.

Planen for kundelogin afhænger af kontotypen. Med ældre konti kan kunder have brug for en invitation eller nulstilling af adgangskode; de nyere kundekonti bruger en engangskode sendt via e-mail. En importeret kundeprofil kan logge ind med sin tilknyttede e-mail uden at oprette en ny profil. Afklar kontomodel, kommunikation og adgang til historiske ordrer, før du flytter data.

Kunde-CSV’en har også begrænsninger: maks 15 MB per fil, og ordreinformation kan ikke importeres via kunde-CSV.

Historiske ordrer uden nye driftsaktioner

Prøv først en lille historisk import efter produkter og kunder. Test, at den ikke sender kunde- eller medarbejdernotifikationer, udløser fulfillment/pakning, trækker lager, bogfører omsætningen igen eller starter e-mailautomatik. Afbryd forbindelser eller brug dokumenterede importindstillinger efter behov; sikkerheden afhænger af det konkrete værktøj og alle tilknyttede integrationer. Kontrollér også genkørsel for dubletter og koblingen mellem kunde, ordre og variant.

Flyt tilmeldinger, afmeldinger og dokumentation for markedsføringssamtykke eksplicit. En importeret kunde er ikke automatisk abonnent. Hold automatik deaktiveret, indtil historik, samtykkestatus og tests er godkendt, og aftal hvem der genaktiverer den.

Kommuniker tydeligt omkring login

Hvis kunderne ikke bliver informeret tydeligt, oplever de migreringen som et problem. Ikke fordi data er væk, men fordi deres adgang ikke virker som før. Planlæg: e-mail til eksisterende kunder, FAQ om nyt login, kundeservice-beredskab de første uger, og tydelige beskeder på login-siden.

Blogindhold kræver manuel gennemgang

Shopify er stærk til commerce, men ikke nødvendigvis lige så stærk til content som fx WordPress. Blogindlæg og artikler vil derfor ofte se anderledes ud efter migreringen. Struktur, billeder, embeds, tabeller og interne links skal typisk gennemgås manuelt.

Det er en klassisk fejl at antage at blogindhold bare kan importeres og fungere perfekt bagefter. Kontroller især overskrifter, billeder, tabeller, produktlinks i indhold, opfordringer til handling, interne links og gamle downloads.

Design og tema

Tema er ikke bare æstetik

Temavalget påvirker performance, fleksibilitet, sektioner, app-kompatibilitet og hvor let shoppen kan vedligeholdes.

En god designmigrering bevarer det genkendelige fra brandet men oversætter det til den nye platforms styrker. Den prøver ikke at kopiere den gamle shop 1:1 hvis det skaber kompleksitet uden gevinst. Den rigtige tilgang er at vælge et modent og gennemtestet tema, bygge med sektioner og templates, holde specialudviklet kode fokuseret, dokumentere alle tilpasninger og teste på mobil tidligt.

Det du bør undgå

Undgå at købe tema efter udseende alene. Vurder fleksibilitet i sektioner, collection- og produktskabeloner, performance, app-kompatibilitet, dokumentation og supportniveau.

Undgå også at lægge for mange visuelle særønsker ind for tidligt. Først skal kerneflows fungere: navigation, collections, produktside, søgning, kurv, checkout og ordrebekræftelser. Alt andet kommer bagefter.

Integrationer, betaling og fragt

Når teams taler om migrering, tænker de ofte på produkter og design. I praksis er integrationer ofte den største risiko.

Klassificer dine integrationer

Del integrationerne i tre: nødvendige ved lancering, kan vente og skal erstattes. Det gør det lettere at afgrænse første leverance.

Kortlæg: betalingsudbydere, regnskab, ERP, lager, fragt, e-mailmarkedsføring, loyalty, anmeldelser, cookie consent, analytics, Merchant Center og eventuelle POS-systemer.

En typisk dansk Shopify-løsning

Et typisk setup for danske shops:

Har virksomheden mere komplekse økonomi- eller ERP-systemer (Navision, Business Central, Uniconta), skal integrationssporet planlægges tidligere og mere detaljeret.

Afklar betaling og fragt før lanceringen

Betalings- og fragtopsætning skal være afklaret tidligt. Det gælder især indløseraftaler, betalingsvindue, MobilePay-flow, fragtregler, fragtpriser, label-print og ordreimport til fragtplatform. Test det hele med rigtige betalinger i live-mode før lancering - ikke kun i sandbox.

Kontrollér både betalingsudbyderens priser og eventuelle tredjeparts-transaktionsgebyrer på Shopifys aktuelle prisside. Beregn omkostningerne med den betalingsopsætning og det abonnement, du overvejer.

Fragtzoner og markeder

Opsæt shipping zones og vær opmærksom på sammenhængen mellem Markets og shipping zones: et land/region skal være i et aktivt market for at kunne sælge dertil. Opsæt shipping profiles og rates per zone. Test mindst tre leveringsmetoder før lancering.

Søgning, filtre og præsentation af varer

Filtre er ofte mere begrænsede end man tror

Mange forventer at filtre og søgning kan overføres direkte. Det kan de sjældent. Der skal tages stilling til hvilke attributter der skal bruges som filtre, og hvordan de vedligeholdes.

Hvis kunder forventer at kunne søge på varenummer, skal det tænkes ind. Det gælder særligt i fagbutikker, B2B og shops med mange tekniske produkter.

Gør tre ting rigtigt her

En god migrering definerer hvilke filtertyper der reelt er vigtige, validerer metadata før temaudvikling, og tester søgning og filtrering med rigtige kundescenarier.

Den dårlige migrering bygger filtrene sent og opdager først efter lancering at værdier er inkonsistente, tomme eller for mange.

Flytning af SEO og måling

Bevar trafikken og genskab tracking

Test SEO og tracking før lancering, og følg dem efter skiftet. Fejl i måleopsætningen kan gøre det svært at skelne mellem ændret kundeadfærd og manglende data.

Sitemap og indeksering

Shopify genererer automatisk sitemap.xml. Efter lancering skal du verificere det nye domæne i Google Search Console og indsende det nye sitemap. Kontroller at sitemap.xml kan hentes uden login - hvis staging-shoppen stadig er password-beskyttet, kan søgemaskiner ikke tilgå sitemap. Fjern password-protection senest ved lancering.

Gennemgå indekseringsstatus og 404-fejl efter lancering. Search Console kan være forsinket, så supplér med en direkte gennemgang af vigtige URL’er og redirects.

On-page SEO

Shopify har indbygget “Edit website SEO” der lader dig redigere title og meta description på hver side. Bevar eller planlæg nye handles konsekvent, opdater interne links i navigation, footer, blog og policies, og tjek noindex/robots-regler efter lancering (kun hvis der er en specifik årsag til at ændre dem).

robots.txt styrer crawling; noindex i meta robots eller HTTP-headeren X-Robots-Tag styrer indeksering. Google understøtter ikke noindex i robots.txt. Kontrollér crawlregler, indeksdirektiver og adgangskodebeskyttelse hver for sig. Blokering af crawl kan forhindre Google i at se et noindex-direktiv. Shopify tillader redigering af robots.txt via robots.txt.liquid; ændr kun regler med et konkret formål.

Omkring 60 tegn til titel og 155 tegn til beskrivelse er redaktionelle pejlemærker, ikke Googles maksimumgrænser; se titler og beskrivelser. Bevar nyttige tekster, og vurder visning og relevans frem for at forkorte dem automatisk.

Test sprog og markeder som URL-par

For hvert aftalt sprog/marked-par, fx da-DK og sv-SE, testes repræsentative produkt-, kategori- og indholdssider. Kontrollér gyldige locale-koder samt hreflang-selvreference og gensidige henvisninger i crawl/HTML; brug URL Inspection til at kontrollere Googles renderede side. Se Googles hreflang-vejledning.

Afstem den tilsigtede canonical for hver version. Test den faktiske gamle locale-URL helt frem til den korrekte endelige sprog-/markedsdestination: direkte permanent redirect ved flytning, 200 ved uændret adresse. En redirect til forkert sprog er ikke godkendt. Registrér par, kilde og destinationer, canonical, observeret resultat, dokumentation og navngiven ejer i testmatrixen; aftalte 404/410-undtagelser dokumenteres særskilt. Gentag på det offentlige domæne efter skiftet.

Affiliate-links og attribution

Kortlæg aktive affiliate-links, deres destination og de parametre eller identifikatorer, udbyderen kræver for attribution. Aftal en navngiven ejer hos marketing og afklar, hvem der får destinationer opdateret hos partneren. Test et reelt link gennem eventuelle redirects til den rigtige slutside, og kontrollér udbydergodkendt attribution i det aftalte testforløb. Bevar nødvendige parametre; fjern ikke alle query-parametre som generel oprydning. Gem observation og godkendelse i testmatrix og lanceringsplan.

Sammenlign strukturerede data

Gem markup fra de gamle repræsentative sider, og sammenlign med det nye tema og apps. Kontrollér relevante Product-data for pris, valuta, lagerstatus og varianter samt BreadcrumbList og organisationsoplysninger. Reviews og ratings må kun medtages, hvis de er reelle og opfylder reglerne for den relevante visning. Markup skal svare til det synlige indhold; undgå dubletter fra tema og apps. Brug Googles Rich Results Test og kontrollér igen efter lancering. Strukturerede data er ikke en forudsætning for crawling og garanterer ikke en særlig visning i søgeresultaterne.

Overgang til den nye GA4-opsætning

GA4 kan opsættes via Shopifys Google-integration eller en anden understøttet integration. Shopifys GA4-vejledning siger, at Google Analytics ikke kan tracke events, før butikkens private mode er slået fra, og henviser til at fjerne adgangskoden. Kontrollér konfigurationen før lancering; almindelig GA4-eventverifikation kræver en offentlig butik. Et særskilt testsetup skal være egnet til netop integrationen og dokumenteres separat.

Min tracking cutover-model:

1. Før migrering: dokumenter nuværende events, konverteringer og UTM-standard i den gamle shop
2. Under opbygningen: kontrollér property, integration, samtykkeindstillinger og mulige dobbelte tags; aftal eventtesten på en offentlig butik eller i et dokumenteret egnet testsetup
3. Ved lancering: fjern adgangskodebeskyttelsen og verificér page_view, add_to_cart, begin_checkout og purchase i DebugView/realtid; kontrollér checkout, værdi, valuta og ordre-id samt dubletter
4. Uge 1: sammenlign events med baseline, fang afvigelser tidligt

Sporing via serveren

Ved en migrering skal både browserbaseret og eventuel serverbaseret måling testes. Registrér de eksisterende hændelser og samtykkesignaler, og afklar, hvilke integrationer der skal genoprettes.

En serverbaseret løsning kan give mere kontrol over dataoverførslen, men fjerner ikke krav om samtykke eller alle målebegrænsninger. Kontrollér især, at samme køb ikke tælles fra flere kilder, og at afvisning af samtykke respekteres i hele forbindelsen.

Vælg løsningen efter behov, omkostninger og mulighed for at vedligeholde den. Der er ingen universel gevinstprocent eller omsætningsgrænse, som gør serverbaseret måling nødvendig for alle webshops.

Consent Mode v2

Google kræver samtykkesignaler til bestemte annoncefunktioner for brugere i EØS. Afklar, hvilke krav der gælder for din brug af Google Ads og Analytics. Consent Mode formidler brugerens valg; det er ikke et samtykkebanner eller en generel tilladelse til at indsamle data.

Opsætningen sker i dit consent-banner (Shopifys built-in, Consentmo eller tredjepart) og kræver at bannerets consent-tilstand sendes til Google via Consent Mode API’et. Bruger du server-side GTM, skal consent-tilstanden også forwarde til server-containeren.

Pixels, samtykke og sporing fra tredjeparter

Shopifys pixel manager håndterer både app pixels og custom web pixels efter deres samtykke- og privatlivstilladelser. Det er placeringen og konfigurationen, der er afgørende, ikke blot leverandørens navn. Scripts indsat uden om pixel manager skal have særskilt samtykkehåndtering. Et banner alene gør ikke webshoppen GDPR-compliant; gennemgå også datagrundlag, aftaler, politikker og rettigheder.

Test før valg, ved accept, afvisning og ændring af valg. Kontrollér lagring, netværkskald og events mod de dokumenterede samtykkeindstillinger, og gem observationerne.

Google Shopping og produktfeeds

Produktfeedets betydning for annoncerne

Et produktfeed er ikke et sideprojekt. Hvis feedet er forkert, sender du annoncebudget mod ugyldige, forkerte eller irrelevante produkter.

Hvad der typisk går galt

De samme problemer går igen: udsolgte varer ligger stadig i feedet, custom labels er væk eller ændret, variantdata matcher ikke, nye URL’er er ikke opdateret i alle systemer, manglende eller forkert GTIN reducerer synlighed, og billeder eller kategorier er ikke valideret korrekt.

Hvad du skal teste før og efter lancering

Kontroller mindst: at alle produkt-URL’er peger til ny shop, at udsolgte produkter håndteres korrekt, at brand/GTIN/kategori er komplette, at billeder er valide, at custom labels virker som planlagt, og at feedet ikke indeholder gamle eller ikke-kanoniske URL’er.

Udpeg en feed-ansvarlig. Bevar eksisterende tildelte produkt- og variant-id’er i Merchant Center, hvor det er muligt; Shopify-id’er kan være nye uden at feed-id’er nødvendigvis skal udskiftes. Google fraråder at ændre et tildelt id, fordi historikken er knyttet til det. Afklar om den valgte feed-integration kan bevare id’erne; dokumentér nødvendige ændringer og en gammel/ny mapping.

Kontrollér, at id’er matcher mellem feed, annoncer, kataloger og produkt-id’er i målehændelser, og bevar custom labels bevidst. Gennemgå Merchant Center-diagnostik efter domæneskift: domæne, canonical URL, billeder, pris, valuta og lagerstatus skal stemme med den offentlige butik.

Jura og overholdelse af regler

En migrering ændrer behandlingskæden: nye leverandører, nye underdatabehandlere, nye dataflows. Compliance er derfor ikke noget der kommer til sidst - det er en del af migreringsprojektet fra starten. Det gælder især for dig med dansk webshop, hvor både GDPR, cookiebekendtgørelsen, moms og forbrugerret rammer samtidigt.

GDPR og databehandleraftaler

Datatilsynet fastslår at du som dataansvarlig skal sikre en skriftlig databehandleraftale når du bruger databehandlere, og at aftalen skal opfylde kravene i art. 28. Du skal også føre passende tilsyn med dine databehandlere.

Shopify er en databehandler for kundedata. Shopifys egen Data Processing Addendum (DPA) beskriver at parterne har separate forpligtelser, og at Shopify ikke har pligt til at fortolke eller rådgive om dine forpligtelser - det er dit ansvar.

Praktiske actions ved migrering:

• Lav en leverandørmatrix: navn, rolle (dataansvarlig/databehandler), datatyper, formål, datalagring, underdatabehandlere, aftale-link, kontrolfrekvens
• Få DPA på plads med Shopify og alle nye apps der behandler kundedata
• Opdater din egen privacy policy til at reflektere det nye setup
• Dokumenter hvilke datapunkter der flyttes (kunder, ordrer) og behandlingsgrundlag for hver type
• Planlæg proces for kunders rettigheder (indsigt, sletning, dataportabilitet)

Datatilsynet understreger også at samtykke kun er ét af flere behandlingsgrundlag, og at du typisk ikke skal bruge samtykke for at behandle kundedata når behandlingen er nødvendig for at levere en bestilling (kontrakt-grundlag).

Cookies og samtykke

Cookiebekendtgørelsen kræver samtykke til ikke-nødvendige cookies og sporingsteknologier. Digitaliseringsstyrelsens cookievejledning fremhæver at det skal være lige så let at afvise som at acceptere - “accepter alle” og “afvis alle” skal være ligestillede.

Datatilsynet understreger at du ofte også skal overholde databeskyttelsesreglerne ud over cookiebekendtgørelsen, fordi cookies kan udgøre personoplysninger.

Ved migrering skal du:

• Auditere alle tags og pixels før lancering (gammel shop + staging)
• Gennemgå banner og pixelkonfiguration samt særskilt samtykkehåndtering for scripts uden om pixel manager
• Teste at “afvis alle” reelt blokerer tredjeparts tags
• Beholde samtykkelog for dokumentation

Moms og OSS/IOSS

Sælger du for mere end 50.000 kr. i momspligtig omsætning, skal du momsregistreres. Skattestyrelsen beskriver både EU-/ikke-EU- og importordningerne under One Stop Shop (OSS). EU-Kommissionen beskriver OSS som frivillig. Grænsen på 10.000 EUR ekskl. moms vedrører, hvor momsen skal betales, ikke et krav om OSS-registrering. Grænsen må ikke være overskredet i hverken indeværende eller foregående kalenderår. For hvert år lægges kvalificerende grænseoverskridende EU-fjernsalg af varer og visse tele-, radio/tv- og elektroniske B2C-ydelser sammen; de to års omsætning lægges ikke sammen. Den forudsætter blandt andet etablering i ét EU-land og vareforsendelse derfra til et andet EU-land. Når grænsen overskrides, eller betingelserne ikke er opfyldt, gælder destinationsmoms som udgangspunkt; frivillig OSS kan forenkle afregningen, mens lokale momsregistreringer kan være et alternativ. Afklar virksomhedens konkrete forhold med revisor.

Shopify har EU VAT-opsætning under Settings → Taxes and duties → European Union, inkl. OSS-registrering. Bruger du importordningen (IOSS) til forsendelser under 150 EUR real værdi, skal det også afspejles.

Skattestyrelsens juridiske vejledning beskriver faktureringspligt som hovedprincip for momspligtige leverancer og krav til fakturaindhold. Ikke-momsregistrerede virksomheder må ikke anføre momsbeløb på faktura.

Ved migrering skal du:

• Afklare om virksomheden bruger OSS og hvor moms afregnes
• Teste at momssatser er korrekte per marked før lancering
• Sikre at faktura-setup lever op til bogføringslovens krav (integrationen til e-conomic eller tilsvarende)
• Konsultere revisor/rådgiver ved tvivl - Shopify understreger selv at moms er merchantens ansvar

Erhvervsstyrelsen beskriver kravene i bogføringsloven og digital bogføring. Sørg for at dine økonomidata kan eksporteres korrekt, at integrationsflow til bogføringssystem kan genskabes, og at dokumentationskrav understøttes af både system og proces.

Forbrugerregler (B2C)

Ved nethandel til forbrugere har du oplysningspligt og 14 dages fortrydelsesret som udgangspunkt. Forbrugerombudsmanden henviser til forbrugeraftaleloven, markedsføringsloven og e-handelsloven.

Genbesøg ved migrering: handelsbetingelser, returpolitik, kontaktoplysninger og ordrebekræftelses-tekster. Sørg for at hele kunderejsen (checkout + e-mails) afspejler de lovpligtige oplysninger.

Fra 19. juni 2026 gælder kravet om en digital fortrydelsesfunktion for relevante online B2C-aftaler med forbrugere i EU, hvor der er lovbestemt fortrydelsesret. Funktionen skal være synligt tilgængelig, have et bekræftelsestrin og sende en bekræftelse på et varigt medium, fx e-mail. Undtagelser for blandt andet visse personlige varer, digitalt indhold og fuldt leverede ydelser skal vurderes konkret. Test både adgang, indsendelse og bekræftelse med den ansvarlige for jura og kundeservice. Se fortrydelsesknap i Shopify og Shopifys EU-vejledning.

Test og gennemgang

En god før lanceringen test dækker tre områder: teknik, SEO og tracking. Den dårlige lanceringsdag er den hvor teamet opdager at noget ikke er testet.

Teknisk test

Test produktvisning (varianter, pris, lager, billeder). Test checkout (betaling, fragt, rabatter, emailkvittering) på minimum tre devices. Test orderflow (fulfillment, tracking, refund). Test høj-variant produkter specifikt hvis du har over 100 varianter per produkt. Test ordrebekræftelses-emails. Lad en person udenfor projektgruppen teste - det er her du fanger det teamet er blevet blind overfor.

SEO-test

Test automatisk hele URL-map’et og supplér med manuel kontrol af top-URL’er fra din gennemgang. Test at sitemap.xml kan hentes uden login. Test at top landing pages er indekserbare (ingen noindex på sider der skal rankes). Crawl interne links og kontrollér canonical, indeksdirektiver og strukturerede data.

Test af sporing

Kontrollér GA4-konfiguration før lancering. På en offentlig butik eller i et særskilt dokumenteret egnet testsetup valideres hændelserne page_view, add_to_cart, begin_checkout og purchase, og vælg nøglehændelser ud fra forretningens mål. Test at consent fungerer: klik “afvis alle” og verificer at ingen ikke-nødvendige tags fyrer. Fjern password-protection før lancering og verificer real-time events samme time.

Oversigt over de ordrer, der skal testes

Download testmatrixen, erstat eksemplerne, og tilføj egne forventede resultater, ansvarlige og dokumentation. Shopify anbefaler at teste hele købsflowet med testordrer. En testmatrix kan omfatte:

Test mindst én fuld ordre per række. Det tager tid, men det fanger fejl du ikke kan fange på nogen anden måde.

Lancering trin for trin

En lancering er ikke en knap du trykker på. Det er en planlagt overgang med klare trin.

Frys ændringer i den gamle shop

Eksportér de aftalte data, gem backup og bevar adgang til den gamle løsning. Aftal præcist tidspunkt og ansvar for ændringsstop eller delta-synkronisering. Afstem nye ordrer, betalinger, lager og kunder efter sidste synkronisering, før webshoppen overtager.

Download lanceringsplanen med ansvar og 90-dages opfølgning. Udfyld navne, tider, acceptkriterier og fejlgrænser; eksempelafsnittet er kun en illustration. Beslutningstageren giver go/no-go ud fra testresultater, afstemning og kendte undtagelser. Udpeg også den person, der kan beslutte og gennemføre rollback.

Gennemgå løsningen før lanceringen

Test produkter, collections, søgning, filtre, checkout, mails, betaling og tracking ifølge testmatrixen ovenfor. Lad en person udenfor projektgruppen teste.

Gennemgå redirects igen

Kontroller toptrafik-sider, topindtjenende produkter, kategorisider, brand-sider og gamle kampagne-URL’er. Hvert af disse skal lande det rigtige sted, ikke bare på forsiden.

Skift domæne og DNS

Forbered eventuelt en lavere DNS TTL i god tid, så den tidligere TTL kan udløbe før skiftet. Lav TTL garanterer ikke et øjeblikkeligt skift, og en høj TTL betyder ikke automatisk nedetid. Gem eksisterende DNS-poster, bevar MX og øvrige e-mailposter, og kontrollér SPF/DKIM, domæne, HTTPS/SSL og mailafsendelse. Skift kun de aftalte webposter. Aftal håndtering af ordrer, hvis begge butikker modtager køb under overgangen.

Planlæg i lavtrafikperiode. Undgå fredage, weekender og højsæsoner. Gå live tidligt om morgenen så du har en hel dag til at fixe ting. Sørg for at relevante personer er tilgængelige - tekniker, content-ansvarlig, kundeservice og marketing skal alle kunne nås.

Opdater feeds, annoncer og tracking

GA4, Meta Pixel, TikTok, Merchant Center, email events og annonce-URL’er skal kontrolleres samme dag. Det er ikke noget der kan vente til mandag. Samme gælder fysiske ting som fakturaer, receipts og link-i-bio.

Fjern adgangskodebeskyttelsen

Nu kan den offentlige butik og sitemap tilgås. Verificér GA4-events, crawl-adgang og indeksdirektiver separat; offentlig adgang garanterer ikke indeksering.

Start overvågningen med det samme

404-fejl, crawlfejl, feedfejl og ordreafvigelser skal fanges i de første kritiske dage. Hav et dashboard åbent og lad det køre.

Plan for at vende tilbage til den gamle løsning

Før du går live, skal du have en rollback-plan for hvad der udløser rollback og hvordan den udføres. Det er ikke pessimisme - det er forsikring.

Hvornår den gamle løsning skal genåbnes

• Betalingsfejl overskrider en på forhånd aftalt grænse for antal, andel eller varighed
• Shipping rates viser “ikke tilgængelig” i primært market
• Kritiske 404’er på top 10 landing pages
• Ordrer kommer ikke igennem til ERP/fragtpartner
• Lagerdata er synligt forkerte på frontend

Sådan vender du tilbage

1. Stop marketing spend og noter tidspunkt. Pause alle betalte kampagner.
2. Afstem nye ordrer, betalinger og lagerændringer, så køb fra den nye butik ikke tabes eller behandles dobbelt.
3. Følg den aftalte plan for DNS og integrationer, når den gamle butik igen kan overtage.
4. Kommuniker tydeligt på site og til kundeservice: “Vi oplever tekniske udfordringer og har midlertidigt skiftet tilbage.”
5. Lav efteranalyse af hvad der gik galt og hvordan det forhindres næste gang.
6. Planlæg ny cutover med rettede fejl - ikke før problemet er løst.

Rollback er en seriøs beslutning der koster tid og troværdighed. Men den er langt billigere end at lade en ødelagt webshop køre videre.

Efter lanceringen og opfølgning

De første uger afgør ofte om migreringen lykkes. Det er normalt at se uro i organisk trafik, indeksering, Shopping-performance, annoncekvalitet, søgning i shoppen og kundeservicehenvendelser. Det unormale er ikke udsving. Det farlige er manglende opfølgning.

Første dag - køb og afstemning

Den teknisk ansvarlige følger betalinger, ordreflow, lager og e-mails. Marketingansvarlig kontrollerer tracking og feed efter åbningen, og SEO-ansvarlig tester hele URL-map’et på det offentlige domæne. Projektansvarlig samler fejl, prioriterer dem og tager stilling til de aftalte rollback-grænser.

Første uge - daglig kontrol

Teknik og kundeservice følger ordrer, refunderinger, login og henvendelser dagligt. SEO-ansvarlig følger 404’er og Search Console, hvor data kan være forsinkede, og kontrollerer, at relevante sider er indekserbare. Feed- og marketingansvarlig kontrollerer Merchant Center-diagnostik, annonce- og e-maillinks, købshændelser, valuta, værdi og dubletter. Nye 404’er vurderes: opret kun redirects, hvor der er en relevant erstatning.

Uge 2-4 - sammenlign med baseline

Projektansvarlig holder en ugentlig gennemgang med teknik, marketing og SEO. Sammenlign faktiske ordrer og omsætning i Shopify/økonomisystemet med kanalmåling, feeds og Search Console. Medregn sæson, kampagner, sortiment og samtykkeændringer. Ved afvigelser undersøges først betaling, lager, feed, indhold, redirects og målefejl; et fald i GA4 er ikke alene bevis for SEO-tab. Gennemgå også performance og kundeservicefejl.

Uge 5-12 og dag 90 - afslutning med ejerskab

Fortsæt ugentlig opfølgning på aftalte målepunkter: ordrer, omsætning, kanaltracking, feeds, indeksering og 404’er mod baseline. Ved 30 dage gennemgås læring og åbne fejl; ved 90 dage godkender projektansvarlig status, resterende opgaver og overdragelse til drift med navngivne ejere. Opfølgningens omfang, periode, ansvar og betaling aftales særskilt. Trafik og omsætning kan svinge efter et platformskifte og kan ikke garanteres.

Risici og forebyggelse

Inden projektet starter bør risiciene listes, vurderes og mitigeres aktivt. Det er hurtigere end du tror, og det sparer timer senere.

Fejl, planen skal forebygge

Starte uden komplet kortlægning

Manglende kortlægning kan efterlade huller i redirects, feeds og indhold. Kontrollér derfor omfanget, før dataimport og udvikling sættes i gang.

Ændre for meget på én gang

Ny platform, ny struktur, nyt design, nye kategorier, nyt brandhierarki og nye apps samtidig øger risikoen voldsomt. Del ændringerne op: flyt først, forbedr bagefter.

Undervurdere redirects

Stadig den mest klassiske fejl. Fejl kan påvirke organisk trafik og skal undersøges hurtigt. Redirects er ikke en “launch-day opgave” - de skal planlægges, testes og vedligeholdes i måneder efter.

Glemme adgangskoden på testmiljøet

Adgangskodebeskyttelse er nyttig i et testmiljø, men skal fjernes, når butikken åbnes. Kontrollér derefter adgang til butik og sitemap samt de forventede analysehændelser. Test både med og uden samtykke.

Glemme gamle billeder og filer

Dokumenter, størrelsesguides, gamle billeder, blogbilleder og supportfiler kan blive overset. Vurder brug og links, og bevar eller omdirigér relevante filer; dokumentér bevidst udgåede filer uden erstatning.

Undervurdere kundelogin

Test, at importerede kunder kan få adgang med den valgte kontotype. Forklar det nye loginforløb, og undersøg både tekniske fejl og uklar kommunikation ved problemer.

Stole blindt på apps

Apps kan hjælpe, men de kan også skabe kompleksitet eller konflikt med tema og struktur. Test dem enkeltvis og dokumenter deres opsætning.

Overse lovkrav og aftaler

“Det tager vi efter lancering” er det klassiske svar. Problemet er at cookies, consent, DPA’er og moms ikke kan efterrepareres uden risiko. Få det på plads før lancering.

Afslutte projektet for tidligt

Planlæg opfølgning som en del af projektet, med aftalt omfang, ansvar og budget for de første 90 dage.

Konklusion

En webshop-migrering er ikke et designprojekt og heller ikke bare en teknisk flytning. Det er et forretningsprojekt med direkte betydning for synlighed, omsætning, drift og kundeoplevelse.

Den dårlige migrering fokuserer på at komme live. Den gode migrering fokuserer på at komme godt videre.

Hvis du planlægger grundigt, kortlægger alt, respekterer redirects, tester feeds og integrationer, håndterer compliance seriøst, kommunikerer tydeligt om kundelogin og tager efter lanceringen alvorligt, kan migreringen blive en af de bedste investeringer i webshoppen.

Denne guide har en parallel Shopify-migreringstjekliste du kan arbejde dig igennem punkt for punkt - med 11 faser fra foranalyse til tæt opfølgning og alle de konkrete kontrolpunkter samlet ét sted.

Står du foran en migrering og vil have en second opinion inden du går i gang, så book en gratis snak med din nuværende webshop og de vigtigste krav til den nye løsning.

Kilder til dataflytning og kundelogin

Shopifys migreringsvejledning beskriver importmetoderne. Kontrollér også kunde-CSV og kundekonti, når kundeprofiler og login planlægges.

Googles vejledning om flytning af websites beskriver redirects, overvågning og mulige udsving. Den giver ikke en garanti for uændrede placeringer eller en fast dato for stabilisering.