Van Shopware-partner wisselen zonder downtime of technische verrassingen

Je bent niet gelukkig met je huidige Shopware-partner. Updates duren te lang, bugs blijven liggen en een roadmap ontbreekt. Toch blijf je, want overstappen voelt riskanter dan blijven. "Niemand anders kent deze code." Het is misschien de meest gehoorde reden waarom merchants blijven bij een partner waar ze eigenlijk niet meer tevreden over zijn.

Dat is een echte angst, en hij is ook echt niet onverwacht. Je live shop is je omzet en de hartslag van je onderneming. Je geeft de sleutels niet graag door aan iemand die de codebase nog nooit gezien heeft.

Elke overname start bij ons met een gratis technische audit. Pas als we exact weten hoe je Shopware-project ervoor staat, beslissen we samen hoe we verdergaan.

Wij hebben al verschillende Shopware-shops overgenomen van andere bureaus. Bijna altijd merken we dat dit veel stress en twijfel zaait bij de merchant, omdat het vaak een onbekende sprong in het diepe is. Daarom schrijf ik hier graag even neer hoe het bij ons verloopt, en waarom we niet gewoon de sleutels aannemen en beginnen typen.

Waarom overstappen zo moeilijk voelt

Misschien herken je jezelf hierin? De redenen om te blijven zijn zelden écht inhoudelijk maar eerder praktisch en psychologisch.

Kennis-lock-in. Eén partij, en soms ook zelfs maar 1 persoon binnen dat bedrijf, kent de code, en niemand weet exact hoeveel werk het is om dat over te nemen.

Schrik voor stukken. Zolang de shop draait, is elke wijziging een potentieel probleem. Een overname voelt als de grootste wijziging van allemaal.

Verloren kosten. Je hebt vele jaren en grote budgetten in dit project gestoken. Weggaan bij de partner die het gebouwd heeft voelt aan alsof je die jaren aan werk zomaar weggooit, ook al is dat niet het geval en werk je gewoon door op dezelfde Shopware winkel.

Onzekerheid over toegang. Weet je niet zeker of je je eigen domein, hosting, repository en licenties écht in handen hebt? En dat durf je niet te vragen zolang je nog samenwerkt om geen slapende honden wakker te maken.

Signalen dat het tijd is om te verhuizen

Niet elk kleinste ongemak is een reden om te wisselen. Soms is een gesprek genoeg, en kan er goed verder gewerkt worden met dezelfde personen. Maar een paar dingen zie je bijna altijd terugkomen bij shops die uiteindelijk toch overstappen:

• Je praat enkel met een accountmanager, nooit rechtstreeks met een developer of met personen die écht aan je website werken. Elke technische vraag gaat door een vertaalslag heen, en zo gaat er heel wat verloren.
• Updates zijn een heel project geworden. Elke Shopware-update is duur, spannend of wordt gewoon uitgesteld.
• Er zijn stukken van je site waarvan gezegd wordt dat je er beter niet aankomt. Dit houdt nieuwe features en updates tegen, en is een bron van stress bij zowel jezelf als bij de ontwikkelaars.
• Facturen zijn vaag. Er worden uren gefactureerd maar je ziet geen resultaat.
• Er is geen roadmap, en geen plan voor de komende 6 maanden, noch voor de lange termijn. Voor een webshop in groei is het essentieel om samen tot een goede planning te komen.

Eén van deze is een gesprek waard. Bots je tegen meerdere frustraties aan, dan is het wel een structureel probleem.

Belangrijk: dit gaat niet over slechte bureaus. Soms is er echt iets misgelopen, en soms ben je gewoon uit je partner gegroeid (of je partner is uit jou gegroeid) of past hun manier van werken niet meer bij waar je nu staat. Beide zijn geldige redenen om verder te kijken.

Waarom we niet gewoon hardweg het roer overnemen

Hier wijken we af van wat je misschien verwacht. Als je bij ons aanklopt met een bestaande shop, gaan we niet meteen features bouwen.

We nemen nooit blind een bestaande codebase over. Anders erven we de problemen van het vorige project, en betaal jij daar uiteindelijk voor.

