Блог ·
Міграція з cPanel на DirectAdmin
Найбільш проторований маршрут із cPanel і що не переноситься: правила імен, спеціальні значення квот, ідентифікатор у білінгу та пʼять реальних пасток.
Автор: Provibr
Це найбільш проторований маршрут із cPanel, і його обирають з однієї причини: ліцензія перестає рости з кількістю ваших клієнтів. cPanel Premier бере 0,49 $ за обліковий запис за місяць понад 100 облікових записів станом на 1 січня 2026; DirectAdmin Standard коштує 29 $ на місяць за необмежену кількість облікових записів, прочитано з directadmin.com 21 серпня 2026. На тисячі облікових записів на одному сервері це 510,99 $ проти 29 $.
Заощадження легко порахувати. Далі йде та частина, яку порахувати непросто: що насправді має статися, що не переживає переїзду, і конкретні місця, де перший міграційний скрипт нишком робить не те.
Provibr підтримує обидві панелі, і клієнт на будь-якій платить нам однаково. У нас немає причини вмовляти вас на цей переїзд, лише зробити його точним, якщо ви на нього зважитеся.
З чого насправді складається міграція
Чотири речі, і лише навколо першої є хороші інструменти.
- Дані. Файли, бази даних, пошта, зони DNS. Це та частина, для якої вендори пишуть інструменти конвертації.
- Ідентичності. Імена користувачів, домени, назви пакетів. Вони мають існувати на призначенні, і вони не завжди переживають переїзд незмінними.
- Автоматизація. Усе, що провізіює, призупиняє й виставляє рахунки вашим обліковим записам, спрямоване на cPanel і має бути спрямоване кудись інде, зазвичай поки обидві панелі діють.
- Хвиля підтримки. Усе, що поводилося одним чином, а тепер поводиться інакше, надходить як звернення протягом наступних двох тижнів.
Ми не виконували вашу міграцію даних і не збираємося описувати чиїсь інструменти конвертації так, ніби ми їх тестували. Пункти два, три й чотири належать нам, бо ми виміряли обидві панелі під час побудови інтеграцій проти них.
Правило імені користувача перейменує частину ваших клієнтів
Обидві панелі вимагають форми імені користувача, і це не та сама форма. Стовпчик cPanel виміряно, створюючи облікові записи на WHM 11.136, доки він не відмовив; стовпчик DirectAdmin відтворює правило, яке застосовує його власний API.
| cPanel / WHM | DirectAdmin | |
|---|---|---|
| Шаблон | ^[a-z][a-z0-9]{0,15}$ | ^[a-z][a-z0-9]{2,15}$ |
| Довжина | від 1 до 16 | від 3 до 16 |
| Має починатися з | літери | літери |
| Дефіс | відхилено | відхилено |
| Підкреслення | відхилено | відхилено |
| Великі літери | нишком робить малими | збережено або відхилено, ніколи не переписано |
| Зарезервовані імена | так, з власною помилкою (root та інші) | не виміряно |
Людей ловить саме мінімум. Обліковий запис cPanel може мати один чи два символи; обліковий запис DirectAdmin не може. Якщо у вас є такі (а довговічні хостери зазвичай мають кілька з ранніх днів), їм потрібне нове імʼя, а це означає, що клієнту треба сказати й що кожне посилання на старе імʼя треба оновити.
І є пастка на виході. WHM приймає імʼя користувача з великими літерами, створює його малими й повідомляє про успіх, не згадуючи про зміну. Тож обліковий запис, який ви вважаєте названим MyClient, від дня свого створення на сервері називався myclient. Хоч би який інвентар ви збудували для міграції, його треба прочитати з сервера, а не з ваших власних записів, інакше частина його ні з чим не збігатиметься.
Те, що зберігає ваша система білінгу, ось-ось указуватиме в нікуди
Це та частина, яку недооцінюють, бо вона невидима до самого перемикання.
Ваша система білінгу, ваші скрипти провізіювання, ваш моніторинг і ваші інструменти підтримки: усі вони ідентифікують хостинговий обліковий запис за чимось. На cPanel цим чимось є імʼя користувача. Після переїзду це досі імʼя користувача, але якщо будь-який із них перейменовано, посилання мертве, а мертве посилання у прогоні нагадувань не викидає помилки. Воно нічого не призупиняє.
Перш ніж переносити хоч один обліковий запис, складіть один список із трьома стовпчиками: імʼя користувача cPanel, імʼя користувача DirectAdmin, яке він матиме, та ідентифікатор, який тримає ваша система білінгу. Якщо ці три не збігаються для кожного рядка, міграція не готова, хоч би як пройшло перенесення даних.
Пʼять речей, виміряних на двох API, що зламають перший скрипт
Усе тут вийшло з написання інтеграцій проти робочих серверів, і всі пʼять дають неправильні результати, а не помилки.
Обидві панелі повідомляють про збій кодом HTTP 200. cPanel повертає result: 0 всередині обʼєкта metadata; DirectAdmin повертає error=1 у тілі. Скрипт, який перевіряє код статусу, бачить успіх для кожного збою по обидва боки переїзду. У cPanel є й третя форма: неправильний чи відсутній токен повертається як HTTP 403 з обʼєктом cpanelresult і без жодного metadata, тож парсер, який знає лише metadata, не відрізнить поганий токен від зламаного сервера.
Ліміт диска "0" у cPanel означає безлімітно, а не нуль. Так само й рядки "unlimited" та, для використання, "none". Міграційний скрипт, який читає квоту джерела як число й пише її на призначення, створить облікові записи взагалі без місця на диску для кожного вашого безлімітного клієнта, і зробить це без жодного попередження.
Контактним email у cPanel може бути буквальний рядок "*unknown*". Те саме для кількох полів швидкості пошти. Скопіюйте його не перевіривши, і ви створите облікові записи, чия контактна адреса є заповнювачем, що ви виявите, коли перше повідомлення про призупинення полетить у нікуди.
Пошук облікових записів у cPanel робить збіг за підрядком, а не точний. Запит provibrtest1 повернув і provibrtest1, і provibrtest12345. Якщо ваша міграція перевіряє кожен обліковий запис після переносу, шукаючи його імʼя в джерельній панелі, ви можете підтвердити не той обліковий запис і позначити мігрованим клієнта, який ним не був. Фільтруйте точно за іменем користувача самі.
Сервер cPanel без облікових записів не повертає порожній список. Він узагалі пропускає ключ даних. Скрипт, який вважає відсутній ключ збоєм, повідомить про ваш останній, успішно спорожнений сервер як про помилку; скрипт, який вважає це «відповіді не отримано», гірший, бо на робочому сервері це різниця між «цього облікового запису немає» і «ми не могли сказати».
З боку DirectAdmin є ще дві, які варто знати. Його перелік використання відстає від створень і видалень приблизно на три секунди, тож крок перевірки, який виконується одразу після створення, не бачить нічого й робить висновок, що обліковий запис не було створено. Використовуйте натомість авторитетний список облікових записів. А текст підтвердження зняття призупинення облікового запису буквально каже «have been suspended», що важить саме під час перемикання, коли призупинення на одній панелі й зняття призупинення на іншій становлять дві половини кожного переїзду.
Що не переноситься
Окрім самих даних:
| Що відбувається | |
|---|---|
| Пакети | Не переносяться. Ви відтворюєте їх вручну на DirectAdmin, а тримати ліміти всередині них в узгодженні маєте ви самі. |
| Додаткові та припарковані домени | cPanel повідомляє головний, додаткові, під- та припарковані домени на обліковий запис. DirectAdmin створює обліковий запис з одним доменом; решту додають усередині панелі після. Усе автоматизоване має знати, який із них головний. |
| Лічильники трафіку | Місячні підсумки, які сервер скидає сам. Вони не переносяться, і перший місяць після міграції читається низько на новій панелі й високо на старій. |
| Причини призупинення | Текст відлунюється на cPanel і зберігається на обліковий запис. Плануйте перезаписати, чому призупинено те, що зараз призупинено. |
| Усе, що зверталося до API cPanel | Клієнтські скрипти, гачки, сторонні плагіни. За замовчуванням у них немає еквівалентів DirectAdmin. |
| Квоти диска, які ніколи не застосовувалися | Див. нижче. Це хвиля підтримки, а не проблема даних. |
Пастка квот і чому вона припадає на перший тиждень
Сервер cPanel застосовує квоти диска лише тоді, коли файлова система, на якій живуть облікові записи, несе підтримку квот. Без неї WHM приймає пакет, приймає число й не застосовує нічого. Ми виміряли саме це на робочому сервері WHM 11.136: обліковий запис, перенесений на пакет із квотою 2 ГБ, далі повідомляв свій ліміт як unlimited, а цифри диска на обліковий запис поверталися порожніми. Ніщо не зазнало невдачі й нічого не було відхилено.
Якщо такий стан вашого парку, то кожен обліковий запис фактично був на безлімітному диску стільки, скільки це було правдою, і деякі з них виросли значно за те, що ви їм продали. Перейдіть на панель, яка справді застосовує налаштовану вами квоту, і всі вони впруться в стіну того самого тижня.
Перевірте це до планування міграції, а не під час нього. Якщо квоти не застосовуються, у вас є рішення щодо облікових записів, які перевищують (підняти їх, звʼязатися з ними чи призначити їм ціну), і це набагато краще рішення ухвалити заздалегідь, ніж у черзі звернень.
Перевірка підключення Provibr повідомляє, чи квоти справді застосовуються на сервері cPanel, поряд із версією та підрахунками облікових записів, що є дешевим способом дізнатися. Це також причина, чому платформа читає ліміт диска облікового запису із облікового запису, а не з пакета: те, що повідомляє обліковий запис, і є тим, що діє.
Робіть це когортами й очікуйте місяців
Шаблон, який працює, нудний, і це єдиний, що працює.
Спершу спрямуйте нові замовлення на DirectAdmin. Для цього нічого не має переїжджати, панель призначення випробовується в реальних умовах, і ви вивчаєте її поведінку на облікових записах, від яких роками ніхто не залежав.
Потім перенесіть облікові записи з найгіршим співвідношенням ліцензії до доходу. Ваші найдешевші плани, чиїм клієнтам найменше важить інтерфейс.
Потім усе інше, партіями, які ви можете підтримати. Розмір партії, за якого поганий вечір відновлюваний, а це для більшості хостерів менше, ніж вони спершу планують.
Тримайте стару панель, доки останній обліковий запис не зійде з неї й не мине один повний цикл білінгу. Саме в місяць після міграції лічильник скидається, рахунки виходять, а розбіжності зʼявляються.
Місяці посередині
Увесь цей відрізок ви запускаєте дві панелі. Два входи, два способи рахувати те, що ви продали, два місця, куди дивитися, коли клієнт телефонує, і два набори автоматизації, які мають дійти згоди щодо того, хто призупинений. Цей період і є справжньою вартістю переїзду, і це причина, чому багато хостерів вирішують мігрувати, а потім так і не починають.
Provibr підключає обидві панелі до одного облікового запису. Обліковий запис cPanel і обліковий запис DirectAdmin зʼявляються в тому самому списку серверів, рахуються в ту саму потужність і потрапляють у той самий місячний рахунок, з тими самими діями призупинення, відновлення, перепакування й видалення за ними. Агент дзвонить назовні з вашої власної мережі, тож жодному серверу не треба відкривати вхідний порт і нічого не встановлюється на жоден. Облікові записи, які ви створили не через Provibr, лишаються недоторканими, доки ви їх не імпортуєте, тож панель, на якій уже чотириста облікових записів, стає чимось, що ви берете під опіку, а не чимось, що ви перебудовуєте.
Він не переносить ваші дані. Він прибирає причину відкладати їх перенесення.
Читати далі
- DirectAdmin проти cPanel: цифри 2026: крива вартості на обліковий запис і девʼять операційних відмінностей.
- Підвищення цін cPanel 2026: арифметика за розміром парку й чотири шляхи виходу.
- Налаштування DirectAdmin: ключі входу, пакети, вебплани та імпорт облікових записів.
Прейскурантні ціни cPanel 2026 взято з публічних повідомлень про анонс, чинний з 1 січня 2026; ціни DirectAdmin прочитано з directadmin.com 21 серпня 2026. Уся поведінка API, описана тут, виміряна на робочих серверах cPanel і DirectAdmin під час побудови інтеграцій Provibr. Жодного твердження не зроблено про інструменти конвертації даних будь-якого вендора, які ми не тестували.
