Migrering af et eksisterende website
At migrere et eksisterende website til Framer kan føles som en ren teknisk øvelse, men i praksis handler det lige så meget om forretning: at bevare trafik, undgå tab af leads og samtidig få et site, der er hurtigere at videreudvikle. Den gode nyhed er, at Framer har et setup med staging og versionering, som gør det realistisk at skifte uden synlig nedetid for brugerne, hvis processen planlægges rigtigt.
Nedenfor får du en konkret, trinvis plan, der kan bruges uanset om du kommer fra WordPress, Webflow, et specialbygget site eller en ældre CMS-løsning.
Hvad “uden nedetid” faktisk betyder
Når folk siger “uden nedetid”, mener de typisk én af to ting: enten at websitet aldrig går helt i sort, eller at skiftet sker så kontrolleret, at brugerne reelt ikke mærker noget. Ved et domæneskift kan der stadig være DNS-propagation, men du kan minimere effekten, så risikoen for tomme sider og fejlbeskeder bliver meget lav.
Det kræver, at du kører to miljøer parallelt i en periode: dit nuværende site (live) og det nye Framer-site (staging). Skiftet bliver så et kontrolleret “cutover”, hvor du allerede har testet alt i et miljø, der ligner produktion.
Fase 0: Inventar, backup og beslutninger der sparer dig for problemer
Før du bygger noget i Framer, skal du vide præcis, hvad du flytter, og hvad du med vilje ikke flytter. Migrering er et godt tidspunkt til at rydde op i gamle landingssider, dubleret indhold og forældede integrationer, men oprydning skal være et valg, ikke et uheld.
Start med en fuld backup af nuværende site og en “site inventory”, der dokumenterer URL’er, metadata og vigtige funktioner. Et crawler-værktøj kan give dig en komplet liste over sider, titler, statuskoder og interne links, som senere bliver fundamentet for redirects og kvalitetssikring.
Lav også en integration-liste. Mange problemer efter lancering kommer ikke fra designet, men fra ting som formularer, tracking, kalender-booking eller rekrutteringsflows.
Efter du har kortlagt det hele, giver det mening at samle de vigtigste afklaringer i en kort beslutningslog:
Hvad skal bevares 1:1 (URL-struktur, indholdshierarki, metadata)?
Hvad må gerne forbedres (IA, design, komponenter, hastighed)?
Hvad er “must work” på dag 1 (formularer, tracking, cookie consent, betalingsflow)?
En praktisk plan, der er nem at styre
Når migrering bliver uoverskuelig, skyldes det ofte, at man prøver at bygge, flytte indhold, fikse SEO og skifte domæne på samme tid. Del arbejdet op i faser med klare leverancer.
Her er en tabel, der fungerer godt som styringsværktøj i både små teams og større organisationer:
Fase | Mål | Typiske leverancer | Risiko der fjernes |
|---|---|---|---|
0. Audit og backup | Få komplet overblik | URL-liste, metadata-export, backup, integrationsliste | Mistet indhold og glemte sider |
1. Staging i Framer | Byg nyt site uden at påvirke live | Framer-projekt, grundlæggende struktur, versions | Ustabil lancering og “live-byggeri” |
2. Designsystem og komponenter | Gør byggeprocessen skalerbar | Tokens, komponentbibliotek, sektioner | Uens design og dyre ændringer |
3. Indhold og CMS | Flyt og valider indhold | CMS collections, import, mediebibliotek | Tomme sider, brudte elementer |
4. SEO og redirects | Beskyt ranking og trafik | Redirect-map, sitemap, metadata-tjek | 404-fejl og trafiktab |
5. Cutover | Skift domæne kontrolleret | TTL-plan, domæneoverførsel, deploy | Nedetid og fejl i kritiske timer |
6. Overvågning | Fang fejl hurtigt | Search Console tjek, analytics, fejlrapporter | Skjulte problemer der vokser |
Fase 1: Opsæt et Framer staging-miljø, før du flytter noget
Framer gør det muligt at arbejde med staging og versioner, hvor du kan publicere en testversion uden at røre dit rigtige domæne. Det er et af de vigtigste greb for at undgå nedetid, fordi du kan teste et næsten færdigt site i ro og mag.
I praksis betyder det:
Du opretter et Framer-projekt, publicerer det til Framer-preview (eller et midlertidigt domæne), og inviterer interne interessenter til at teste. Først når alt er godkendt, flytter du det rigtige domæne over.
Hvis du kommer fra et site med mange eksisterende sektioner, kan et værktøj der kopierer HTML-sektioner ind i Framer spare tid, men det er sjældent nok alene. De sektioner, der er forretningskritiske, bør som regel bygges “native” i Framer, så de bliver nemme at vedligeholde.
Fase 2: Byg et lille designsystem, før du bygger alle sider
Et migrationsteam bliver hurtigt fristet til at bygge side for side. Det føles effektivt i starten, men bliver dyrt, når der kommer ændringer: ny knapstil, justeret spacing, opdateret typografi eller en ændring i kort-komponenter på tværs af sitet.
Derfor: brug tid tidligt på komponenter og enkle designregler. I Framer kan du arbejde med genbrugelige komponenter, farver, typografi og spacing, så ændringer slår igennem konsekvent.
Et lille, praktisk minimum kunne være:
Header og footer
Navigationskomponent
Hero-sektioner i 2 til 3 varianter
CTA-moduler
Cards, logo-wall, testimonial-modul
Formularblokke og succes-fejl states
Den tilgang er også typisk i studios, der arbejder med designsystemer og hurtig prototyping, fordi den gør både levering og senere drift mere forudsigelig.
Fase 3: Indholdsoverførsel, CMS og redaktørflow
Når strukturen er på plads, kan du flytte indhold. Hvis du kommer fra WordPress eller et andet CMS, handler det sjældent om “at flytte alt”. Det handler om at flytte det rigtige, med samme betydning og samme URL-intention.
Planlæg indholdsoverførslen som en kombination af import og manuel kvalitetssikring:
Statisk indhold: Sider som “Om”, “Kontakt”, “Priser” kan flyttes og finpudses manuelt.
Dynamisk indhold: Blog, cases, karrieresider og events bør lægges i Framer CMS collections, så redaktører kan arbejde uden at røre layoutet.
Medier: Billeder og video skal tjekkes for størrelse, komprimering og alt-tekster.
Når du tester, så test som en bruger. Klik rundt, udfyld formularer, tjek kvitteringer, og bekræft at data lander det rigtige sted.
Fase 4: SEO der overlever skiftet
SEO er sjældent “magi”. Det er ofte helt konkrete ting: URL’er, redirects, titler, beskrivelser, headings, interne links og statuskoder.
Den vigtigste leverance i denne fase er en redirect-map, hvor du matcher gammel URL til ny URL. Hvis du kan bevare URL-strukturen, bliver arbejdet mindre, men det er ikke altid muligt eller ønskeligt. Hvis du ændrer, skal du være konsekvent.
Efter du har lavet redirect-planen, skal du sikre:
Title tags og meta descriptions er med (eller forbedret bevidst)
Canonicals giver mening
Sitemap findes og er korrekt
404-sider er designet og hjælpsomme
Tracking og Search Console er klar fra dag 1
En lille detalje, der ofte glemmes: interne links. Hvis din navigation, footer og gamle blogartikler linker til gamle URL’er, kan du skabe unødvendige redirect-kæder. Det er bedre at opdatere links direkte til de nye adresser.
Fase 5: Domæneskift med minimal risiko
Når staging-versionen er godkendt, og redirect-planen er klar, planlægger du cutover. Her er målet ikke at “være modig”. Målet er at være kedelig og kontrolleret.
Først sænker du TTL på DNS-poster nogle timer før skiftet, så ændringer slår hurtigere igennem. Selve skiftet afhænger af, hvor du kommer fra:
Flyt mellem Framer-projekter: Domænet kan typisk flyttes i Framer uden DNS-ændringer, ved at fjerne domænet fra det gamle projekt og tilføje det til det nye.
Flyt fra ekstern hosting: Du opdaterer DNS til Framers anbefalede records (A-records og CNAME for www).
Når domænet peger rigtigt, deployer du den version, du allerede har testet. Og vigtigt: Framer versionering gør det muligt at rulle tilbage, hvis du opdager noget kritisk.
En kort “go-live” tjekliste, der fungerer i praksis, kan se sådan ud:
DNS og certifikat: Domæne peger korrekt, HTTPS virker
Redirects: Stikprøver på de vigtigste gamle URL’er
Tracking: Analytics events og conversions registreres
Kontaktpunkter: Formularer, booking og e-mail flows virker
Performance: Forsiden og top landingssider er hurtige på mobil
Fase 6: Overvågning de første 48 timer
Efter cutover skal du holde øje med signaler, ikke mavefornemmelser. Tjek Search Console for crawl-fejl og 404’er, og sammenlign trafikken i analytics med samme periode ugen før, så du ser afvigelser tidligt.
Det er normalt med små udsving, mens søgemaskiner genindlæser sider. Det er ikke normalt, hvis vigtige landingssider falder ud, eller hvis formularer stopper med at sende. Det er præcis derfor, staging, redirect-map og tests skal ligge før cutover.
Typiske faldgruber og hvordan de undgås
De fleste migrationer går galt på de samme 5 til 6 punkter. Det er ikke fordi teams er udygtige, men fordi de undervurderer, hvor mange små afhængigheder et website har.
Her er en kort risikoliste, som er god at bruge i kick-off:
Brudte URL’er: Manglende redirects eller forkert mapping
Mistet tracking: GA, pixels og events bliver ikke genskabt korrekt
Glemt indhold: PDF’er, billeder, gamle kampagnesider
Uens design: Manglende komponenter giver visuel støj
Formularfejl: Data lander ikke i CRM eller mailkasser
For sen QA: Mobilvisning og browserfejl opdages først efter launch
Hvis du kun gør én ting for at reducere risiko: lav en URL-inventarliste tidligt og brug den aktivt i QA. Den liste bliver din røde tråd.
Når migrering også er en måde at arbejde hurtigere på bagefter
En del virksomheder flytter til Framer for at få et site, der er nemmere at vedligeholde uden et langt udviklingsloop. Det kræver dog, at sitet er bygget med drift for øje: komponenter, klare CMS-strukturer og en opsætning, hvor marketing kan redigere sikkert.
Det er også her, mange vælger en samarbejdsmodel med løbende designkapacitet, så ændringer, kampagner og nye landingssider kan produceres i et stabilt flow, uden at alt bliver et nyt projekt hver gang.
Hvis du planlægger migreringen som en serie små leverancer, kan du også nå en “phase launch”, hvor du går live med de vigtigste sider først og udbygger resten i korte sprint, mens dit gamle site stadig kan fungere som reference i baggrunden. Det giver ro i maven og bedre kvalitet.
