Naar de inhoud

Blog ·

Migreren van cPanel naar DirectAdmin

De meest genomen route weg van cPanel, en wat niet meekomt: gebruikersnaamregels, quota-sentinels, de identifier in je facturatiesysteem, en vijf echte vallen.

Door Provibr

Dit is de meest genomen route weg van cPanel, en hij wordt om één reden genomen: de licentie stopt met meegroeien met je klantenaantal. cPanel Premier rekent $0,49 per account per maand boven 100 accounts sinds 1 januari 2026; DirectAdmin Standard is $29 per maand voor onbeperkte accounts, afgelezen van directadmin.com op 21 augustus 2026. Bij duizend accounts op één server is dat $510,99 tegen $29.

De besparing is makkelijk te berekenen. Wat volgt is het deel dat dat niet is: wat er werkelijk moet gebeuren, wat de verplaatsing niet overleeft, en de specifieke plekken waar een eerste migratiescript stilletjes het verkeerde doet.

Provibr ondersteunt beide panelen, en een klant op elk van beide betaalt ons hetzelfde. We hebben geen reden om je deze stap aan te praten, alleen om hem kloppend te maken als je hem zet.

Waar een migratie werkelijk uit bestaat

Vier dingen, en alleen om het eerste zit goed gereedschap.

  1. De data. Bestanden, databases, mail, DNS-zones. Dit is het deel waar leveranciers conversiegereedschap voor schrijven.
  2. De identiteiten. Gebruikersnamen, domeinen, pakketnamen. Die moeten op de bestemming bestaan en ze overleven niet altijd ongewijzigd.
  3. De automatisering. Alles wat je accounts aanmaakt, opschort en factureert is op cPanel gericht en moet ergens anders op gericht worden, meestal terwijl beide panelen live zijn.
  4. De supportgolf. Alles wat zich op de ene manier gedroeg en zich nu anders gedraagt, dat de komende twee weken als tickets binnenkomt.

We hebben je datamigratie niet uitgevoerd en we gaan het conversiegereedschap van niemand beschrijven alsof we het hadden getest. Punt twee, drie en vier zijn van ons, want we hebben beide panelen gemeten tijdens het bouwen van integraties ertegen.

De gebruikersnaamregel hernoemt sommige van je klanten

Beide panelen dwingen een vorm voor gebruikersnamen af, en het is niet dezelfde vorm. De cPanel-kolom is gemeten door accounts aan te maken op WHM 11.136 tot hij weigerde; de DirectAdmin-kolom is de regel die zijn eigen API afdwingt:

cPanel / WHMDirectAdmin
Patroon^[a-z][a-z0-9]{0,15}$^[a-z][a-z0-9]{2,15}$
Lengte1 tot 163 tot 16
Moet beginnen meteen lettereen letter
Koppeltekengeweigerdgeweigerd
Liggend streepjegeweigerdgeweigerd
Hoofdlettersstilzwijgend naar kleine lettersbehouden of geweigerd, nooit herschreven
Gereserveerde namenja, met hun eigen fout (root en andere)niet gemeten

Degene die mensen erin luist is het minimum. Een cPanel-account mag één of twee tekens lang zijn; een DirectAdmin-account niet. Heb je daar een paar van (en langlevende hosts hebben er meestal een handvol uit de begintijd), dan hebben ze een nieuwe naam nodig, en dat betekent dat de klant het moet horen en dat elke verwijzing naar de oude naam bijgewerkt moet worden.

En er is een val op de weg naar buiten. WHM accepteert een gebruikersnaam met hoofdletters, maakt hem in kleine letters aan, en meldt succes zonder de wijziging te noemen. Dus het account dat volgens jou MyClient heet, heet sinds de dag dat het gemaakt werd myclient op de server. Elke inventaris die je voor de migratie opbouwt moet van de server gelezen worden en niet uit je eigen administratie, anders komt een deel ervan met niets overeen.

Wat je facturatiesysteem bewaart, staat op het punt naar niets te wijzen

Dit is het deel dat onderschat wordt, want het is onzichtbaar tot het moment van overzetten.

Je facturatiesysteem, je aanmaakscripts, je monitoring en je supportgereedschap identificeren een hostingaccount allemaal aan iets. Op cPanel is dat iets de gebruikersnaam. Na de verplaatsing is het nog steeds een gebruikersnaam, maar als een van hen hernoemd is, is de verwijzing dood, en een dode verwijzing in een dunning-ronde geeft geen fout. Hij schort niets op.

