Transforming a cPanel server

This turns the cPanel server you already have into a CorePanel server. Not a copy on a second machine — this machine. Home directories, mailboxes and the MySQL data directory stay exactly where they are and CorePanel adopts them, so the sites are offline for seconds rather than hours, whether the server holds 20 GB or 2 TB.

On the server we timed — 45 accounts, 51 domains, 84 mailboxes, 43 databases — the sites were unreachable for 28 seconds, and the whole run took ten minutes. That window grows with the number of files on the server, not with the size of the data, so a much larger server is a minute or two rather than twenty. It is not a figure you have to take on trust either: PLAN prices it for your server, from your server, before you agree to anything.

If you would rather move the accounts onto a different server, that is the other route — see Coming from cPanel for how the two compare, and Importing cPanel accounts for how it works.

Before you start


The OS	AlmaLinux, Rocky or RHEL 8, 9 or 10. On CentOS 7, run cPanel’s own `elevate-cpanel` first, aiming at AlmaLinux 9.
Root	Every stage runs as root, on the cPanel server itself.
A backup	A hypervisor snapshot of the whole VM is the cheapest kind. The tool asks you to type `I-HAVE-A-BACKUP` before it changes anything.
An hour, unhurried	The offline part is seconds. The sitting around it is not something to rush.

One habit worth adopting: stop creating accounts in WHM for the duration. It is not forbidden, it is just one more thing to reconcile.

The tool also reports anonymously as it goes — which stage ran, how long it took, how long the sites were actually offline, and the id of the step that stopped it if one did. Never a hostname, a domain, an account name or an error message. It says so once, before the first stage, and --no-telemetry on any command (or COREPANEL_NO_TELEMETRY=1 in the environment) turns it off; the exact field list is in Anonymous usage statistics.

The tutorial

Step 1 — Ask the server whether it can be done

Run this on the cPanel server, as root:

curl -fsSL https://get.corepanel.net/check | sh

It downloads a single binary, checks it against its published checksum, runs it, prints a report and deletes itself. It reads and nothing else — no installation, nothing configured, nothing stopped. It does look up where each domain points and ask each of this server’s own sites for its homepage, the way a visitor would, so the check can tell you which sites are broken before you book a window; --no-dns turns both off if you are scanning a copy of a server. Run it on a production server in the middle of the day.

What comes back is an inventory of the server, a score, and a verdict in one of three states:

READY TO TRANSFORM — go ahead.
READY TO TRANSFORM, WITH ITEMS TO REVIEW — go ahead, once you have read the warnings. Fix them before you book the window, not during it.
CANNOT BE TRANSFORMED IN PLACE — the report names each blocker and its way out.

The full page on this stage, with an example report and what every finding means, is The cPanel migration check.

Step 2 — Install the tool

The same URL installs the binary it just verified:

curl -fsSL https://get.corepanel.net/check | sh -s -- --install

That puts corepanel-transform in /usr/local/bin. Nothing else on the server changes.

Step 3 — Run it

corepanel-transform

With no arguments it walks the whole transformation as one guided sitting. Before each stage it prints what that stage will do to this server — what goes offline, for how long, the steps it runs, and whether it can be reversed — and then it asks. Enter goes on, q stops.

It goes in five stages:

	Stage
1	CHECK	reads this server again and says whether it can be transformed
2	PLAN	writes the ordered steps and the offline window
3	PREPARE	installs CorePanel beside cPanel — nothing goes offline
4	CUTOVER	cPanel stops, CorePanel takes over — the offline window
5	VERIFY	proves every domain, mailbox, database and zone answers

Two stages ask you to type a word rather than press Enter, and both are deliberate:

PREPARE asks for I-HAVE-A-BACKUP.
CUTOVER asks for TRANSFORM.

If your server has more than 20 websites, the free Personal edition cannot hold it, and PREPARE will say so. The guided run offers the fix on the spot: a free 14-day trial of Pro or Business, no card and no key. It asks before minting one, because a trial is bound to this server’s address. You can also do it yourself:

corepanel license trial --edition business --email you@example.com

Step 4 — Read the verification, then look yourself

VERIFY checks every domain, mailbox, database and zone against the inventory taken before anything happened, and reports per account. Read it before you tell anyone the move is done.

Then spend five minutes looking with your own eyes:

corepanel account list                    # every account is here
curl -sI https://example.com/             # and once in a real browser
doveadm auth test user@example.com        # a mailbox logs in
dig SOA example.com @127.0.0.1            # the zone answers

