Spørger du en merchant på Adobe Commerce, hvad platformen koster, får du som regel licensprisen. Spørger du deres CFO, får du et andet og større tal. Spørger du dem, der driver webshoppen til daglig, får du et tredje svar: "Et team af udviklere på fuld tid - for altid." Lyder det bekendt? Så læs videre.
Det kan måske lyde som et angreb på Adobe Commerce/Magento - og det er det også (beklager). Når det er sagt, hjælper vi virksomheder uanset teknologi, også Magento! Men husk, at teknologi blot er et værktøj, der skal understøtte virksomhedens mål. Netop derfor er det ærgerligt at se virksomheder bruge så mange penge på blot at holde en Adobe Commerce/Magento-shop kørende. Penge, der enten kunne spares og bruges på andre initiativer, der understøtter forretningen, eller bruges på at udvikle nye funktioner.
Denne artikel sætter fokus på netop det.
Den samlede TCO, som ingen regner med
Adobe offentliggør ikke listepriser, men priser fra implementeringspartnere og indkøbsdata tegner et forholdsvis ensartet billede. Licenser ligger på cirka $22.000-$125.000+ om året for on-premise-udgaven og $40.000-$190.000+ for Adobe Commerce on Cloud, afhængigt af GMV. Og licensen udgør typisk kun 20-40 % af det, en merchant faktisk bruger. En ofte anvendt tommelfingerregel på tværs af bureauer er, at de samlede ejeromkostninger (TCO) ender på to til tre gange licensprisen, når hosting, extensions, udvikling og vedligeholdelse regnes med. Det betyder, at de fleste mellemstore webshops ligger et sted mellem $122.000 og $450.000+ om året.
Hvor bliver resten af pengene af? Opdelt ser et typisk Adobe Commerce-budget sådan ud:
Tallene er samlet fra offentliggjorte benchmarks for 2026 fra Bemeir, Elogic, Swell, Folio3 og MGT Commerce. De enkelte webshops kan variere betydeligt.
Der er især to ting, der skiller sig ud.
For det første er licensen den mindste post. Merchants, der sammenligner platforme udelukkende på licensprisen, sammenligner altså det forkerte tal.
For det andet - og endnu vigtigere - er den største enkeltstående udgift mennesker. Udviklingsaftalen, vedligeholdelsen af integrationer, vedligeholdelsen af custom-kode og opgraderingscyklussen. Det er her, pengene bliver brugt, og det er værd at spørge, hvad man egentlig får for dem.
Den reelle omkostning er roadmapet
Her er det mønster, vi gentagne gange ser, når vi sætter os ned med merchants, der bruger Adobe Commerce:
Der er et team - internt, et bureau eller begge dele. De er kompetente. De har travlt. De installerer en sikkerhedsopdatering, løser den checkout-fejl, der opstod efter den seneste opgradering, genopbygger ERP-integrationen, fordi leverandøren har ændret sin autentificeringsmodel, og bruger tre uger på at få webshoppen gennem en mindre versionsopgradering.
Så kommer marketing med et ønske om et nyt B2B-tilbudsflow, en ordentlig søgeoplevelse eller kundespecifikke priser, som salg har lovet i to år. Og svaret er: næste kvartal. Og derefter kvartalet efter.
Teamet underperformer ikke. Platformen optager deres tid. Hver time, der bruges på at holde Adobe Commerce kørende, er en time, der ikke bruges på at gøre forretningen mere konkurrencedygtig. Resultatet er et sekscifret udviklingsbudget for en webshop, der stort set ser ud og fungerer, som den gjorde for tre år siden.
Det er den reelle TCO: høje omkostninger og lav udviklingshastighed. Enterprise-budget for at stå stille. Det er på sin vis ret ærgerligt.
Så hvorfor skifter merchants ikke?
Hvis en moderne composable stack kan levere den samme eller bedre funktionalitet til en brøkdel af driftsomkostningerne - og det kan den i mange tilfælde - hvorfor er det så svært at komme videre? I vores samtaler handler det typisk om fire indvendinger. De er alle legitime. Ingen af dem er nødvendigvis en grund til at blive.
Men lad os være fair. Det er ikke en nem beslutning at skifte platform.
1. "Bedre den djævel, du kender."
Du kender din nuværende platforms problemer. Du ved, hvilke extensions der konflikter med hinanden, hvilken opgradering der kommer til at gøre ondt, og hvilken udvikler du skal ringe til klokken 2 om natten. En ny platform er et blankt stykke papir, og blanke stykker papir kan være skræmmende.
Men at kende problemerne er ikke det samme som at være fri for problemer. Den kendte djævel er stadig en djævel, og du betaler ham godt. Den rigtige måde at reducere usikkerheden på er ikke at undgå den, men at gøre den mindre: Lav et afgrænset proof of concept med jeres rigtige produktkatalog og integrationer, før nogen underskriver en aftale om at skifte platform.
2. "Ny teknologi, nyt projekt, ny risiko."
Replatforming har et ry, der er opbygget gennem to årtiers ERP- og commerce-projekter, der er løbet over tid og budget. Merchants husker migreringen fra Magento 1 til Magento 2, som ofte var mere smertefuld end den oprindelige implementering.
Det ærlige svar er, at risikoen er reel, og at risikobilledet har ændret sig. Moderne commerce-platforme er API-first og modulære, hvilket betyder, at en migration ikke behøver at være et stort skift på én gang. I kan flytte storefronten, mens backenden bevares, eller flytte kurv og checkout, mens produktkataloget bliver, hvor det er. Hvert trin kan testes, rulles tilbage og skabe værdi uafhængigt af de andre. Risikoen forsvinder ikke - den bliver opdelt i mindre dele, der er nemmere at håndtere.
3. "Jeg har ikke tid til at køre endnu et projekt."
Det er som regel den mest ærlige indvending. Commerce-teamet er allerede presset af at holde den nuværende platform kørende. Tanken om at lægge en migration oveni er udmattende bare at tænke på.
Men læg mærke til cirkulariteten: Teamet har ikke tid på grund af platformen. Migrationen er det, der giver tiden tilbage. Og det er ikke nødvendigt, at merchantens team driver projektet. Den rigtige partner tager sig af projektledelse, arkitektur og udvikling og involverer merchantens team dér, hvor deres viden er vigtigst - i kravspecifikation, test og godkendelse, ikke i sprintplanlægning.
4. "Jeg kan ikke få budget til et nyt projekt."
Budget er den indvending, der lyder økonomisk, men i virkeligheden er strukturel. De nuværende omkostninger er fordelt på licens, hosting, bureauaftale, værktøjer og interne ressourcer - ofte på tre eller fire forskellige budgetposter, som ingen lægger sammen. En replatforming fremstår derimod som ét nyt samlet beløb, der skal godkendes. Den gamle omkostning er usynlig; den nye er meget synlig.
Løsningen er også at gøre de nuværende omkostninger synlige. Beregn den reelle TCO - alle poster og over en treårig periode - og sæt den op mod de forventede driftsomkostninger ved alternativet. I de fleste tilfælde tjener migrationen sig selv hjem gennem besparelserne inden for de første 18-30 måneder, og business casen bliver tydelig. Spørgsmålet går fra "Har vi råd til at skifte?" til "Har vi råd til at fortsætte med at betale det her?"
Transformér - genopbyg ikke bare
Vi arbejder ikke med at flytte merchants fra én tung platform til en anden. Det ville blot nulstille uret på det samme problem.
Pointen med at forlade Adobe Commerce er ikke at køre den samme webshop et billigere sted. Det handler om at frigøre det udviklingsbudget, der i dag bruges på vedligeholdelse, og i stedet bruge det på det, der rent faktisk skaber vækst i omsætningen: bedre søgning og produktopdagelse, conversational og agentic commerce, B2B-workflows, der matcher den måde jeres kunder faktisk køber på, og en stack, der gør det muligt at tilføje funktionalitet på uger i stedet for kvartaler.
Eller måske bare spare penge på de grundlæggende ting - som jeres e-commerce-løsning, der egentlig bare skal understøtte forretningen, men som nu nærmest er forretningen. Og det er netop derfor, det er vigtigt at se på jeres TCO.
