Det nedarvede site: håndtér teknisk gæld fra det forrige bureau

Kort svar: Overtag aldrig ansvaret for et nedarvet site, før du har kortlagt det. Sortér derefter den tekniske gæld i tre bøtter: kritisk (sikkerhedshuller, manglende backup, udløbne licenser – løses nu i en afgrænset stabiliseringsfase), snart (opdateringsefterslæb, langsomme sider – planlægges over de næste måneder) og lad ligge (grimt, men harmløst – røres kun, hvis kunden betaler for det). Og tal aldrig grimt om det forrige bureau.

Fagligt gennemgået: 2. oktober 2026

Før eller siden lander det på dit bord: et site bygget af “dem før os” – 42 plugins, et child-tema med tusindvis af linjer hjemmestrikket kode, ingen dokumentation og en kunde, der bare gerne vil have, at det virker.

Det nedarvede site er både en risiko, fordi du arver ansvaret for andres beslutninger, og en mulighed, fordi kunden allerede har valgt dig. Her er processen, der gør overtagelsen rentabel i stedet for et velgørenhedsprojekt.

1. Kortlægningen før ansvaret

Kør hele tjeklisten fra onboarding af nyt kundesite – adgange, ejerskab, backup og versioner – og grav så et spadestik dybere, fordi sitet er nedarvet:

• Hvor kommer temaet fra, og opdateres det stadig?
• Hvilke plugins er forladte og har ikke fået opdateringer i lang tid?
• Ligger der kode i temaet, som burde være et plugin?
• Er der licenser bundet til det gamle bureaus konti, som stopper ved skiftet?
• Findes der udokumenterede specialløsninger – formularer, integrationer, cron-jobs?

Skriv det hele ned med skærmbilleder. Dokumentet er både din arbejdsplan og dit bevis for, hvordan sitet så ud, før du tog over. Den skelnen bliver vigtig, hvis noget går i stykker i uge to.

2. Kortlæg teknisk med WP-CLI

Har du SSH-adgang, giver WP-CLI et hurtigt og objektivt billede. Kommandoerne ændrer ikke noget på sitet:

# Er WordPress-kernens filer uændrede?
wp core verify-checksums

# Plugins med versioner og tilgængelige opdateringer
wp plugin list --fields=name,status,version,update

# Hvem har administratoradgang?
wp user list --role=administrator --fields=user_login,user_email,user_registered

# Planlagte opgaver – her gemmer udokumenterede integrationer sig ofte
wp cron event list

# Kører sitet på en understøttet PHP-version?
wp --info

Fejler verify-checksums, er kernefiler ændret eller tilføjet – det kan være gammel tilpasning, men også et tegn på kompromittering. Ukendte administratorer og mærkelige cron-hændelser hører direkte i “kritisk”-bøtten. Kører sitet på en forældet PHP-version, skal opgraderingen til PHP 8.3 eller 8.4 planlægges – efter test på staging, jf. fejl efter PHP-opgradering.

3. Triagen: kritisk, snart, lad ligge

Bøtte	Eksempler	Hvornår
Kritisk	Manglende eller utestet backup, kendte sårbarheder i plugins eller kerne, udløbende licenser, fremmede administratoradgange, alt der rører betalinger	Før eller i første uge
Snart	Opdateringsefterslæb, langsomme sider, rod i brugerroller, manglende overvågning	Første kvartal, planlagt
Lad ligge	Grim kode, der virker; forladte, men harmløse plugins; navngivning, du ikke bryder dig om	Kun hvis kunden betaler for det

Prioritér teknisk gæld som økonomisk gæld: dyr rente først – og noget gæld er så billig, at den aldrig skal indfries. Perfektionisme på kundens regning er ikke grundighed; det er dårlig rådgivning.

4. Prissæt oprydningen rigtigt

Sælg overtagelsen i to dele: først en stabiliseringsfase med aftalt omfang og samlet pris – kortlægning, hele “kritisk”-bøtten og ordentlig hosting med testet backup – og derefter den løbende vedligeholdelsesaftale. Aldrig omvendt, og aldrig “vi tager det hen ad vejen”: uden en klar ramme bliver du enten den, der fakturerer overraskelser, eller bureauet, der rydder op gratis.

“Snart”-bøtten prissættes som små projekter i driftens anbefalinger – ét ad gangen, jf. månedsrapporten. Flyt også sitet over på din egen standardplatform som del af stabiliseringen: du kan ikke stå inde for driften på en ukendt server, du ikke har nøglerne til.