Then open the panel itself. A transformed server does not ask you to configure it first. It opens on its dashboard, not on the initial configuration assistant, because PREPARE has already read the answers out of cPanel — on an in-place transformation they are the only correct ones:

What the panel needs	Where the run takes it from
Main server address	`ADDR` in `/etc/wwwacct.conf` — the machine keeps its address, which is why no DNS is re-pointed
Server hostname	`HOST`, and it is applied as well as recorded: the panel’s own site, the login banner and Postfix’s HELO name
Nameservers	`NS` through `NS4`, in cPanel’s own order — the first is the one every SOA names
The address each nameserver answers on	resolved from the delegation your server has been serving all along, so a nameserver that lives on another machine stays on it
Administrator’s contact address	`CONTACTEMAIL`

So the panel is already at your server’s own hostname over HTTPS, or at https://<server-ip> if you would rather not wait for anything.

Two details are worth knowing:

The contact address is recorded, not acted on. It is not registered as the certificate (ACME) contact and it does not rename the panel’s administrator account. Open Server → Configuration Wizard in the panel when you have a minute: confirming the address there is what commits it to both, and the same screen asks for the administrator’s name, which cPanel does not hold and the run therefore never invents.
A nameserver that does not resolve is recorded at this server’s own address — it is what cPanel already names in the SOA of every zone this machine serves — and the run says so on screen. That line is worth reading: a delegation that does not resolve was already broken before the transformation.

The cutover prints it — the step before the health gate, so it arrives whatever the gate goes on to say — and the run repeats it as the last thing on the screen, whether it finished or stopped:

SIGNING IN TO THE PANEL

  panel     https://your-server-hostname
  user      coreadmin
  password  <generated>

The password is generated by the run and kept in /root/.corepanel_password, readable by root only — the same file a hand-installed CorePanel uses. Change it in the panel whenever you like; nothing reads that file back.

Why the run has to hand you one at all: a CorePanel installed by hand is set up with corepanel system init, which asks for the panel domain, the administrator email and a password before the server has any accounts on it. A transformation never passes through that moment — the identity comes out of cPanel and the accounts are registered while cPanel is still serving — so the run sets the administrator’s first password itself.

It only ever sets it once. Running that step again on a panel that already has a password leaves it alone and just tells you where to sign in, so an administrator who has already been in and changed the password is never locked out by a second pass — which is what makes it safe to put in front of the gate that can send you round again.

Step 5 — Live with it for a few days

cPanel is not removed. It is stopped and disabled, and its packages, its /usr/local/cpanel and its licence are all still on the disk. That is what keeps the way back open, and leaving it there costs nothing but disk space.

While you are in that window:

corepanel-transform status      # what this run did, step by step
corepanel-transform rollback    # gives the server back to cPanel (asks you to type ROLLBACK)

A rollback gives back a whole cPanel — mail, FTP and DNS included — and because the data was never copied, mail delivered and database rows written since the cutover survive it. There is nothing to reconcile: there is one copy of the data, and both panels read the same bytes.

Step 6 — Remove cPanel, another day

When you are sure — days later, not the same evening:

corepanel-transform cleanup     # asks you to type ERASE-CPANEL

This is the point of no return, and it is the one thing the guided run never offers you. It refuses to run unless VERIFY has passed, the report found nothing broken, and something is answering on ports 80 and 443 right now.

The panel remembers this for you. Until cPanel is actually gone, the dashboard carries a card saying it is still installed, how many of its packages are left and roughly what they occupy — with this command on it, ready to copy, from the first day. It disappears by itself once the cleanup has run, because what it goes by is what is on the machine. See Dashboard.

That is the whole tutorial. Everything below is the detail behind it.

What actually happens

Why the window is short

The data never moves. Home directories, Maildirs and the MySQL data directory are adopted where they already are — same paths, same uids, same bytes on the same disk. The IP does not change either, so DNS delegation is untouched and there is no propagation to wait for.

What the transformation does is swap which set of daemons serves that data. That is why the offline window is measured in seconds regardless of the server’s size — stopping one set of daemons and starting another costs what it costs whether they were serving 20 GB or 2 TB — and why a rollback afterwards does not lose the writes made in between.

The one step that can scale with data size is the database, and the plan prices it from your server before you agree to anything:

