In het kort
Van Magento bureau wisselen hoeft geen downtime of gemiste bestellingen te betekenen. Het risico zit in de overdracht: toegang die niet van jou is, code die niemand heeft gecontroleerd en patches waarvan niemand zeker weet of ze erop staan. Deze checklist laat zien wat je regelt voordat je van Magento bureau wisselt, hoe je de overdracht stap voor stap op een stagingkopie uitvoert en wat je in de eerste 30 dagen met je nieuwe Magento specialist controleert.
Signalen dat het tijd is om van Magento bureau te wisselen
De meeste samenwerkingen met een bureau eindigen langzaam, niet met één groot incident. Deze signalen moet je serieus nemen.
- Tickets wachten dagen op antwoord, en dringende problemen worden behandeld als gewone verzoeken
- Niemand kan je vertellen welke Magento-versie en welk patchniveau je webshop draait
- Beveiligingspatches worden laat geïnstalleerd, of direct op de live webshop zonder test op staging
- Elke update maakt iets kapot, en de fixes worden als nieuw werk gefactureerd
- Je hebt geen toegang tot je eigen code, server of accounts, of je moet er elke keer om vragen
- De developer die je webshop kende is vertrokken, en de rest van het team begint bij nul
- Je hebt kennis nodig die het bureau niet heeft, bijvoorbeeld Hyvä, Adobe Commerce of serverwerk
Wat van jou moet zijn voordat je van Magento bureau wisselt
Voordat je iets aankondigt, controleer je of elk account en elke sleutel hieronder op naam van je bedrijf staat, of dat je er in elk geval admintoegang toe hebt. Alles wat alleen het oude bureau beheert, kan de overdracht tegenhouden.
| Wat | Waar het staat | Waarom het telt |
|---|---|---|
| Git-repository | GitHub, GitLab of Bitbucket | De volledige codegeschiedenis, inclusief eigen modules en themawijzigingen. Die hoort in jouw organisatie te staan, met het bureau als uitgenodigd lid. |
| Server en hosting | Account bij de hostingprovider, SSH en controlepaneel | Zonder eigenaarstoegang kun je de webshop niet verhuizen, opschalen of herstellen. |
| Magento Marketplace-toegangssleutels | Commerce Marketplace-account (MAGEID) | Composer downloadt met deze sleutels Magento- en Marketplace-pakketten van repo.magento.com. Extensies die op de Marketplace zijn gekocht, zijn gekoppeld aan het account waarmee ze zijn gekocht. |
| Composer auth.json | Projectmap of Composer-homemap op de server | Bevat de inloggegevens voor private pakketrepositories. Het bestand hoort niet in Git, dus laat elke repository erin opsommen. |
| Hyvä-licentie of sleutels | Hyvä-account | Het Hyvä-thema is gratis en open source, maar Composer-toegang werkt met een sleutel die aan je domein gekoppeld is. Hyvä Checkout, UI en Commerce zijn betaalde licenties. |
| Extensielicenties | Klantaccount bij elke leverancier | Licenties die het bureau heeft gekocht, staan mogelijk op zijn naam. Vraag om een overdracht, of om sleutels en downloads op jouw naam. |
| Domein, DNS en Cloudflare | Accounts bij registrar en Cloudflare | Wie de DNS beheert, bepaalt waar de webshop naartoe wijst en hoe de e-mail wordt afgeleverd. |
| API-sleutels voor betaling en verzending | Dashboards van betaalprovider en vervoerder | Sleutels horen in jouw accounts te zijn aangemaakt en na de wissel te worden vervangen. |
| Google-accounts | GA4, Search Console, Merchant Center, Google Ads, Tag Manager | Jouw data en de historie ervan. Jij hoort eigenaar te zijn, het bureau alleen gebruiker. |
| Back-ups | Hosting en externe opslag | Een recente back-up van database en media die je zelf kunt downloaden. |
| Documentatie | Wiki, README, ticketsysteem | Deploymentstappen, cronjobs, koppelingen, eigen modules en bekende problemen. |
Volgens de documentatie van Adobe horen Marketplace-toegangssleutels bij het MAGEID-account dat ze heeft aangemaakt: de public key is de gebruikersnaam en de private key het wachtwoord voor repo.magento.com. Heeft het oude bureau de sleutels in zijn eigen account aangemaakt, maak dan nieuwe aan in jouw account en laat ze tijdens de overdracht in auth.json zetten. Composer raadt zelf aan auth.json buiten Git te houden, dus je vindt het niet in de repository.
Stap voor stap overdragen zonder downtime
- Audit: het nieuwe bureau bekijkt de webshop voordat het iets verandert, waaronder de Magento-versie, extensies, eigen code, serverstack, cron, indexers, logs en snelheid.
- Toegang overdragen: je maakt persoonlijke accounts aan voor het nieuwe bureau in Git, hosting, de Magento-admin, Cloudflare en Google. Geen gedeelde wachtwoorden en geen logins die van het oude bureau worden doorgegeven.
- Stagingkopie: het nieuwe bureau bouwt een stagingomgeving op uit de Git-repository en een geanonimiseerde kopie van de database, en controleert of de deployment foutloos verloopt.
- Code review: de code op de live server wordt vergeleken met de Git-repository. Wijzigingen die direct op de server zijn gedaan en aangepaste core-bestanden komen in deze stap boven water.
- Patchniveau controleren: de Commerce Version Tool van Adobe, gestart met php vendor/bin/patch-status vanuit de rootmap van Magento, laat zien welke maandelijkse beveiligingspatches zijn geïnstalleerd en welke ontbreken. Het commando vendor/bin/magento-patches status van de Quality Patches Tool toont welke quality patches zijn toegepast.
- Monitoring: uptime, foutlogs, cron, queues en checkoutcontroles worden ingericht voordat de toegang van het oude bureau wordt ingetrokken, zodat niets onbewaakt draait.
- Inloggegevens vervangen: zodra het nieuwe team zelfstandig werkt, worden de wachtwoorden, SSH-sleutels, API-sleutels en Marketplace-sleutels die het oude bureau gebruikte gewijzigd of verwijderd.
- Overlap en overstap: plan een korte overlap waarin het oude bureau nog vragen kan beantwoorden, en beëindig daarna de toegang op een afgesproken datum.
Geen van deze stappen raakt de live webshop. Klanten blijven bestellen terwijl de overdracht op de achtergrond loopt.
De eerste 30 dagen met je nieuwe Magento specialist
- Een schriftelijk auditrapport met versie, patchniveau, risico’s en een prioriteitenlijst
- Ontbrekende beveiligingspatches worden eerst op staging geïnstalleerd en daarna live gezet
- Back-ups worden gecontroleerd door er echt één op staging terug te zetten
- De deployment is gedocumenteerd, zodat elke developer in het team wijzigingen op dezelfde manier live zet
- Een plan voor de komende maanden, zoals een upgrade, snelheidswerk of het opruimen van extensies
Wat je een nieuwe Magento specialist vraagt
- Hoe voeren jullie de overdracht uit, en wat hebben jullie in de eerste week van ons nodig?
- Vergelijken jullie de code op de server met de Git-repository?
- Hoe installeren jullie beveiligingspatches, en hoe bevestigen jullie daarna het patchniveau?
- Welke reactietijden spreken jullie af voor dringende problemen, en staan die in het contract?
- Blijven alle accounts, sleutels en licenties op onze naam staan?
- Wat documenteren jullie, en waar kunnen we het lezen?
Zo neem je netjes afscheid van het oude bureau
- Lees eerst het contract: opzegtermijn, openstaande facturen en van wie de code en de licenties zijn
- Zeg schriftelijk op, met een duidelijke einddatum en een lijst van wat je overgedragen wilt krijgen
- Vraag om documentatie, openstaande tickets en bekende problemen, niet alleen om wachtwoorden
- Betaal openstaande facturen op tijd, want zonder conflict verloopt een overdracht soepeler
- Trek toegang pas in nadat het nieuwe bureau heeft bevestigd dat alles werkt
Fouten om te vermijden als je van Magento bureau wisselt
- De toegang van het oude bureau intrekken voordat je een werkende kopie van de code en de database hebt
- Zonder controle aannemen dat de Git-repository overeenkomt met de live server
- In de eerste week een upgrade of redesign starten, voordat de audit klaar is
- Eén adminlogin met meerdere mensen delen in plaats van persoonlijke accounts aan te maken
- Cronjobs, koppelingen en e-mailinstellingen vergeten die alleen op de server bestaan
- Sleutels en wachtwoorden ongewijzigd laten nadat het oude team weg is
Overstappen naar MageBooster
MageBooster is een Magento bureau voor Magento Open Source, Adobe Commerce, Mage-OS en Hyvä. Overstappen naar ons gaat in vier stappen: een audit en controle van de toegang in de eerste week, 24/7-monitoring vanaf de tweede week, en daarna doorlopend onderhoud met maandelijkse beveiligingspatches die eerst op staging zijn getest en een maandelijks rapport. Het begint met een gratis analyse van je webshop, en jij beslist wat de volgende stap is.
Bekijk onze Magento support en onderhoud →
Lees ook: waarom werken met een Magento bureau? →
Wij nemen contact met je op
Laat je gegevens en het adres van je webshop achter. We bekijken eerst je webshop en nemen binnen één werkdag contact op, via telefoon, WhatsApp of e-mail, wat jij het liefst hebt.
English
German
Dutch
Turkish