DirectAdmin → StarkOne

Move every site to StarkOne. Leave the old server as it was.

Migronix runs on your new StarkOne server, reads the DirectAdmin server over SSH and rebuilds every account: files, databases, database users with their passwords, SSL, PHP settings, redirects, cron and FTP. Then it checks that each site answers exactly as it did.

Run on the StarkOne server, as root

$curl -fsSL https://migronix.io/install.sh | sh

Linux x86-64 and arm64One static binaryv0.2.6 What it does

DirectAdminsource · only read ssh

public_html databases DB users SSL PHP settings redirects cron FTP

StarkOnetarget · Migronix runs here root

migronix verifysource → target

bakery.example200 · 182,404 BOK

law-office.example308 → wwwOK

hotel.example200 · 96,248 BOK

studio.example200 → 500RED

Read-onlyon the source, apart from one SSH key and a firewall allow that cleanup removes

Same passwordsfor database users and FTP logins, copied as hashes

Re-runnablefinished steps are skipped, files and databases are brought up to date

Checkedevery site is asked on both servers and compared to the byte

How it works

Six steps, all on the new server

Nothing to install on the old server. Every step can be run again: finished work is skipped and the rest is brought up to date.

1

Install

Downloads the binary for this machine, checks its SHA-256 and puts it in /usr/local/bin. It uses the server's own ssh and rsync.

$curl -fsSL https://migronix.io/install.sh | sh
2

Link the servers

Creates Migronix's own SSH key, adds it to the source and allows each server's IP in the other's csf. No key at hand? Leave out --key and it prints a one-liner to run where you already have root.

$migronix init --source 203.0.113.10 --key /root/da_root_key
3

Scan and choose

A read-only inventory of accounts, domains, databases, certificates, cron, FTP and mail. Then leave out domains that point nowhere or elsewhere, or any account by name.

$migronix scan

$migronix exclude --not-live
4

Migrate

Two accounts at a time by default. Add --dry-run first to see every step for every account, or --only to start with one site.

$migronix migrate --parallel 2
5

Verify

Asks every migrated site from both servers and lights red wherever the answers differ, with the reason.

$migronix verify
6

Cut over

A last sync right before you switch DNS. After the switch, trade the imported certificates for Let's Encrypt ones that StarkOne renews, and remove the key and firewall entries from both servers.

$migronix syncthen switch DNS

$migronix letsencrypt

$migronix cleanup

Web UI or terminal

Click it or type it. It is the same tool.

The web UI runs the very same operations as the commands, and shows you the command before it runs it. Start a migration in the browser and follow it in the terminal, or the other way round.

Listens on localhost only. You reach it through an SSH tunnel, with the token from the printed URL.
One operation at a time, streamed live. A migration keeps running when you close the tab.
Stops by itself after 30 minutes without activity.

On the StarkOne server

$migronix ui

On your computer, then open the printed URL

$ssh -L 8787:127.0.0.1:8787 root@your-server

127.0.0.1:8787

Migronixv0.2.6migrate running

24accounts

21migrated

0failed

1RED

Scan sourceExclude not liveMigrate…Sync…Verify

User	Domain	PHP	Status	Verify
bakery	bakery.example	8.3	done	OK
lawoff	law-office.example	8.4	done	OK
studio	studio.example	7.4	done	RED
cafe	cafe.example	8.3	running

$ migronix migrate --only cafe

[1/1] cafe   databases: 2 database(s), 171M
[1/1] cafe   files: 1.1G
[1/1] cafe   nginx: force https, 2 redirect rule(s)

What moves

Everything a site needs to answer the same way

Each account becomes a StarkOne website with the same domain, Linux user and paths. Applications keep their configuration: no wp-config.php to edit.

Websites

Created through the StarkOne panel with the same domain, user and PHP version, which is installed if missing. Extra domains and subdomains become sites of the same user, domain pointers become aliases.

Files

rsync of every public_html over SSH, owned by the new user, at the same path as before.

Databases

A consistent mysqldump streamed over SSH into MariaDB, with the same character set. Nothing is written to the source's disk.

Database users