What you have	What happens	How long
MariaDB, same major	Adopted in place: a config swap and a restart	Seconds
An older MariaDB	`mariadb-upgrade` over the same data directory	Minutes
MySQL 5.7 / 8.0	Dumped and restored per database	This is where an afternoon can hide

PREPARE, in detail

cPanel keeps serving every site, mailbox and database throughout this stage. What lands is only what genuinely coexists: CorePanel itself (its web server installed but masked, so there is no fight for port 80), the PHP stack under its own prefix, and the panel on a port of its own.

Then every account is registered, not created: the system user is adopted with its uid and its password hash, the home directory is adopted where it is, and the site is provisioned around them — PHP-FPM pool, vhost, DKIM key, DNS zone. Mailboxes, FTP logins, databases, certificates and cron jobs all come across with their existing credentials.

Mail, FTP and DNS are not installed here, and that is not an oversight: cPanel ships its own builds of those same daemons at the same paths, so installing ours would replace binaries under a running service. They are cutover work.

The PHP your sites are actually on

Before a single account is registered, PREPARE reads the interpreters cPanel is running right now and makes this server match them.

Versions. Every PHP version some site on the server is on gets installed, whether or not a fresh CorePanel would have it. This is not a nicety. An account is given the PHP version CorePanel has, falling back to the newest one installed — so on a server where only 8.4 was present, every site that ran cPanel’s 8.1 came back on 8.4, three minor versions up, and nothing said so. A version CorePanel cannot install at all — a 5.6, a 7.0, anything nothing packages any more — is named in the output along with the version those sites will land on instead, so you can test them while cPanel is still serving.

Sites with no version of their own. A cPanel site that was never moved off the server’s default does not record a version at all — its vhost says inherit, and the version it runs is whatever /etc/cpanel/ea4/php.conf says the server’s default is. That is the state of every account nobody has touched the PHP of, so on most servers it is the common case rather than the exception. The transform reads that file and resolves it, so those accounts count exactly like the ones that name a version: their PHP gets installed, and their extensions get carried across. Without that step they carry no version at all, which lands them on the newest one installed — and takes their extensions with it.

Extensions. Each source interpreter is asked what it loads, the answer is compared with what the interpreter replacing it loads, and the difference is installed from the extension catalogue. On a typical cPanel server that is imap, soap, bcmath, posix and the ionCube Loader — the last of which matters more than the rest put together, because software encoded with ionCube does not fail when the loader is missing. It answers 200 OK with a page saying it cannot run, which is exactly what a health check reads as a working site. WHMCS is the common case.

An extension the catalogue does not carry cannot be installed for you, and is listed by name with the interpreter it came from. Everything this step did — and everything it could not do — is checked again in VERIFY, per version, while the rollback window is still open.

This is also where cPanel’s exclude= line loses its php* entry, because with it in place dnf reports every CorePanel PHP package as not existing. The rest of that line — the entries protecting cPanel’s own dovecot, exim and FTP builds — stays until the cutover, and a rollback restores all of it.

Two things are deliberately deferred to the window, and reported as pending rather than done: tightening the home directories (doing it now would take every site offline, because cPanel’s Apache reaches docroots differently) and applying disk quotas (enforcing a limit against an already-full home would suspend a live account mid-afternoon).

If a single account fails to import, its adoption undoes itself — pool, vhost, DKIM, cert registration — and never the user, the home, or a byte inside it. Fix it and run again.

CUTOVER, in detail

The steps are ordered so that mail goes first — senders retry for days, so it is the forgiving one — and web goes last and comes back first, because it is the clock everyone is watching.

