For å ha reell kontroll på nettsiden trenger bedriften avklarte rettigheter, egne tilganger og et oppsett en annen leverandør kan overta. Domenet, innholdet, koden og tjenestene rundt nettstedet må vurderes hver for seg. En innlogging eller en mappe med filer svarer ikke på hele spørsmålet om hvem som eier nettsiden.
Dette er nyttig både før dere bestiller en ny nettside og når dere vurderer å bytte nettsideleverandør. Målet er å kunne fortsette driften, få hjelp av andre og forstå hva et bytte vil kreve. Dere trenger ikke drifte alt selv for å ha kontroll, men ansvaret og veien videre må være tydelig.
Skill mellom tilgang, rettigheter og praktisk overtakelse
En administrator kan kanskje redigere siden, men mangler tilgang til domenet eller sikkerhetskopien. Bedriften kan ha avtalt bruksrett til designet, men mangler filene som trengs for å endre det. Koden kan ligge i et arkiv dere kontrollerer, mens kontaktskjemaet fortsatt bruker en tjenestekonto hos den gamle leverandøren. Derfor bør dere stille tre ulike spørsmål:
- Hva kan vi gjøre? Få skriftlig avklart bruk, endring, videreutvikling og overføring til en ny leverandør.
- Hva har vi tilgang til? Kontroller kontoer, kontaktopplysninger, fakturering og muligheten til å gjenopprette tilgang.
- Hva kan andre faktisk overta? Be om filer, data, dokumentasjon og en kontrollert demonstrasjon av at løsningen fungerer i et nytt miljø.
Et godt samarbeid tåler disse spørsmålene. En overtakelse kan kreve betalt arbeid selv om rettigheter og tilganger er avklart. Be om omfang, prisgrunnlag, oppsigelsesfrist og hvem som bistår. Da blir leverandørbytte en planlagt oppgave fremfor en diskusjon først når samarbeidet avsluttes.
Begynn med domenet og kontoene som holder bedriften i gang
For norske .no-domener er registreringen en bruksrett gjennom et abonnement. Kontroller at riktig virksomhet står som abonnent, og at kontaktopplysningene er oppdatert. Bytte av domeneforhandler er noe annet enn bytte av abonnent. Norids regelverk beskriver disse forskjellene.
Dere kan beholde .no-domenet ved bytte av forhandler. Norid beskriver flyttekode og engangskode som to alternativer; engangskoden sendes til e-postadressen registrert på abonnementet. Se fremgangsmåten hos Norid. En slik flytting flytter ikke automatisk nettsidens filer eller bedriftens e-post.
Be om en oversikt over DNS, altså oppføringene som styrer hvor domenet sender besøkende og e-post. Ved bytte av navnetjenere må også e-postoppsett og bekreftelser for tilkoblede tjenester tas med. En nettside som virker, er ikke bevis på at e-posten fortsatt kommer frem.
La bedriften kontrollere nødvendige administratortilganger og gjenoppretting der plattformen støtter det. Bruk navngitte brukere, passende roller og flerfaktorautentisering. Ha en avtalt reserve hvis hovedkontakten slutter eller mister telefonen. Der leverandøren bruker en delt konto for flere kunder, må dere avklare hvilken eksport eller ny konto som erstatter deres del. Hele leverandørkontoen kan ikke bare inngå i overtakelsen.
Lag én oversikt over det som skal overtas
Bruk denne oversikten i et møte med leverandøren. For hver rad bør dere notere ansvarlig person, hvor dokumentasjonen ligger, hva som mangler og når det skal avklares. Ikke skriv passord eller hemmelige nøkler i et vanlig prosjektdokument.
| Del | Hva dere bør ha kontroll på | Bevis ved overtakelse |
|---|---|---|
| Domene og DNS | Abonnent, fornyelse, kontaktpunkt og oppføringer for nettside og e-post. | Bekreftet tilgang og en datert kopi av oppsettet. |
| Innhold og rettigheter | Tekst, bilder, designfiler, fonter og vilkår for videre bruk. | Avtale, lisensoversikt og avtalte originalfiler. |
| Kode og publisering | Kodearkiv, versjoner, bygging og hvordan endringer settes i drift. | En ny utvikler kan bygge og publisere en testversjon. |
| Data og medier | Database, opplastinger, innholdsfelter og nødvendige koblinger mellom data. | Eksport som er kontrollert og lest inn i testmiljøet. |
| Tjenester og betaling | Innlogging, skjema, e-post, betaling, analyse og integrasjoner. | Avklart konto, fakturamottaker og ansvar for hver tjeneste. |
| Drift og gjenoppretting | Sikkerhetskopi, overvåking, oppdateringer og håndtering av feil. | Testet gjenoppretting og navngitt ansvarlig etter byttet. |
På små skjermer kan du rulle tabellen sidelengs.
Avklar bruksrett, lisenser og kostnader før dere bytter
Be avtalen beskrive hva som leveres spesielt til dere, og hva som bygger på eksisterende programvare, maler eller tredjepartsinnhold. Be også om en konkret avklaring av om dere kan la en annen leverandør endre og videreutvikle materialet. En generell formulering om at «kunden eier nettsiden» er et dårlig arbeidsgrunnlag hvis ingen har beskrevet delene.
Gå gjennom bilder, fonter, temaer, utvidelser og abonnementer hver for seg. Hvem har kjøpt lisensen? Hvilken bruk er avtalt? Kan ordningen videreføres ved et bytte, eller trenger dere en egen lisens? Avklar også oppdateringer og support. Et bilde som ligger offentlig på nettsiden, er ikke i seg selv dokumentasjon på bruksretten.
Dette er spørsmål som skal avklares i den konkrete avtalen og de aktuelle lisensvilkårene. Ved uenighet om rettigheter bør avtalen vurderes juridisk før materiale overføres eller endres. Guiden avgjør ikke hvem som eier kode eller design i et bestemt kundeforhold.
Ta også med overtakelse når dere beregner hva nettsiden koster over tid. Kostnadsguiden viser et fiktivt treårsbudsjett og hvordan endrede forutsetninger påvirker sammenligningen.
Hva må følge med fra WordPress, Astro eller Lovable?
Teknologivalget avgjør hvilke deler som må kartlegges. Egen kode gir muligheter til å forme løsningen, men det er dokumentasjonen og den faktiske overtakelsen som viser hvor lett andre kan fortsette. Les hvorfor vi bygger mer med Astro og AI for bakgrunnen for arbeidsmåten vår.
WordPress: innholdseksport og full sikkerhetskopi er ulike ting
«Verktøy → Eksporter» lager en XML-fil med innhold som innlegg, sider og kategorier, ifølge WordPress-dokumentasjonen. Den bør ikke behandles som en full kopi av nettstedet. For en komplett overtakelse må dere også kartlegge database, opplastede filer, temaer, utvidelser og oppsett. WordPress’ veiledning om sikkerhetskopi skiller mellom databasen og filene. Kontroller at kopien faktisk kan gjenopprettes.
Astro og egen kode: gjør bygging og drift forståelig for neste utvikler
Be om kodearkivet med endringshistorikk, nødvendige versjoner, innholdskilder og en kort oppskrift for å bygge, teste og publisere. Dokumentasjonen bør forklare hvilke tjenester som må være tilgjengelige og hvor hemmelige nøkler settes inn sikkert. En kopi av de ferdige nettsidefilene kan vise dagens side, men er ikke nødvendigvis nok til å videreutvikle den.
GitHub støtter overføring av kodearkiv, med bestemte krav til tilganger og mottaker. Eksisterende samarbeidspartnere og enkelte integrasjoner kan følge med, så tilgangene må gjennomgås etterpå. GitHubs dokumentasjon beskriver hva som overføres. Hosting, eksterne databaser og fakturering må fortsatt avklares for seg.
Lovable: kodeeksport må følges av data og tilkoblede tjenester
Lovable dokumenterer at kode kan eksporteres og kjøres utenfor plattformen. Kodeeksporten inneholder ikke databasen og opplastede filer; disse må håndteres separat. Ved full flytting må også innlogging, lagring og andre tilkoblede tjenester kartlegges og eventuelt erstattes. Se Lovables dokumentasjon om eierskap og flytting. Be om en test av akkurat deres løsning før dere avslutter tjenestene den bruker.
Et fiktivt eksempel: Koden er levert, men skjemaet virker ikke
Tenk deg en bedrift i Vestfold som bytter leverandør. Den får et kodearkiv og beskjed om at alt er overlevert. Den nye utvikleren får forsiden til å vises, men produktinformasjonen mangler, og forespørslene kommer ikke frem. Eksemplet er fiktivt og beskriver ingen bestemt kunde.
Gjennomgangen viser at produktdata lå i en separat database, bildene i en lagringstjeneste og e-postutsendingen på leverandørens konto. Det mangler også en beskrivelse av hvilken programvareversjon prosjektet trenger. Koden er en del av leveransen, men forutsetningene for å bruke den er ufullstendige.
Løsningen er å avtale eksport av data og bilder, opprette eller overføre nødvendige tjenestetilganger og dokumentere byggingen. Deretter kontrolleres det at et produkt vises riktig, og at en avtalt testhenvendelse når riktig mottaker. Først da har bedriften et konkret grunnlag for å godkjenne denne delen av overtakelsen.
Slik planlegger dere overtakelsen uten å miste oversikten
- Kartlegg før dere sier opp. Samle avtaler, kontooversikt og dokumentasjon. Avklar hva som blir værende, hva som flyttes, frister og kostnader. Ta en kontrollert sikkerhetskopi før endringer.
- Fordel ansvaret. Navngi én kontakt hos bedriften og hos hver leverandør. Avtal hvem som flytter data, endrer DNS, tester e-post og godkjenner byttet. Planlegg når gammelt og nytt oppsett må virke samtidig.
- Test i et skjermet miljø. La den nye leverandøren bygge eller gjenopprette løsningen fra materialet dere har mottatt. Kontroller redigering, mobil, skjemaer, innlogging og aktuelle integrasjoner. Bruk testbetaling og testdata der det er mulig.
- Avtal siste overføring og tilbakeføring. For en nettbutikk eller portal må nye bestillinger og registreringer etter første eksport håndteres. Bestem tidspunkt, eventuell kort endringspause og hvordan feil kan rettes uten å miste nye data.
- Kontroller og avslutt. Sjekk nettside, e-post, adresser og avtalte funksjoner etter byttet. Bekreft driftsansvar og sikkerhetskopi før gammel drift avvikles. Fjern gamle tilganger og bytt nøkler som tidligere leverandør ikke lenger skal bruke.
Bevar nyttige nettadresser når dere kan, og planlegg relevante omdirigeringer dersom adresser endres. Registrer et målegrunnlag før byttet og følg med på feil etterpå. SEO-guiden om synlighet og måling og guiden om ny nettside går nærmere inn på innhold, lanseringskontroll og måling.
Personopplysninger trenger en egen plan
Avklar hvem som får tilgang til kundeopplysninger under flyttingen, og bruk en sikker overføringsmåte. Når en leverandør behandler personopplysninger på bedriftens vegne, må forholdet reguleres i en databehandleravtale. Ved avslutning skal avtalen regulere tilbakelevering eller sletting og håndtering av kopier. Veiledningen fra Datatilsynet forklarer kravene. Avklar også eventuelle lovpålagte lagringsplikter og hvordan sikkerhetskopier håndteres.
En avtalt kopi til gjenoppretting bør ha et formål, begrenset tilgang og en avklart levetid. Et leverandørbytte er ikke en grunn til å beholde personopplysninger uten tidsgrense. Les også guiden om sikkerhet i AI-bygde nettsider for kontroll av tilganger, data og ansvar.
Be leverandøren om en konkret overtakelsesplan
Dere kan bruke denne listen som grunnlag for en forespørsel og tilpasse den til avtalen deres:
- Beskriv hvilke deler av nettstedet vi har avtalt rett til å bruke, endre og la andre videreutvikle.
- Vis hvem som kontrollerer domenet, kontoene og faktureringen, og hva som må overføres eller opprettes på nytt.
- Lever en oversikt over kode, innhold, data, medier, lisenser og tilkoblede tjenester som trengs for videre drift.
- Beskriv hvordan en ny leverandør kan bygge, publisere og gjenopprette løsningen, og hvordan dette kan testes.
- Oppgi arbeid, kostnader og frister ved overtakelse, inkludert siste dataoverføring, tilbakeføring ved feil og avslutning av tilganger.
Hvis leverandøren ikke svarer, begynn med avtalen, fakturaene og kontoene bedriften allerede kontrollerer. Be om en skriftlig avklaring av det som mangler, og dokumenter henvendelsene. Plattformenes offisielle støtte- og gjenopprettingsrutiner kan være neste steg for kontoer dere kan dokumentere rett til. Uenighet om utlevering eller rettigheter bør avklares før noen forsøker å endre eierskap eller stenge tilganger.
Hos Færder Marketing kan vi begynne med en gjennomgang av dagens nettsted og det som faktisk er tilgjengelig. Da kan vi vurdere hva som kan videreføres, hva som må avklares med dagens leverandør, og om dere trenger flytting, forbedring eller en ny løsning. Les om arbeidet vårt med nettsider og videreutvikling, eller fortell oss hva dere ønsker å overta. Send gjerne nettsideadressen og en beskrivelse av situasjonen; passord og kundedata hører ikke hjemme i kontaktskjemaet.