Voordat je één account verplaatst, maak je één lijst met drie kolommen: de cPanel-gebruikersnaam, de DirectAdmin-gebruikersnaam die hij zal krijgen, en de identifier die je facturatiesysteem vasthoudt. Als die drie niet voor elke regel overeenkomen, is de migratie niet klaar, hoe de dataoverdracht ook ging.

Vijf dingen gemeten op de twee API's die een eerste script breken

Alles hier kwam uit het schrijven van integraties tegen draaiende servers, en alle vijf leveren verkeerde resultaten op in plaats van fouten.

Beide panelen melden falen met HTTP 200. cPanel geeft result: 0 terug in een metadata-object; DirectAdmin geeft error=1 in de body terug. Een script dat de statuscode controleert ziet succes bij elke fout aan beide kanten van de verplaatsing. cPanel heeft nog een derde vorm: een fout of ontbrekend token komt terug als HTTP 403 met een cpanelresult-object en helemaal geen metadata, dus een parser die alleen metadata kent kan een slecht token niet onderscheiden van een kapotte server.

cPanels schijflimiet van "0" betekent onbeperkt, niet nul. Dat geldt ook voor de strings "unlimited" en, voor verbruik, "none". Een migratiescript dat het bronquotum als getal leest en naar de bestemming schrijft, maakt voor elke onbeperkte klant die je hebt accounts aan met helemaal geen schijfruimte, en het doet dat zonder ook maar één waarschuwing.

Het contactadres van cPanel kan de letterlijke string "*unknown*" zijn. Hetzelfde geldt voor een paar van de mail-rate-velden. Kopieer hem ongecontroleerd over en je hebt accounts aangemaakt wier contactadres een plaatshouder is, wat je ontdekt wanneer de eerste opschortingsmelding nergens aankomt.

cPanels accountzoeken is een deelstringmatch, geen exacte. Vragen om provibrtest1 gaf zowel provibrtest1 als provibrtest12345 terug. Als je migratie elk account na de verplaatsing verifieert door het bronpaneel op de naam te doorzoeken, kun je het verkeerde account bevestigen en een klant als gemigreerd markeren die dat niet was. Filter zelf exact op de gebruikersnaam.

Een cPanel-server zonder accounts geeft geen lege lijst terug. Hij laat de datasleutel helemaal weg. Een script dat een ontbrekende sleutel als fout behandelt, meldt je laatste, succesvol geleegde server als een fout; een script dat het als “geen antwoord ontvangen” behandelt is erger, want op een live server is dat het verschil tussen “dit account is weg” en “we konden het niet vaststellen”.

Aan de DirectAdmin-kant zijn er nog twee die het weten waard zijn. Zijn verbruiksoverzicht loopt op aanmaken en verwijderen ongeveer drie seconden achter, dus een verificatiestap die meteen na een aanmaak draait ziet niets en concludeert dat het account niet gemaakt is; gebruik in plaats daarvan de gezaghebbende accountlijst. En de bevestigingstekst voor het hervatten van een account leest letterlijk “have been suspended”, wat juist tijdens een overzetting van belang is, wanneer opschorten op het ene paneel en hervatten op het andere de twee helften van elke verplaatsing zijn.

Wat er niet meekomt

Naast de data zelf:

Wat er gebeurt
PakkettenNiet overdraagbaar. Je maakt ze met de hand opnieuw aan op DirectAdmin, en de limieten erin zijn aan jou om gelijk te houden.
Addon- en parked-domeinencPanel meldt hoofd-, addon-, sub- en parked-domeinen per account. DirectAdmin maakt een account aan met één domein; de rest wordt er daarna in het paneel bij gezet. Alles wat geautomatiseerd is moet weten welk het hoofddomein is.
BandbreedtetellersMaandtotalen die de server zelf terugzet. Ze verhuizen niet mee, en de eerste maand na een migratie leest laag op het nieuwe paneel en hoog op het oude.
Redenen voor opschortingDe tekst wordt op cPanel teruggekaatst en per account bewaard. Reken erop dat je opnieuw moet vastleggen waarom alles wat nu opgeschort is, opgeschort is.
Alles wat de API van cPanel aanriepScripts richting klant, hooks, plug-ins van derden. Die hebben standaard geen DirectAdmin-equivalenten.
Schijfquota die nooit afgedwongen werdenZie hieronder. Dit is een supportgolf, geen dataprobleem.