Every site is asked what it answers, while cPanel is still serving it. Nothing is changed and nothing is stopped; the reading is written down, and the health gate at the end compares against it. See below for why it is worth a step of its own.
cPanel’s own services stop.
Exim’s queue is flushed and drained; whatever will not go is listed for you.
Mail and FTP stop.
The databases are taken over, in the mode the plan named. On a server where that restarts MariaDB, the visible clock starts here — every site with a database behind it is serving an error for the length of the restart, and the plan says so before you agree to the window.
Apache stops, and cPanel’s own scheduled jobs are neutralised with it — an update run firing mid-cutover would restart everything just stopped. On every other server the clock starts here, and either way the run prints which step opened it.
Anything else that was serving or protecting the old stack is stood down — a proxy in front of Apache, a WAF, the host firewall.
The server’s outbound address is pinned to its IPv4, in /etc/gai.conf. This follows the step above for a reason: on a dual-stack machine, with the firewall down and no policy in that file, the C library prefers IPv6 for every destination that offers both — so a server that has always been seen at its IPv4 starts being seen at its IPv6, and everything licensed against the address (WHMCS, Softaculous, LiteSpeed, JetBackup) begins failing its licence check hours later, when the verdict it cached runs out. A server with no IPv6 route out is left alone, and so is one whose /etc/gai.conf already says something — the run tells you what to re-check instead.
The work that can only happen with nothing running: the home directories are tightened to 0700 (cPanel leaves them traversable so its Apache can reach the sites; CorePanel does not need that), the disk quotas are applied, and cron is paused so neither runs against a job halfway through its own.
CorePanel starts: PHP pools, then the web server. The clock stops here.
Mail, FTP and DNS are installed and started — cPanel’s builds come off, ours go on. Postfix’s submission service (587) is left as permissive as your Exim was: cPanel offers AUTH there without requiring TLS first, and applications already on the server — a billing system, a WordPress plugin — are configured against that. The reading is taken in step 1, while Exim is still answering; a server that already required TLS keeps requiring it, and STARTTLS is offered either way, so mail clients go on encrypting.
The DNS zones are published, with the same records, on the same port 53.
The panel is opened for its administrator: the address and a generated password, put on screen. This comes before the gate on purpose — see below.
A health gate probes the result from outside: one HTTP request per site, a mailbox login, a database login, an SOA query per zone, an FTP login — and every site’s answer against what step 1 recorded.

There is no DNS ceremony anywhere in that list. Same IP, same delegation.

You do not have to hold that list in your head while it runs. Every step says which of how many it is and what the plan expects it to cost, and from the moment the sites go down the tool keeps the clock on screen — how long they have been down, and how much of the window the plan still owes:

  6/15 Stop cPanel's web server — about 40 s
       the sites go down here · the plan books about 2 m
       Apache stopped; cPanel's cron is neutralised for the window
       took 12.4 s, well under the 40.0 s the plan estimated
       …
  9/15 Keep this server's outbound address on its IPv4 — about 1 s
       sites down 12.4 s · about 80 s left in the window
       outbound address pinned to IPv4 in /etc/gai.conf
       took 0.0 s
 10/15 Tighten the homes and apply quotas — about 15 s
       sites down 12.4 s · about 80 s left in the window
       45 homes tightened to 0700, median 59 ms, worst jsmith at 1.2 s
       took 5.1 s, well under the 15.0 s the plan estimated
 11/15 Start CorePanel — about 25 s
       sites down 17.5 s · about 65 s left in the window
       php-fpm and corehttpd are up; 51 vhosts loaded
       took 10.5 s (the plan estimated 25.0 s)
       the sites are back — down 28.0 s, and the plan booked about 2 m

That last line is the number the whole transformation is judged on, and it is measured rather than estimated. It is also the one figure the tool reports back to us, so the estimates above it get better with every server that runs one.

Resuming into a half-finished cutover says so instead of restarting the clock at zero: the sites went down in an earlier sitting, and the figure on screen says which outage it is measuring.

If the health gate finds something wrong it names it and offers the rollback rather than taking it — the step changes nothing, so you can fix what it found and run it again with the sites live.

A stopped gate does not leave you locked out. By the time it runs, this server is already CorePanel’s: the sites are being served, the accounts are registered, mail and DNS are ours, and stopping there undoes none of that. So the step before the gate is the one that hands over the panel — the address and the password, printed again under the error, last on the screen. Fixing what the gate named is usually a few clicks in that panel, and then you run corepanel-transform again: it re-enters the step that stopped and no other. The rollback is still there if you would rather take it, but it is a choice now rather than the only move left.

The reading taken before the window

The first step of the cutover asks every site on the server for its homepage while cPanel is still serving it, and writes down what came back. It changes nothing, it can be run as often as you like, and it exists because “the site answers” is not “the site works”.

A page can report its own failure with a perfectly successful status code. Software sold in encoded form — WHMCS and most billing and licensing systems are — ships a stub that checks for its loader and, when the loader is missing, prints a paragraph saying so and stops. PHP considers that a request it finished successfully, so the web server sends HTTP 200 with the notice where the page should be. A health gate that reads status codes sees a site in perfect order.

With the reading in hand the gate asks a better question — is this the same page? — and answers three things it could not answer before:

