Mag mijn webhoster ons cms schrappen volgend jaar?

Een lezer vroeg me:

Onze websitebouwer en hosting bedrijf stapt over op een ander (en volgens hun veiliger) cms systeem. Het cms dat we nu gebruiken zal per 1 juli bevroren worden en per 1 januari daarna offline gehaald worden. Kunnen zij dat eenzijdig zeggen? Dit geeft ons enorme kosten, onder meer 5000 euro voor de migratie van alle content en verdubbeling van de maandelijkse kosten.
Het voelt natuurlijk nogal vervelend om over te moeten naar een nieuw systeem terwijl het huidige nog prima lijkt te werken. Maar onderhoud van software is duur, met name als de software steeds ouder wordt. Ik begrijp de stap van de websitebouwer/hoster dus wel.

Ik moet zeggen dat ik in dit geval de gegunde termijnen (een dik half jaar nog alles kunnen doen en daarna nog zes maanden gebruiken zonder aanpassingen in het cms) best schappelijk vind. Ik krijg deze vraag vaker maar dan zijn de termijnen eerder in weken uitgedrukt. Een periode van dik een jaar om te migreren naar een andere leverancier voelt best redelijk, en dat maakt dat ik eigenlijk geen juridisch argument tegen kan bedenken.

Ja, als er in de voorwaarden of SLA zou staan dat de software nog een aantal jaren mee moet kunnen natuurlijk. Maar ik ken geen leverancier die zichzelf zo hard vast gaat pinnen zonder behoorlijke vergoeding. Of als heel recent het contract is vernieuwd voor een paar jaar en het cms een belangrijk deel van de dienst is. Maar dat is vrij uitzonderlijk.

Arnoud

