Van cPanel migreren
cPanel is de grootste migratiebron die er is, dus CoreCP leest zijn archieven rechtstreeks — hetzelfde cpmove-archief dat pkgacct schrijft, én de volledige accountbackup die een klant zelf in zijn eigen cPanel kan maken zonder iemand om toe
Geschreven voor: Beheerder
cPanel is de grootste migratiebron die er is, dus CoreCP leest zijn archieven rechtstreeks — hetzelfde cpmove-archief dat pkgacct schrijft, én de volledige accountbackup die een klant zelf in zijn eigen cPanel kan maken zonder iemand om toestemming te vragen.
Alleen beheerders. Een import maakt unix-gebruikers aan, laadt databases en publiceert DNS op een hele machine.
Wat er meekomt
| Het account | Naam, unix-wachtwoord (de hash, dus het wachtwoord blijft werken), schijfquota, shell, en of het geschorst was |
| Websites | Het hoofddomein, de subdomeinen en de addon-domeinen, elk met de PHP-versie waarop cPanel ze serveerde |
| Bestanden | De hele home-map, op de plek waar cPanel hem had staan — zie Waar de bestanden terechtkomen |
| Databases | Elke database met zijn gegevens, zijn gebruikers en hun wachtwoorden |
| Mailboxen met hun wachtwoord-hashes, forwarders, catch-alls, autoresponders en alle berichten | |
| DNS | De zone, met de records die naar de oude server wezen verplaatst naar deze |
| Certificaten | Het geïnstalleerde certificaat en zijn sleutel, als het archief ze bevat |
| DKIM | De sleutel zelf, opnieuw gepubliceerd onder de eigen selector van CoreCP, zodat handtekeningen tijdens de omschakeling blijven kloppen |
| Cron | De crontab van het account |
Wat niet, en wat je eraan doet
Niets hiervan verdwijnt stilletjes. Elke regel hieronder staat met naam en toenaam in het rapport van de import die hem tegenkwam:
| Wat je doet | |
|---|---|
| PostgreSQL | CoreCP heeft geen PostgreSQL-rol. Zelf dumpen en terugzetten, of laten staan waar het staat. |
| Mailman-mailinglijsten | CoreCP heeft geen lijstbeheerder. Verhuis de lijsten vóór de cutover naar een dienst die dat doet. |
| Mailfilters | De mail komt gewoon aan; hij wordt alleen niet meer op de server in mappen gesorteerd. Bouw de regels na in de mailclient van de klant, of wacht op server-side filters. |
| Extra FTP-logins | CoreCP heeft nog geen FTPS-rol. De eigen SFTP-login van het account werkt, en dat is wat alles zou moeten gebruiken. |
| Apache-configuratie in het archief | CoreCP rendert zijn eigen webserverconfiguratie. Een eigen directive moet je opnieuw als CoreCP-instelling maken. |
| Reseller-pakketten | Maak de reseller en zijn hostingpakketten hier eerst aan en importeer daarna — dan landen de accounts bij de juiste eigenaar. |
| cPanel's eigen extra's | FrontPage, cPanel's eigen cron-hulpjes, zijn statistieken. Die gaan met cPanel mee weg. |
Waar de bestanden terechtkomen
cPanel serveert het hoofddomein uit ~/public_html en CoreCP serveert elk domein uit ~/domains/<domein>/public_html. De bestanden worden niet verplaatst. Een site die zijn eigen map ergens met een volledig pad noemt — en dat doen ze bijna allemaal ergens — zou daardoor breken. Het pad van CoreCP wordt aangemaakt als een link naar dat van cPanel, dus allebei werken en er staat maar één kopie op schijf. Het rapport zegt dat per website.
De uitzondering is mail: cPanel bewaart de maildirs ín de home-map en CoreCP bewaart ze in ~/imap, dus de berichten verhuizen daarheen. Ze blijven níet óók in de home staan — dan zou elk bericht dubbel meetellen in de schijfquota van de klant.
Route 1 — een backupbestand
Dit is de route als je het archief al hebt: iemand heeft het gestuurd, of de oude server bestaat niet meer.
Paneel → Migraties → Nieuwe migratie → Bronpaneel: cPanel / WHM → Backup uploaden. Het bestand wordt rechtstreeks naar de doelserver gestreamd en daar versleuteld bewaard; het paneel bewaart geen kopie, want een cPanel-archief bevat elke wachtwoord-hash en elke DKIM-sleutel van de oude server.
Druk daarna éérst op Proefdraaien. Dat schrijft niets en drukt het hele plan af: welke websites, op welke PHP-versie, welke databases onder welke naam, welke mailboxen, en alles wat niet meekomt. Lees het. Dan pas Nu migreren.
Op de commandoregel is het dezelfde operatie:
corectl import cpanel /root/cpmove-bob.tar.gz --dry-run
corectl import cpanel /root/cpmove-bob.tar.gz --report /root/bob.jsonRoute 2 — live ophalen van de oude server
CoreCP belt de oude machine zelf. Twee manieren, en welke je hebt hangt af van wat de klant je kan geven.
Met root op de bron (WHM)
De node draait cPanel's eigen pkgacct, streamt het resultaat rechtstreeks naar binnen en verwijdert het daarna op de bron.
# Wat laat deze server toe? Schrijft niets.
corectl import cpanel-server root@oude-host.example --mode pkgacct --check
# Eerst één account.
corectl import cpanel-server root@oude-host.example --mode pkgacct --accounts bob
# Daarna de rest.
corectl import cpanel-server root@oude-host.example --mode pkgacct --parallel 2Alleen met de eigen cPanel-login van de klant
Dit is het normale geval voor een klant die weggaat bij andermans shared host: hij heeft zijn eigen account en verder niets. CoreCP logt via SSH in als dat account en vraagt cPanel om dezelfde volledige backup die de klant zelf in zijn controlepaneel kan maken.
corectl import cpanel-server bob@oude-host.example --mode user --check
corectl import cpanel-server bob@oude-host.example --mode userNergens is root nodig. Twee dingen zijn goed om vooraf te weten:
- cPanel schrijft het archief in de home-map van de klant zelf, dus zijn quota moet ruimte hebben voor een tweede kopie van zijn account.
--checkmeet dat en weigert liever dan zijn schijf vol te zetten. CoreCP verwijdert het archief zodra het gelezen is. - De backupfunctie van het account kan door de beheerder van de bron zijn uitgezet. Is dat zo, dan zegt
--checkhet en is de route het archief: vraag om eencpmove-bestand en gebruik route 1.
Laat je --mode weg, dan kiest CoreCP: root@… betekent pkgacct, elke andere login betekent user.
Het rapport
Elke import eindigt in een verificatierapport, en dat is geen logboek maar een lijst van resources met OK, WARN of FAIL ernaast, ná afloop gecheckt tegen de draaiende server.
- OK — het staat er en het werkt.
- WARN — het staat er en er moet iemand iets doen: een mailbox waarvan de wachtwoordvorm niet mee kon, een verlopen certificaat, een database die hernoemd is.
- FAIL — het archief had het en het staat er niet. Alleen dat maakt het rapport rood.
Lees het vóórdat je de klant vertelt dat zijn site verhuisd is. Het is ook waar de lijst "wat niet is meegekomen" staat, dus het is wat je hem stuurt.
Databases houden hun naam, tenzij het niet kan
CoreCP leest de eigenaar van een database uit zijn <account>_-prefix, dezelfde conventie die cPanel gebruikt. Een database bob_shop die in het account bob wordt geïmporteerd houdt dus exact die naam, en het configuratiebestand van de site blijft werken.
Hernoemen gebeurt alleen als het moet: als je onder een andere accountnaam importeert, of als de bron een database zonder prefix had. Het rapport zegt het, en het zegt het ding dat ertoe doet — het configuratiebestand van de website noemt nog de oude naam. Bij een WordPress-site is dat DB_NAME in wp-config.php.
Extra namen, subdomeinen en hotlink-beveiliging
Drie dingen uit je oude paneel komen anders terug dan je misschien verwacht.
Pointers en geparkeerde domeinen worden extra namen van de website waar ze bij horen. Er komt dus geen tweede website bij in je lijst. Stond een pointer in je oude paneel op doorsturen, dan blijft hij doorsturen; stond hij op dezelfde site tonen, dan doet hij dat. En de post aan die naam blijft aankomen in de mailboxen van het hoofddomein, precies zoals daar.
Subdomeinen worden volwaardige websites onder hun hoofddomein, met een eigen certificaat en een eigen PHP-versie. Je bestanden blijven staan waar ze stonden — ook als dat in de map van het hoofddomein was. Er wordt niets verplaatst, dus links die naar een map verwijzen blijven werken.
Hotlink-beveiliging gaat niet mee. Dat staat ook met zoveel woorden in het migratierapport:
[corecp] hotlink configuration is NOT carried over for voorbeeld.nl.CoreCP heeft die functie bewust niet: hij werkt sinds 2020 niet meer betrouwbaar, omdat browsers het veld waar hij op kijkt niet meer meesturen. Je .htaccess gaat gewoon mee met je bestanden, dus de oude regels staan er nog en je kunt ze zelf weghalen. In Extra namen en subdomeinen staat wat wél werkt.
Twee keer doen is veilig
Hetzelfde archief nog een keer importeren verandert niets aan wat er al staat: geen dubbele mailbox, geen dubbele forwarder, geen verdubbelde rijen. Dat is opzet — een onderbroken migratie herhaal je, je maakt hem niet ongedaan.
Vóór de cutover
- Verlaag de TTL op de DNS van de bron een dag van tevoren, dan gaat de omschakeling snel.
- Proefdraaien, en het plan lezen.
- Migreren, en het rapport lezen.
- De site controleren op de nieuwe server voordat de wereld hem ziet — met een
hosts-regel op je eigen machine die het domein naar de nieuwe node wijst. - De DNS omzetten (of de nameservers).
- Nog één keer importeren na de omschakeling, voor wat er tussentijds is veranderd: hetzelfde commando, en herhalen is veilig.
- Pas dán zeggen tegen de oude provider dat hij mag stoppen.
Zien hoe ver een verhuizing is
Een verhuizing van een hele server duurt uren en soms een nacht. Sinds de takenlijst bestaat (zie Achtergrondtaken volgen) hoef je daarvoor het migratiescherm niet open te houden: de verhuizing staat als één regel in de lijst met alles wat er draait, met de teller die de verhuizing zelf bijhoudt.
- Een serververhuizing telt accounts: 9 van de 26 accounts. Klaar is alles wat niet meer op de wachtrij staat — geslaagd, met waarschuwing én mislukt, want alle drie zijn ze afgehandeld.
- Een verhuizing van één account heeft precies één stuk werk en toont dus géén balk, alleen de toestand en de duur. Een balk die alleen 0% of 100% kan zijn, vertelt je niets.
De aantallen ok / waarschuwing / mislukt uit het controlerapport zijn een oordeel, geen maat voor werk. Die blijven op de migratiepagina staan, waar ze per account uit te klappen zijn; de takenlijst is de index, niet een tweede rapport. Klik de regel en je gaat er rechtstreeks heen.
root@panel1:~# corecp-panel tasks list --source migration
STARTED SOURCE OPERATION SUBJECT STATE PROGRESS DURATION
2026-08-17 08:12:44 migration migration.server da1.example.net running 9/26 accounts 41m02sAls de server een migratie weigert
Drukt je hostingbedrijf op Nu migreren en neemt de doelserver het niet aan, dan blijft het bevestigingsvenster staan met de reden erin, en blijft alles wat er in het formulier stond gewoon staan. Een externe pull heeft een stuk of tien velden; die opnieuw moeten intypen omdat de bronnaam een typefout had is hoe iemand het opgeeft en een SSH-sessie opent.
Hetzelfde geldt voor het weggooien van een geüploade backup. Dat venster ging vroeger meteen dicht, en als de server het bestand niet wilde verwijderen kreeg je dat nergens te zien.
Nog een reden waarom een upload geweigerd kan worden: de doelserver draait een agent die dit paneel niet ondersteunt. Dan zegt de melding dat, met wat eraan te doen is — de server bijwerken — en de upload lukt zodra dat gebeurd is. Zie Servers buiten het versievenster voor wanneer dat speelt.