A site that broke during the cutover is named, with what the page now says. A missing loader, a missing extension: the gate quotes the sentence off the page rather than reporting a status code that looks fine.
A site that was already broken is not blamed on the run. Somebody’s unpatched template engine has been printing a fatal error since last month; cPanel served that as a 200 because suPHP prints errors into the page, and CorePanel serves the same fault as an honest 500. Without the reading, that reads as a site the transformation killed — and as an invitation to roll a whole server back over it. The step names those sites at the start of the window, in capitals, before anything is stopped.
A site that stopped redirecting is reported. An application that sent visitors to a login page and now hands them a page instead has stopped reaching its own code.

What is deliberately not compared is how big the page is. On a real cPanel server a third of the homepages answer 200 with an empty body, so a page that is blank in perfect health gets bigger when it breaks — and a homepage carrying a session token or a cart count differs between two requests a minute apart. “It got smaller” is not evidence, and nothing here treats it as any.

If the reading is missing — an older plan, an interrupted run — the gate says so and falls back to judging status codes, rather than passing in silence.

What PHP wrote while the gate was asking

A page can fail without the failure being visible anywhere in what it sends back. CorePanel runs PHP-FPM with display_errors off, so a fatal error prints nothing into the page — and if the script had already sent enough output for the buffer to flush, the response is HTTP 200 with the page cut short mid-sentence. Under the buffer size the same fault is an honest 500 the gate can see; above it, nothing in the response says anything is wrong.

So the gate also reads the one place a fatal always lands: the account’s own PHP error log. It notes where the log stands, asks that account’s sites for their homepages, and reports anything PHP recorded in between — with the file and the line.

This is always a warning and never a failure, and the reason is what the transformation is for. It keeps a site as it was. The code that threw the error is the customer’s own, unchanged by the run, and it was throwing the same thing on cPanel — where suPHP printed it into the page instead of logging it, which is why nobody had to look. A site that was already bad stays bad, its owner knows, and rolling a whole server back over somebody’s plugin is not the answer.

The same check notices when the log is unwritable, which matters more than it sounds: an empty log and a log nothing can write look identical, and only one of them means there were no errors.

What carries over, and what does not

Carried, verbatim or equivalent: system users with their uids and password hashes · home directories in place · Maildirs including Dovecot’s indexes · mailboxes, forwarders and their hashes · FTP logins · domains, subdomains, aliases and addon domains · per-domain PHP version · DNS zones · SSL certificates and keys · databases, users and grants · cron jobs · hosting packages and per-account limits · resellers, as sellers, one level deep, with the two ceilings they were sold on and the plans they sell.

Your resellers come across with their limits

cPanel keeps four files about a reseller. This run reads three of them — who owns whom, the reseller list itself, and reseller-limits.yaml — and each reseller is created in CorePanel before any of their accounts is registered, carrying the two totals CorePanel enforces: how many accounts they may sell, how much disk in total, and whether they may oversell that disk. A reseller capped at 25 accounts and 50 GB on cPanel is capped at 25 accounts and 50 GB here, and the ceilings refuse rather than decorate: the twenty-sixth account is turned away, whoever asks for it.

A reseller who had limits but no accounts still comes across. They exist on the source, and an import that only looked at accounts would never have heard of them.

Their hosting plans come with them. cPanel has no owner column for a package — it puts the owner in the name, as acmehost_starter — so each plan whose prefix names one of your resellers is filed under that reseller as plain starter, which is what makes it theirs to edit. Two resellers’ starter and your own are three different plans; a plan is unique per owner, not per server. A prefix naming no reseller is left alone, because gold_plus on a server with no reseller called gold is a plan somebody named with an underscore.

Three things a cPanel reseller carries have no equivalent here, and the run names each one as it files them rather than dropping them in silence:

cPanel	What happens
The per-reseller privilege list (`kill-acct`, `add-pkg`, `create-dns`…)	Reported, not applied. A CorePanel reseller is all-or-nothing within their own accounts, so a reseller who could not terminate accounts on cPanel can here — this is the one thing a migration widens, which is why the run prints it per reseller
A total bandwidth ceiling	Reported. CorePanel measures bandwidth per account and enforces no reseller total
A restriction on which packages they may sell	Reported. CorePanel has no such notion

