Guide - 23 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.

Gjort rigtigt er en migrering samtidig en unik mulighed for at rydde op. Du kan forbedre struktur, performance, drift og konvertering i én samlet proces. En god migrering handler ikke kun om at flytte data. Den handler om at skabe en stærkere webshop og en enklere hverdag.

Denne guide er skrevet på baggrund af rigtige migreringer jeg har ledet siden 2016. Når migreringer går galt, skyldes det sjældent én stor fejl. Det er næsten altid summen af for hurtige beslutninger, mangelfuld kortlægning, for få redirects, dårlig feed-kontrol, svag gennemgang og utilstrækkelig opfølgning efter lancering. 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.

Min tommelfingerregel

Migrer, når mindst tre af disse udsagn er sande: drift og vedligehold tager for meget tid, vækst kræver dyre specialløsninger, integrationer er skrøbelige, mobiloplevelsen er ikke god nok, teamet arbejder for langsomt i den nuværende platform, eller fremtidige planer kræver mere standardisering og skalerbarhed.

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. For dig er Shopifys egen Store Migration app eller ren CSV-import typisk nok. Tidslinje: 2-4 uger. 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. Tidslinje: 4-8 uger. 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. Tidslinje: 6-12 uger. 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. Tidslinje: 8-16 uger. 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.
• Kundepasswords: Kan ikke migreres via CSV. Kunder skal nulstille kodeord.
• 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 via CSV (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.

Vær opmærksom på at apps kan flytte SEO-metadata og redirects, men resultatet har ofte mangler. Meta titles kan mangle, descriptions kan blive afkortet, og redirects dækker sjældent filter-URL’er, paginering og gamle 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

• Under 500 produkter, få integrationer: CSV eller Store Migration app
• 500-10.000 produkter, flere integrationer: Matrixify eller LitExtension + custom scripts til metafields
• Over 10.000 produkter, ordrehistorik, variant-metafields: API-baseret migrering eller partner-setup

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

Den største fejl jeg ser er at starte med importen. En migrering starter ikke med CSV-filer. Den starter med kortlægning.

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, PDF’er, 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 audit bliver dit “før”-billede. Uden det har du ingen måde at måle om migreringen lykkes.

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 PDF-stier 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

Jeg har set migreringer fejle alene på governance - ingen ejer, uklare beslutninger, ingen beslutningslog. Før du starter bygger du projektet op med tydelige roller.

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 - men aldrig samle “projektleder” og “teknisk lead” i én. De skal kunne udfordre hinanden.

Dokumentér beslutninger og aftal projektets omfang

Alle migreringer jeg leder har to faste dokumenter: en scope-kontrakt (hvad er inde, hvad er ude, med konkrete eksempler) og en beslutningslog (hvornår blev hvad besluttet, og hvorfor). Begge forhindrer at projektet udvides usynligt undervejs.

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

En god migrering har en realistisk tidslinje med klare milepæle og beslutningsporte. For små og mellemstore shops passer en 8-12 ugers plan ofte godt.

Milepæle og leverancer

Estimater efter webshoppens størrelse

• Lille butik (under 500 produkter, få integrationer): 2-4 uger
• Mellem butik (500-10.000 produkter, flere integrationer, SEO-sårbarhed): 4-8 uger
• Stor butik (over 10.000 produkter, custom flows, mange markeder, ERP/WMS): 8-16 uger

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

Shopify har sin egen URL-struktur som næsten altid afviger fra den gamle platform. Alle eksisterende URL’er til produkter, kategorier, blogindlæg og undersider bliver til 404-sider i Google, annoncer og gamle links, hvis der ikke laves redirects.

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 de vigtigste sider manuelt
7. Crawl igen
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.

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, PDF-filer, 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 altid med et subset på 10-20 produkter først. Find fejlene, juster mapping-reglerne, og kør først den fulde import når subset’et er rent.

Kategoristruktur er et strategisk valg

En migrering er ofte det bedste tidspunkt at rydde op i kategoritræet. Men det er også et risikoområde. Ændrer du kategorinavne, URL’er, intern linking og navigation samtidig, stiger risikoen markant.

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. Men kunders kodeord kan ikke migreres, fordi de er krypterede uden for Shopifys system.

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 kode sendt via e-mail. 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.

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

Jeg deler altid integrationer i tre: “must-have ved lancering”, “kan vente” og “erstattes”. Det skarpe cut tidligt i projektet forhindrer scope creep sent i projektet.

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.

Bruger du en tredjepartsudbyder til betaling i stedet for Shopify Payments, skal du også regne Shopifys tredjeparts-transaktionsgebyrer med (2 % på Basic, 1 % på Shopify, 0,6 % på Advanced).

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

SEO og tracking er ofte det første der går galt ved en migrering, og det sidste man opdager. Fordi data halter bagud, ser man typisk ikke konsekvensen før 2-4 uger efter lancering, og da er skaden sket.

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).