Projecten die van een ander bureau komen, krijgen eerst een code review. We willen vertrouwen hebben in de codebase voor we de verantwoordelijkheid opnemen om hem up-to-date te houden. Als we die verantwoordelijkheid tekenen, moeten we weten waar we ja tegen zeggen. Zo kan het ook zijn dat we een project pas aannemen onder bepaalde voorwaarden, na een grote 'opkuisronde', of soms, helaas, zelfs helemaal moeten bedanken om bepaalde code te adopteren.

Stap 1: de audit

De audit is altijd de eerste start van de overname. Geen administratieve formaliteit maar wel het moment waarop onbekend risico bekend kan gemaakt worden.

Onze Shopware-audit kijkt onder andere naar:

• Codekwaliteit en architectuur. Hoe is dit gebouwd, en houdt die structuur stand als er iets bijkomt? Kunnen we zonder al te veel problemen verder bouwen op de bestaande website?
• Update-veiligheid en core overrides. Dit is het belangrijkste stuk. Elke wijziging buiten de officiële extension points verhoogt het risico bij toekomstige updates.
• Plugincompatibiliteit en dependencies. Welke plugins zitten erin, worden ze nog onderhouden, en wat blokkeert een versiesprong? Is alles custom? Zijn er veel Store-plugins in gebruik?
• Performance-knelpunten. Waarom duurt een productpagina drie seconden? Waarom is de checkout traag? Zit het probleem in de code of in de infrastructuur?
• Beveiliging. Zijn er bekende kwetsbaarheden actief, of loopt de Shopware-versie serieus achter?

Je krijgt daar een geprioriteerd rapport van en een gesprek waarin we het samen doornemen. Ook als je daarna beslist om toch te blijven waar je zit. Een audit is nuttig als tweede mening, los van wie het werk daarna doet.

Een audit is nooit verloren werk. Ze geeft je een objectief beeld van de technische staat van je Shopware-project, ongeacht de volgende stap. Beslis je om de overname door ons te laten uitvoeren, dan nemen wij de kost van de audit volledig voor onze rekening. Kies je ervoor om bij je huidige partner te blijven of met een ander bureau samen te werken, dan bedraagt de audit €1799,-. Bij een effectieve overname nemen wij de kost van de technische audit op ons. Wil je enkel een onafhankelijke technische analyse zonder verdere samenwerking, dan kan dat dus ook als aparte audit.

Stap 2: de eigendomscheck

Dit is de meest onderschatte stap van een bureauwissel, en een waar je vandaag zelf al aan kan beginnen.

Loop deze lijst af en zet bij elk item wie de eigenaar is. Niet wie het beheert, maar echt wie het bezit.

• Domeinnaam. Staat de registratie op jouw bedrijf, of op dat van je (vorige) agency?
• Hosting. Op wiens account draait de server, en wie kan hem morgen opzeggen? Heb je volledige toegang tot de server?
• Repository. Waar staat de code, en heb jij toegang? Krijg je de volledige git-historiek mee, of alleen een zip met de laatste versie?
• Shopware-licenties en plugin-licenties. Op wiens account staan die aangekocht?
• Betaalproviders, verzendpartners, ERP-koppelingen. Staan die accounts op jouw naam?
• Data. Kan je een volledige database-export en een media-export krijgen?
• DNS, mail, analytics, Search Console. Alle neven-software die soms wel eens in de vlugte vergeten wordt

Als hier onbekenden of gaten in zitten, betekent dat niet per se dat er problemen zijn. Vaak zijn deze diensten of producten organisch gegroeid: iets werd ooit snel opgezet en vlug geregeld, en niemand heeft het daarna rechtgezet of goed doorgegeven. Het is belangrijk om deze zaken in kaart te brengen, voordat je opzegt. Onderhandelen over toegang is een stuk makkelijker zolang de samenwerking nog loopt.

Stap 3: opruimen voor we bouwen

Uit de audit rolt een lijst. Niet alles daarvan moet meteen opgelost worden, en dat zeggen we er ook bij. Maar een paar dingen willen we in orde hebben voor we echt verder aan de slag gaan. Op een slechte fundering kan je niet bouwen.