The privilege list is the only one of the three that is kept rather than just printed. It is stored on the reseller, and it comes back at the moment it can still change your mind: the reseller that arrives has no panel login and can do nothing at all, so nothing widens until you give it one. The day you run corepanel admin create … --seller acmehost, that command answers with what the source allowed and what this login grants instead. Afterwards, corepanel seller show acmehost prints the set again — see the CLI reference. A reseller cPanel granted everything is not mentioned, because nothing was withheld from them to begin with.

The reseller also ends up with two logins where cPanel gave them one: an administrator login for the panel, and their hosting account’s own credentials for their own websites. cPanel made those the same username; here they are two objects.

Not carried, and the check says so beforehand: the undeliverable remainder of the Exim queue · traffic statistics and old web logs, which restart at zero · mailing lists · autoresponders and mail filters · Passenger/Node applications · PostgreSQL · Roundcube contacts and settings · third-party products (Imunify, JetBackup, Softaculous, LiteSpeed, CloudLinux) · a small set of .htaccess directives the check lists per domain · custom Apache includes.

Changed by design: Apache becomes CorePanel’s web server, Exim becomes Postfix, EA4’s PHP becomes CorePanel’s PHP stack, and mail and FTP authentication moves to CorePanel’s own broker.

If your billing system talks to WHM

A cPanel server with a WHMCS behind it is a server plus years of billing automation pointed at the WHM API. PREPARE carries those credentials across — as digests, so the plaintext never leaves the billing system that has been sending it for years — and leaves the API closed, because :2087 is the most attacked port in shared hosting and opening it is a decision.

The guided run asks once, after VERIFY. Otherwise:

corepanel whmcompat enable     # Business edition
corepanel whmcompat selftest   # drives a real WHM API request end to end

See WHMCS for what the shim covers.

The rollback, in detail

The way back is a command, not a document:

corepanel-transform rollback

It works the procedure out from this server rather than replaying a file written a week ago, so it cannot send you after a unit that has since gone. It stops and disables what CorePanel is holding, puts cPanel’s services back — including reinstalling cPanel’s own mail, FTP and DNS packages, whose configuration cPanel then rebuilds itself — and stops the panel last, once cPanel is answering again.

It also refuses when it should. Giving mail and FTP back to cPanel makes cPanel’s account files the truth again, and those stopped being updated at the cutover. If a mailbox was created, an FTP account added or a password changed under CorePanel since, the rollback compares both sides, names the difference and stops rather than discard it silently. --force goes ahead and prints exactly what is being given up.

The one thing it cannot compare is DNS, and it says so every time rather than checking it badly: a zone edited in CorePanel since the cutover is in CorePanel’s store, and cPanel would answer from the copy it had at the cutover.

The window has no timer. It closes when you run cleanup, and not before.

After cleanup

cleanup removes the cPanel packages, its repositories, /usr/local/cpanel, /var/cpanel (archived to a tarball first — it is a few megabytes of text and the only remaining answer to what this server was) and the licence. It also clears two things nobody would think to look for: cPanel’s global dnf exclusion, which hides every CorePanel PHP package behind what looks like a broken repository, and the /usr/local/bin/php that has just gone with cPanel’s PHP CLI — every cPanel-style cron line reading php script.php would otherwise have no php at all, so cleanup puts it back pointing at CorePanel’s.

It deliberately leaves cPanel’s own service database users alone. Nothing announced them, and a DROP USER is not undoable.

Three pieces of ordinary server setup are left to you afterwards, because each one is a visible change the transformation had no business making on its own:

the FTP passive port range, which is CorePanel’s and not cPanel’s — check it against your firewall
the host firewall and, if you want them, disk quotas at the filesystem level
SELinux back to enforcing, if the server was not already

When something goes wrong


The run was interrupted	`corepanel-transform` again, or `corepanel-transform resume`. State is on disk after every step.
A step failed	It says which one, and what is still standing. Every step before it is recorded as done: running again re-enters that step and no other.
You want to see what happened	`corepanel-transform status`
A site serves but behaves oddly	Almost always `.htaccess`. The check listed the directives per domain before you started.
You want out	`corepanel-transform rollback`, any time until `cleanup`.

The subcommands are all still there for automation and for anyone who already knows the order — check, plan, run, resume, status, rollback, cleanup — and they take the same flags and ask the same words as the guided run.

What changed, and when

Every release that touched the tool is listed in the Transform changelog, with what it fixed and what it means for a server transformed before it. Upgrade before you start rather than mid-run:

corepanel-transform version
curl -fsSL https://get.corepanel.net/check | sh -s -- --install