5. Stabiliseringsfasen i praksis

En typisk stabilisering kan lægges i denne rækkefølge, så de største risici lukkes først:

1. Sikr en gendannelig backup af filer og database, og test den på et separat miljø, før du ændrer noget.
2. Luk fremmede adgange: fjern ukendte administratorer, skift adgangskoder til WordPress, hosting, database og SFTP, og forny saltnøglerne i wp-config.php (med WP-CLI: wp config shuffle-salts), så gamle login-cookies ugyldiggøres.
3. Opdatér det sårbare: kerne og plugins med kendte sårbarheder – på staging først, hvis sitet er forretningskritisk.
4. Flyt til din platform, så backup, staging og adgang følger din standard, jf. flyt et kundesite uden nedetid.
5. Sæt overvågning og dokumentation op: oppetid, opdateringer og en driftsside, der beskriver sitets særheder.

Først når de fem punkter er på plads, går sitet over i almindelig drift. Kommer der fund undervejs, som ligger uden for den aftalte ramme, så stop op og aftal dem særskilt – det er netop dét, der holder stabiliseringen afgrænset.

6. Aftal ansvarsfordelingen skriftligt

Lav en kort overtagelsesaftale, før du rører noget. Den skal beskrive, hvornår ansvaret går over til dig, hvilke kendte fejl og risici der er konstateret ved overtagelsen, og hvad stabiliseringsfasen dækker – og ikke dækker.

Send kortlægningens hovedpunkter til kunden – “sådan ser sitet ud i dag, her er de tre vigtigste risici” – og bed om et kort skriftligt ok, før stabiliseringen går i gang. Den mail gør to ting: kunden forstår, hvad de har købt, og ingen kan senere påstå, at problemerne opstod på din vagt.

7. Renovér eller byg nyt?

Tommelfingerreglen: overstiger oprydningen omkring halvdelen af prisen for at bygge sitet ordentligt op fra din standardopsætning, så anbefal nybyg – med det gamle site kørende urørt imens.

• Renovering vælges, når fundamentet er sundt – opdateret tema, fornuftig struktur – og gælden ligger i kanterne.
• Nybyg vælges, når gælden ligger i fundamentet: forladt sidebygger, et tema der ikke tåler PHP-opdateringer, eller en sikkerhedsmæssigt uholdbar opbygning.

Sig det ærligt og med tal. Kunden har lige forladt ét bureau og opdager hurtigt, hvis en nybyg-anbefaling mest handler om din omsætning.

8. Om forgængeren: kun professionelt

Uanset hvad du finder: omtal forgængeren neutralt. “Det var en almindelig måde at gøre det på dengang” og “jeg ville vælge en anden løsning i dag” siger alt – uden at gøre kunden dum, for de valgte jo selv bureauet.

Husk også spejlet: en dag er du forgængeren, og så høster du gevinsten af en ordentlig offboarding og et godt eftermæle. Bureauer, der taler pænt om hinanden, får også flere henvisninger fra hinanden – branchen er mindre, end den ser ud.

Læs også

• Hub: For bureauer og freelancere
• Onboarding af nyt kundesite
• Din standardopsætning
• Offboarding: sådan afleverer du et kundesite ordentligt
• WP-CLI for begyndere
• Bureau hosting til WordPress og WooCommerce – én platform til de overtagne sites

Ofte stillede spørgsmål om nedarvede sites

Hvad skal jeg tjekke først på et overtaget site?

Backup (findes den, og virker den?), kendte sårbarheder, fremmede administratoradgange, licenser bundet til det gamle bureau og alt, der rører betalinger. Det er “kritisk”-bøtten.

Skal al teknisk gæld ryddes op?

Nej. Prioritér som økonomisk gæld: dyr rente først. Grim, men harmløs kode må gerne blive liggende – oprydning for æstetikkens skyld er dårlig rådgivning på kundens regning.

Hvornår er nybyg bedre end renovering?

Når oprydningen koster mere end cirka halvdelen af et nybyg fra din standardopsætning, eller når gælden sidder i fundamentet: forladt sidebygger, et tema der ikke tåler opdateringer, eller uholdbar sikkerhed.

Hvordan beviser jeg, at fejlene fandtes, før jeg overtog sitet?

Dokumentér kortlægningen med skærmbilleder og output fra fx WP-CLI, send hovedpunkterne til kunden, og få et skriftligt ok, før du ændrer noget. Så er udgangspunktet aftalt.