Shopify tillader også redigering af robots.txt via robots.txt.liquid i theme-koden - brug det kun hvis du ved præcis hvad du laver.

Overgang til den nye GA4-opsætning

GA4 kan opsættes via Shopifys Google-integration eller en anden understøttet integration. Test den konkrete opsætning i testmiljøet og igen ved lancering. Adgangskodebeskyttelse påvirker, hvad besøgende og søgemaskiner kan tilgå, men er ikke i sig selv et generelt bevis på, at alle analysehændelser er blokeret.

Min tracking cutover-model:

1. Før migrering: dokumenter nuværende events, konverteringer og UTM-standard i den gamle shop
2. Under staging: test at baseline events affyres på den nye shop (page_view, add_to_cart, begin_checkout, purchase)
3. Ved lancering: fjern password-protection og verificer real-time events samme time
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 built-in cookie banner dækker Shopify-specifikke pixels og cookies. Tredjeparts pixels (Meta, TikTok, Google Ads remarketing) kan kræve særskilt consent-logik eller en dedikeret consent-app.

Test altid: klik “afvis alle” og verificer at ingen ikke-nødvendige tags fyrer. Dette er det oftest oversete punkt i migreringer.

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.

En god migrering har altid en feed-ejer. En dårlig migrering håber at appen ordner det.

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)
• Genbesøge cookie banner - Shopifys built-in dækker kun Shopify-cookies
• 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). OSS er relevant ved salg til privatpersoner i EU over 10.000 EUR per år.

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.

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 301-redirects på top-URL’er fra din audit. Test at sitemap.xml kan hentes uden login. Test at top landing pages er indekserbare (ingen noindex på sider der skal rankes). Stikprøve-test interne links.

Test af sporing

Test at GA4 er implementeret. Valider key events: page_view, add_to_cart, begin_checkout, purchase. 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

Shopify anbefaler eksplicit at teste hele købsflowet med testordrer. Min matrix dækker altid:

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

Eksporter produkter, kunder, ordrer, redirects og anden forretningskritisk data. Gem backup og bevar adgang til den gamle løsning. Du kommer til at skulle slå noget op om nogle uger, og det skal være muligt.

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

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

Først her bliver tracking og indeksering aktivt. Hvis du glemmer det, kan GA4 ikke tracke events og Google kan ikke hente sitemap.

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

• Betaling fejler for over X% af checkouts i 30 minutter (jeg bruger typisk 10 % som tærskel)
• 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. Revert DNS til den tidligere host (forudsat at gammel shop stadig kører).
3. Kommuniker tydeligt på site og til kundeservice: “Vi oplever tekniske udfordringer og har midlertidigt skiftet tilbage.”
4. Lav efteranalyse af hvad der gik galt og hvordan det forhindres næste gang.
5. 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.

Uge 1 - tæt opfølgning

Tjek dagligt: Search Console-fejl, 404’er, Merchant Center-produkter, konverteringsflow, ordrebekræftelser, kundeservice-input, top-landing pages, real-time GA4 events og annonce-URL’er. Lav nye redirects så snart nye 404’er dukker op. Kontakt kunder der har loginproblemer proaktivt.

Uge 2-4 - stabilisering

Sammenlign konverteringsrate, AOV og traffic med baseline fra pre-migration auditen. Tjek Core Web Vitals (performance er ofte anderledes på Shopify, både godt og skidt). Gennemgå ranking-tab systematisk - er top landing pages stadig i top 10? Har du mistet featured snippets?

Efter 30 dage - retrospektiv

Lav en retrospektiv med hele teamet. Hvad kostede mere end ventet? Hvad fungerede bedre? Hvilke integrationer skal udskiftes næste gang? Dokumenter læringen. En god migrering anser ikke projektet for afsluttet ved DNS-skift - den har en plan for de første 30 dage og tid sat af til de første 90.

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.

Typiske fejl jeg ser

Starte uden komplet kortlægning

Det skaber blinde huller i redirects, feeds og indhold. Hver gang jeg har set et migreringsprojekt gå skævt, kunne det spores tilbage til noget der ikke blev kortlagt i starten.

Æ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. Den koster organisk trafik i måneder hvis den ikke bliver fanget tidligt. 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

PDF’er, størrelsesguides, gamle billeder, blogbilleder og supportfiler bliver ofte overset. De har typisk gode backlinks og må ikke ende som 404.

Undervurdere kundelogin

Kunder bliver frustrerede hvis de ikke forstår hvorfor deres gamle kodeord ikke virker. Det er ikke en teknisk fejl men en kommunikationsfejl.

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

Post-launch er en del af migreringen, ikke en ekstra service. Sæt budget og tid af til de første 30 dage efter lancering.

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 - jeg har hjulpet med nok af dem til at vide hvor det typisk går skævt.