23 reacties

  1. Dit is precies de reden dat ik zakelijk probeer allerlei Saas-achtige diensten te vermijden. Je bouwt er (een onderdeel van) je bedrijf op, en dan stoppen ze (misschien meestal wel om op zich verdedigbare redenen, maar daar koop je niet veel voor).

    Hetzelfde geldt een beetje voor Open Source. Er zijn in het Open Source universum vele mooie dingen ontstaan, maar er zijn ook veel dingen die te veel afhangen van enkele individuen, en als die er geen zin meer in hebben/onderling ruzie krijgen dan krijg je, in het beste geval, verweesde software die nog wel een paar jaar zo-zo werkt, en in het slechtste geval stopt het gewoon.

    Voorbeeld 1: De opencloud/nextcloud split. Dat is dan goed gegaan (net?) omdat ze allebei voldoende kritische massa hadden, maar als dat niet zo was geweest? Voorbeeld 2: het voor mij zeer nuttige programma Dragondisk (een soort Filezilla voor S3). De ontwikkelaar onderhoudt het niet meer, maar het werkt nog. Hoe lang nog? En er is volgens mij niet echt een goed alternatief.

      1. Ik had wel verwacht dat er zo’n reactie zou komen. Dat is typisch zo’n reactie uit de Open Source hoek.

        Dat is inderdaad leuk als je duizenden euro’s per jaar of meer aan IT te besteden hebt. Er zijn veel bedrijven die genoeg hebben aan ‘standaard’ oplossingen, desnoods met een kleine aanpassing. Voor hen is IT gewoon een tool, net als een heftruck of een printer dat is.

        Die willen geen duizenden Euro’s aanvullend besteden aan ontwikkelaars, en dat zou ook niet moeten. En ze kunnen waarschijnlijk ook wel een alternatief vinden (betalend of gratis, open source of niet), maar de kosten zitten in de switch: configureren, data overzetten, tijdsverlies ivm leren werken met het nieuwe product.

        Ik draag Open Source een zeer warm hart toe, en ik heb ook al een aantal OS projecten financieel ondersteund, en ik zou met plezier zakelijk meer implementeren, maar het risico op discontinuiteit van een standaardproduct is gewoon groot, vaak te groot. Hetzelfde geldt overigens ook voor veel (niet OS) SAAS, zoals boekhoudsoftware, facturatiesoftware, project/team management software,(of CMS, zoals in het voorbeeld). Als ik Saas overweeg, dan kijk ik niet primair naar welk product het beste past bij mijn noden, maar of het waarschijnlijk is dat dat product over 5 jaar nog actief aangeboden en ondersteund wordt.

        En eigenlijk is dat jammer.

        1. Het is inderdaad bijna ondoenlijk, zelfs voor een team van ontwikkelaars, om even een open source pakket over te nemen als de oorspronkelijke club er de brui aan geeft. Je zit niet zomaar in een modern complex project, laat staan dat je dat als bedrijf zelfs maar moet willen.

        2. Geheel mee eens. Open Source is vaak geweldig, zowel technisch als principieel, maar het idee dat een normaal bedrijf dat gewoon gebruik wil maken van werkende software zelf die projecten gaat aanpassen en zo is niet reeel. Wat, naast wat je al zei, van belang is als je gebruik gaat maken van Saas-diensten is om heel goed en nauwkeurig te documenteren welke koppelingen je ermee hebt. Wat voor datastromen zijn er, wie zijn de gebruikers, wat voor API’s worden aangeroepen en vanaf waar, en welke van je diensten zijn afhankelijk van die koppelingen. Dat maakt het in elk geval eenvoudiger om naar een andere leverancier te migreren. Als je het weloverwogen doet kan het dingen beter, eenvoudiger en goedkoper maken. Als je het verkeerd doet kost het kapitalen en manjaren werk om alles weer te herstellen.

          1. Wat voor datastromen zijn er, wie zijn de gebruikers, wat voor API’s worden aangeroepen en vanaf waar, en welke van je diensten zijn afhankelijk van die koppelingen.

            Ja, maar ik wil juist betalen voor de laatste drie letters uit SAAS. Wat jj beschrijft is niet ‘as a service’, maar ‘as a burden’. Als ik dat allemaal moet gaan doen, als niet-IT-er, dan kan ik net zo goed de laatste stap ook nog nemen en de software ook lokaal laten draaien. Ik ben gewoon een zelfstandig zakelijk dienstverlener, niet een IT-er.

        3. Deze reactie vind ik dan weer typerend. Want deze discussie is juist gestart, omdat een commerciële leverancier precies hetzelfde probleem introduceert. Alleen van de commerciële CMS is geen broncode en is er helemaal geen kans om het over te nemen.

          1. Het verschil is dat ik als gebruiker kijk naar de kans op een dergelijk probleem, en jij (waarschijnlijk) naar de kansen op een oplossing als het probleem zich eenmaal voordoet.

            Er zijn misschien in het geval van OS extra oplossing vergeleken met closed source, en misschien nog wel goedkopere ook. Maar die mogelijke oplossingen liggen toch nog ver buiten mijn technische en financiele bereik, dus voor mij is dat geen voordeel.

            Misschien hebben we beiden gelijk?

      2. Nee, soms is dat een nadeel. De oorspronkelijke auteur houdt ermee op en er zijn 5 andere ontwikkelaars die branches gaan aanmaken van het project met iets andere namen waardoor je met 5 verschillende versies te maken krijgt. En dan moet je zelf onderhoud gaan doen dus da’s ontwikkelaar nummer 6 die erbij komt.

        En natuurlijk kun je een ontwikkelaar inhuren om het onderhoud voor jou te doen. Bij voorkeur een goedkope ontwikkelaar. Outsourcing naar Dubai of India, dan maar? Maar welke garantie heb je dan dat het product kwalitatief goed op orde blijft? Want als je een ontwikkelaar in India gaat zoeken dan zul je er duizenden vinden. Moet je alleen niet die ontwikkelaar treffen die alles op Google en StackOverflow bij elkaar moet zoeken omdat hij nul-komma-nul ontwikkel-kennis heeft…

        Nu ben ik een ontwikkelaar en kan ik het dus zelf onderhouden. Maar ik werk veel aan projectjes die door iemand anders in elkaar zijn gezet en aan alle kanten wankelen. Is het eerste dat ik moet doen twee weken refactoren om het stabieler te krijgen en dan heb ik nog geen tijd gehad voor de 20 nieuwe features die erin moeten. 🙂

        Da’s dus nog erger met open source. En vervelender indien het ook nog eens GPL code is. Of gemengde licenties…

    1. Ik hoor eigenlijk niet een alternatief? Geen SaaS, geen opensource. Dan blijft over een lokaal software pakket? Maar ook die zal geupdate moeten blijven met alle zelfde mogelijkheden waar het mis kan gaan of je moet betalen.

      1. Het alternatief is om je bij het aloude handwerk te houden… Koop je een commercieel pakket dan kan de leverancier stoppen met support. Ga je Open Source dan kan het project instorten. Kies je voor SAAS dan kan jouw leverancier met zijn product stoppen.

        Bij Open Source is er nog de mogelijkheid om een stuk onderhoud zelf uit te (laten) voeren; hetgeen in de andere gevallen geen reële mogelijkheid is. Bij SAAS is het de vraag of je na beëindiging van het contract nog wel bij jouw gegevens kunt; dat is bij een applicatie die je lokaal draait een stuk makkelijker (maar kan ook kostbaar zijn).

        Een goede ondernemer maakt een verstandiger keus dan zijn concurrenten.

      1. Open source zou je zelf kunnen onderhouden, als je de kennis en de tijd hebt (dat eerste heb ik niet, en dat tweede ook maar beperkt).

        Cyberduck: kende ik nog niet. Ik heb er naar gekeken. Zou inderdaad een keuze kunnen zijn, maar lijkt zware overkill voor mij. Alles wat ik zoek is een read-write toegang naar een S3 opslag met een bestand-structuur achtige GUI, meer niet.

    2. De cloud is gewoon een andere manier van ‘niet jouw computer’ zeggen. SaaS is het zelfde als ‘niet jouw software’. Beide maken je als je niet oppast afhankelijk van een leverancier. Aan de andere kant als je vroeger Wordstar gebruikte had je 21 jaar terug ook een probleem toen de ontwikkeling stopte.

      Belangrijker dan de software die je gebruikt (lokaal, cloud/service maakt niet uit) is dat de data in een open en liefst standaard formaat is opgeslagen/kan worden geëxporteerd.

      Belangrijker dan cloud of self hosten is zorgen dat je software beide kan. Wij maken een SaaS product dat in de cloud gehost wordt, de software kan echter ook naar een eigen server gedeployed worden, elke release wordt daarop getest. En uiteraard kunnen we dan dus als het moet ook deployen naar een virtual machine op een concurrerend cloud product.

  2. Is de 5000 E voor migratie naar het nieuwe CMS of naar een andere leverancier? En die verdubbeling van de maandelijkse kosten? Wordt deze gevraagd door de leverancier? Of is dat de prijs van een andere leverancier?

    Indien de hoster zegt: we zetten dit systeem stop, en je betaald maar 5000E en twee keer zoveel maandelijkse kosten, zodat wij niet zoveel onderhoudskosten hebben, dan vindt ik dit onevenredig bezwarend. Een prijswijziging dient duidelijk te worden opgenomen in de voorwaarden. Zoiets als: Wij mogen verhoogde BTW tarieven doorrekenen, of de prijzen, marktconform, verhogen. Te algemeen en ze gelden niet. Nooit specifiek genoeg om verdubbeling van contractkosten te eisen wegens “veiliger” systeem.

    Als een schrapping werkelijk nodig is wegens veiligheid, wat is dan de staat van het huidige systeem? Lek als een mandje? Schiet de leverancier daar ook niet te kort?

    Eisen bij de leverancier te blijven lijkt me geen goede oplossing, al is dit mogelijk goed recht. Je zit dan met een chagrijnige dienstverlener van een belangrijke functie van je bedrijf. Dat geeft meer problemen dan het oplost.

    En die leverancier geeft maar gewoon de CMS inhoud in een .sql oid, dat hoeft werkelijk geen 5000E te kosten, en zou zeker in de algemene voorwaarden moeten staan (“uw copyrighte inhoud kunt u krijgen op CD-ROM voor de prijs van 11.018 gulden” ja daaag!)

    En een mooie referentie/review achterlaten natuurlijk, voor toekomstige klanten die het wel interessant vinden te weten dat kritieke diensten worden opgeschort en dat het prijskaartje dan voor de consument rekening komt.

    “Om u veilig te houden, en onze taak als verantwoordelijke dienstverlener goed te kunnen doen, noodzaakt het ons over te stappen op een nieuw CMS. De kostenbesparing van dit nieuwe CMS wordt doorgerekend naar u als klant, middels een gratis migratie, en een marktconforme veiligheidsgarantie”.

  3. Ook: Als het nieuwe CMS minder onderhoudskosten heeft, waarom moet het dan 200% kosten?

    Je maakt als beetje IT-boer natuurlijk een migratie-script om je bestaande klanten allemaal met 1 klik over te zetten. Waarom zou je daar 5000E extra voor moeten betalen? Omdat het veiliger is? Veiliger dan marktconform mag worden verwacht van een capabele geldvragende dienstverlener?

    Klinkt zeer als de klant laten opdraaien voor een noodzakelijke techniek-update binnen het bedrijf (om een concurrent te blijven). Of er zelfs aan verdienen. Dat klinkt echt niet eerlijk voor een eenzijdig besluit.

  4. Ik zit niet erg in de wereld van CMS, maar ik stel me voor dat een CMS gebruiken wat minder goed onderhouden wordt, en dat ze nu overstappen naar bv WordPress. Ik geloof niet dat je dit soort omzettingen met een scripje kan doen. Dat is gewoon handwerk. Hoeveel werk het is hangt helemaal af van de site.

    1. Data uit het ene CMS trekken en in het andere stoppen kan prima geautomatiseerd worden. Vaak kies je als programmeur er voor om een aantal lastige dataconversies handmatig uit te laten voeren, om 12 uur te coderen aan wat in 2 uur met de hand gedaan kan worden is inefficiënt. Wat minder makkelijk te converteren is zijn “templates”, stijl-bestanden (css) en custom code (zowel javascript als CMS uitbreidingen).

      Ik heb geen idee hoe de webhoster uit het verhaal aan de €5000 kosten komt; dat is zo’n twee mensweken werk. Maar dat is niet onrealistisch als de site een behoorlijke portie maatwerk bevatte.

      1. Op pagina basis zal de tekst converteren best gaan, maar relaties/links tussen pagina’s wordt vast lastiger. En als gebruikers, al dan niet na registratie, commentaar o.i.d. kunnen leveren (die dan zolang je laag staat in de pikorde eerst gemodereerd moeten worden) wordt scripje al lastiger. En natuurlijk moet de site ook in de huisstijl blijven; en wil je ook niet dat alle gebruikers een nieuw account moeten maken.

        Ik ken de website niet, maar 5000 voor een complete conversie van CMS a naar CMS b komt redelijk over.

        1. Platte tekst overzetten is triviaal; bij opmaak in de tekst moet je de opmaak converteren naar het nieuwe systeem. Relaties tussen pagina’s zitten in de database en kunnen ook (met wat programmeerwerk) geconverteerd worden. Ik zou verwachten dan een webhoster die meerdere klanten van CMS A naar CMS B wil omzetten investeert in een automatische tool (en de kosten omslaat over de klanten die de tool gebruiken.) Gebruikers hebben een eigen tabel in de database en kunnen ook automatisch overgezet worden. Wachtwoorden overzetten kan een probleem zijn als die versleuteld zijn opgeslagen, maar ook daar is een “standaard” oplossing voor te vinden.

          Layout is vaak het probleem. Ieder CMS heet een eigen filosofie over hoe een pagina opgebouwd moet worden en het is lastig om de stijl weer 1-op-1 gelijk te krijgen. Daar kan een stevige portie handwerk in zitten. En al het programmeerwerk dat je hebt laten verrichten om jouw site “uniek” te maken zul je opnieuw moeten laten uitvoeren…

          Kortom, die €5000 kan redelijk zijn, maar ik heb niet genoeg informatie om dat te bepalen. Aan de andere kant, het zou me niet verbazen als je een betere deal krijgt wanneer je laat vallen dat dit aanbod een reden is om bij een concurrerende partij een offerte op te vragen.

Geef een reactie

Handige HTML: <a href=""> voor hyperlinks, <blockquote> om te citeren, <UL>/<OL> voor lijsten, en <em> en <strong> voor italics en vet.