1. Core overrides eruit en vervangen door de officiële extension points. Dit is wat een shop weer update-veilig maakt.
2. Vuile hacks documenteren of opruimen. Soms is een 'hack' de juiste oplossing geweest onder tijdsdruk. Dan mag hij blijven, maar dan staat er wel bij waarom. Idealiter gaan we op zoek naar een duurzame oplossing.
3. Naar de laatste Shopware-versie. Achterstand wordt alleen maar duurder naarmate je wacht. We updaten graag ten minste naar de laatste nieuwe versie binnen je huidige major.
4. Documenteren. Wat draait waar, welke koppelingen zijn er, wat is er bewust anders gedaan. Zodat de volgende persoon (ook als dat niet wij zijn) niet opnieuw moet raden.

Deze fase is werk, en dus een kost. We verzwijgen dat niet. Wat je ervoor terugkrijgt, is een shop waar de volgende update geen circus meer is. Daarnaast is je shop ook klaar om (optioneel) in te stappen op ons Evergreen pakket. Die eerste update naar de laatste versie wordt expliciet buiten het abonnement gerekend, gefactureerd aan ons normale tarief, net omdat het per project sterk verschilt hoe groot die inhaalbeweging is.

Deze fase is geen optioneel werk: een bestaande Shopware-shop klaarzetten voor de toekomst vraagt tijd en aandacht. We maken daar liever geen belofte van dat alles "vanzelf" opgelost is.

Wat je ervoor terugkrijgt, is een stabiele basis waarop je opnieuw kan verderbouwen. Updates worden geen risicovolle inhaalbeweging meer, maar een voorspelbaar onderdeel van het beheer van je webshop. Hoe groot deze opruimronde is, verschilt sterk per project.

Daarna kan je er eventueel voor kiezen om je shop onder Evergreen te brengen, zodat toekomstige updates en technisch onderhoud structureel opgevolgd worden.

Ondertussen blijft je shop gewoon draaien

Dit is meestal de vraag die er het meest toe doet, dus expliciet: er is geen enkel moment waarop we de stekker uittrekken en beginnen hopen dat het aan de andere kant weer aangaat.

De audit raakt je live shop niet aan. Het opruimwerk gebeurt in stappen, met testen en in een staging-omgeving. Pas als we klaar zijn gaan we hiermee live. De echt spannende stappen (een grote versiesprong of een migratie van hosting) plannen we samen in, op een moment dat jou past, met een gepast plan-b of terugvalscenario dat we afspreken voor we beginnen.

Time is money, maar downtime kost nog meer. Dat proberen we dus steeds zo hard mogelijk te beperken.

En dan pas: verder bouwen

Na de opruim bouwen we verder op een codebase die we vertrouwen, met rechtstreeks contact tussen jou en de ontwikkelaar die aan je shop werkt. Geen accountmanager, PM, PO, of AI-chatbot als tussenlaag.

Wil je updates daarna niet meer als losse projecten zien terugkomen, dan is Evergreen de vervolgstap: beveiligingsupdates binnen de week, minor- en patch-updates elk kwartaal, grote updates samen ingepland, voor een vast maandbedrag. Dat is geen verplichting, maar het is wel waar dit hele traject naartoe werkt: van bureau wisselen mag niet iets zijn dat je over drie jaar opnieuw moet doen.

Audit, eigendomscheck, opruimen, dan pas bouwen. Die volgorde is het hele verschil tussen een wissel die voelt als een gok en een wissel die voelt als een stabiele overdracht waar we samen met vertrouwen in springen.

En het mooie aan de eerste stap: die verplicht je tot niets. Een audit vertelt je wat er echt onder je shop zit, ook als je conclusie is dat je blijft waar je bent, of met een andere partij in zee wil gaan.

Dus, de belangrijkste hamvragen: weet jij vandaag wie de eigenaar is van je domein, je hosting en je repository? Als je even moest twijfelen bij een van die drie, is dat het eerste wat ik zou uitzoeken, ongeacht met wie je verder werkt.

Twijfel je of je Shopware-project klaar is voor een overdracht? Start met een technische audit. Je krijgt een objectief beeld van de staat van je shop, zonder verplichting om daarna met ons verder te gaan.