Recreated with the same password hashes and grants, for localhost and 127.0.0.1, and listed in the panel.

SSL

Existing certificates and keys are imported, wildcard and commercial ones too, so HTTPS works before DNS moves. Expired ones are skipped.

PHP settings

The limits PHP ran with on the source: memory_limit, upload sizes, timeouts and timezone, set per site in the panel.

Redirects

Force HTTPS, www or bare domain, and redirect rules from custom nginx templates, written to the site's StarkOne nginx config.

Cron

The account's crontab, with DirectAdmin's PHP paths rewritten to StarkOne's.

FTP

Every login with the same name and password, landing in the same directory. StarkOne's FTP plugin, with FTPS, is enabled if needed.

Listed in the scan, not moved mailboxes and forwarders DNS zones PHP modules StarkOne lacks nginx protections in custom templates

Verify

A red light for any site that answers differently

Before you touch DNS, migronix verify asks every migrated site over HTTPS straight from each server's own IP, with no redirect followed and no certificate check, and compares the answers.

Same HTTP status and redirect

A 200 that became a 500, or a redirect that now goes elsewhere, is red.

Same size, to the byte

Without compression, so a page cut short or a missing stylesheet shows up even when the status is 200.

Same title

Catches "Database error" pages that happen to be the right length.

Domain	Source	Target	Result
bakery.example	200 · 182,404 B	200 · 182,404 B	OK
law-office.example	308 → www.law-office.example	308 → www.law-office.example	OK
studio.example	200 · 79,122 B	500 · 0 B	REDHTTP 200 on source, 500 on target
hotel.example	200 · 96,248 B	200 · 87,228 B	REDsize differs: 96248 bytes on source, 87228 on target
shop.example	200 · 226,406 B	200 · 226,358 B	OKwithin the page's own variation

3 of 5 sites answer the same on both servers; 2 RED

Each server is asked twice. A page that changes on every request, with nonces or tracking ids, is only flagged when the servers differ by more than the page moves on its own.

Safety

Built for production servers

The old server keeps serving every site until you switch DNS. Migronix is careful with both machines.

The source is only read

Two changes, both made by init: Migronix's public key in authorized_keys and a csf allow for the new server's IP. cleanup removes both.

Never overwrites what it did not create

A website, Linux user, database or database user that already exists on StarkOne stops that account instead.

Protects live sites

A site whose DNS already points to the new server is not re-synced from the old one, where its data is older. --force overrides.

Resumable

Every step of every account is recorded. After an interruption, run the same command again.

One operation at a time

The terminal and the web UI share a lock, so two runs never write the same state.

Everything on record

Inventory, plan, state and a log per account in /var/lib/migronix. The plan is plain JSON you can edit.

FAQ

Questions

Requirements

New server: StarkOne, with root access. Linux x86-64 or arm64.
Old server: DirectAdmin, reachable over SSH as root: with a key you already have, or through the one-liner init prints.
Network: The new server connects to the old one on its SSH port. init opens csf for it.

Do the sites go down during the migration?

No. Migronix copies while the old server keeps serving. Nothing changes for visitors until you switch DNS, and migronix sync right before the switch brings files and databases up to date.

Can I migrate one site first?

Yes. migronix migrate --only example.com takes users or domains. Use --dry-run to see exactly which steps would run.

What happens to email?

The scan lists mailboxes and forwarders per domain, so you know what is there. Moving mail is not part of Migronix yet.

A step failed. Now what?

migronix status shows which step and why, /var/lib/migronix/logs/<user>.log has the details. Fix the cause and run the same command again: finished steps are skipped.

How do I remove Migronix afterwards?

migronix cleanup removes its key from the old server, the csf entries on both servers and its StarkOne API key. Then delete /usr/local/bin/migronix and /var/lib/migronix.

What does the install command do?

It downloads the binary for your architecture from migronix.io/download, checks it against SHA256SUMS and installs it as /usr/local/bin/migronix. Nothing else on the system changes, and running it again upgrades in place.

Loading install.sh…

Ready when your new server is.

Install on the StarkOne server, run migronix ui, and follow the steps.