De quota-val, en waarom hij in week één landt

Een cPanel-server dwingt schijfquota alleen af als het bestandssysteem waar de accounts op staan quota-ondersteuning heeft. Zonder dat accepteert WHM het pakket, accepteert hij het getal, en dwingt hij niets af. We hebben precies dit gemeten op een draaiende WHM 11.136-server: een account dat naar een pakket met een quotum van 2 GB werd verplaatst bleef zijn grens als unlimited melden, en de schijfcijfers per account kwamen leeg terug. Er faalde niets en er werd niets geweigerd.

Als dat de staat van je park is, dan is elk account feitelijk op onbeperkte schijf geweest zolang dat waar was, en sommige zullen ver over wat je ze verkocht zijn heen gegroeid. Verplaats naar een paneel dat het quotum dat je instelde wél afdwingt, en ze lopen allemaal in dezelfde week tegen de muur aan.

Controleer dit voordat je de migratie plant, niet tijdens. Als quota niet afgedwongen worden, moet je een beslissing nemen over de accounts die eroverheen zitten (verhoog ze, neem contact op, of beprijs ze), en dat is een veel betere beslissing om vooraf te nemen dan in een ticketwachtrij.

De verbindingstest van Provibr meldt of quota werkelijk afgedwongen worden op een cPanel-server, naast de versie en de accountaantallen, wat een goedkope manier is om erachter te komen. Het is ook de reden dat het platform de schijflimiet van een account uit het account leest in plaats van uit het pakket: wat het account meldt is wat er geldt.

Doe het in cohorten, en reken op maanden

Het patroon dat werkt is saai en het is het enige dat werkt.

Richt nieuwe bestellingen eerst op DirectAdmin. Hiervoor hoeft niets te verhuizen, het bestemmingspaneel wordt onder echte omstandigheden beproefd, en je leert zijn gedrag op accounts waar niemand jarenlang van afhankelijk is geweest.

Verplaats daarna de accounts met de slechtste verhouding tussen licentie en omzet. Je goedkoopste plannen, wier klanten zich het minst aantrekken van de interface.

Daarna al het andere, in batches die je aankunt. Een batchgrootte waarbij een slechte middag te herstellen is, wat voor de meeste hosts kleiner is dan ze eerst plannen.

Houd het oude paneel tot het laatste account eraf is en één volledige facturatiecyclus voorbij is. De maand na een migratie is wanneer de teller terugloopt, de facturen uitgaan en de verschillen opduiken.

De maanden ertussen

Die hele periode draai je twee panelen. Twee logins, twee manieren om te tellen wat je verkocht, twee plekken om te kijken als een klant belt, en twee sets automatisering die het eens moeten zijn over wie opgeschort is. Die periode is de werkelijke kostenpost van de verplaatsing, en het is de reden dat veel hosts besluiten te migreren en er dan nooit aan beginnen.

Provibr koppelt beide panelen aan hetzelfde account. Een cPanel-account en een DirectAdmin-account verschijnen in dezelfde serverlijst, tellen mee voor dezelfde capaciteit en komen op dezelfde maandfactuur, met dezelfde acties voor opschorten, hervatten, van pakket wisselen en verwijderen erachter. De agent belt uitgaand vanuit je eigen netwerk, dus geen van beide servers hoeft een inkomende poort open te zetten en er wordt op geen van beide iets geïnstalleerd. Accounts die je niet via Provibr hebt aangemaakt blijven met rust gelaten tot je ze importeert, dus een paneel met al vierhonderd accounts erop wordt iets wat je overneemt in plaats van iets wat je herbouwt.

Het verplaatst je data niet. Het haalt de reden weg om het verplaatsen uit te stellen.

Lees verder

De cPanel-lijstprijzen van 2026 komen uit publieke berichtgeving over de aankondiging die op 1 januari 2026 inging; de DirectAdmin-prijzen zijn afgelezen van directadmin.com op 21 augustus 2026. Elk API-gedrag dat hier beschreven wordt is gemeten tegen draaiende cPanel- en DirectAdmin-servers tijdens het bouwen van de Provibr-integraties. Er wordt geen bewering gedaan over het data-conversiegereedschap van enige leverancier, dat we niet getest hebben.

Begin met één host en één agent

Maak een account aan, installeer de agent met één commando en koppel je eerste Proxmox-host. De proefperiode loopt 14 dagen en vraagt geen betaalgegevens.