Move projects to another server

You can run two SixPanel servers and keep projects on whichever one you like — some here, some there, both live at the same time. Move one project, or move the whole server in one go — this page is how you migrate from one SixPanel server to another. Nothing has to be moved all at once, and a project you do not move keeps running exactly where it is.

Shops and websites move the same way. A 6amMart project, a static website, a Node.js app, a PHP website and a WordPress site can all be sent to another server. Two things stay where they were made — a website built with Create with AI, and a staging site — and the page names them before you press anything (see Websites that stay).

This page is about the Migration page. It has three tabs, in the order you use them: Servers to pair the other machine, then One project or Everything depending on how much you are moving.

Your DNS is never touched, on either path. Nothing is switched over for you.

A project is offline for the last part of its move. Its code and files are copied while it is still serving. Then it is stopped on this server, so that nothing can change half-way, what changed in the meantime is sent, and it stays stopped here afterwards — see what "parked" means. Projects you are not moving are not affected. A static website is the one exception: it keeps answering here, because nothing of it changes.

Which of the two you want

One project — leave the rest where they are:

• One shop has outgrown the server it shares with two others, and you want it on a box of its own.
• You are moving to a bigger or cheaper provider and would rather do it one shop at a time than all at once.
• You keep one customer's shop, or one client's WordPress site, on its own server for their peace of mind.

Everything — this whole server, settings, shops and websites, onto a brand-new box:

• You have outgrown the current server and want a bigger one.
• You are changing hosting provider.
• You want everything on newer system software, on a fresh install.

The difference in what you must prepare: a single-project move needs SixPanel already installed on the other server. A move of everything does not — SixPanel installs itself on a plain, empty server with SSH and nothing else.

Step 1 — link the other server, once

Open Migration → Servers, then Link a server, and fill in its address, its SSH user, its SSH port, and either the password or an SSH private key.

Most cloud servers give you a user like ubuntu rather than root. Either works — SixPanel elevates its own commands.

Give it a name you will recognise — "Shop 2 server" is more use than an IP address six months later. Then press Link it.

The panel dials it straight away and tells you what it found: reachable with SixPanel installed, reachable but no SixPanel, or not reachable and why. A link that saves but cannot be reached is shown as a problem, not a success — better to know now than at the first move.

The password or key you give is stored on this server only, in a file only the system administrator can read, and deleted when you unlink. It is used for exactly two things: creating the project on the other server, and sending the data.

The link stays until you remove it. You do not re-enter anything per move.

Unlink takes the server off the list and deletes the stored password or key. Nothing on either server changes, and a project you already moved stays where it is.

Linking also remembers that server's identity, and the panel refuses to connect if it ever changes — that is what stops somebody else's machine answering at the same address. So if you rebuild or reinstall the other server, unlink it and link it again: unlinking forgets the old identity, and the new link records the new one.

Move one project

On Migration → One project, choose the project and the server, and press Move it. Read the confirmation before you press it: it says what happens to this copy, and it is different for a shop, a website and a static website.

The project list has two groups, 6amMart projects and Websites. Under it the page names what is left out and why:

• The main project is not in the project list — see Does my main project move? under Questions people ask.
• A staging site is not in it either — of a shop or of a website. It stays on the server it was made on; make a new staging site on the other server instead.
• Not offered here lists the websites that cannot be moved, each with its reason — see Websites that stay.
• A linked server whose last check failed is not in the server list. Open Servers, press Check now on it, and come back.

While a move is running, Move it is switched off and the page says so. The running move is the first one under Recent moves.

A 6amMart project

The panel:

1. Checks the other server is ready — it answers, SixPanel is installed, the project name is free there, and it has enough disk space. If any of those fail, the move stops before anything is copied and tells you which.
2. Backs this project up here, and verifies the backup. Not as the way the data travels — as the way back if something goes wrong.
3. Asks the other server to create the project. That server does it, with its own database, its own database user, its own PHP pool, its own Redis instance and its own ports — so nothing collides with what already runs there.
4. Sends the app and its uploaded files — while the shop is still serving. The whole project goes across: the admin app with its code and its installed packages, the customer website, and every uploaded file. This is the long part, and it costs no downtime.
5. Pauses this project here. Only this one: its website, its app API, its admin panel and its background workers stop, so no order, sign-up or upload can arrive from here on. Your other shops keep serving. Nobody is left inside its account either: SSH access to it is closed, a terminal open on it is closed, and whatever was still running as its account — a timed job half way through, something started by hand — is ended, and named in the move's log.
6. Sends what changed since — the files that were added or edited during step 4 — and then the database.
7. Compares both copies. It counts the rows in your database on both servers and compares them table by table, and it fingerprints every uploaded file on both sides and compares that too. Nothing is started on the other server until both sides match.
8. Brings the app up on the other server. That server gives the files to the project's own account, serves the project's addresses, points the app at its own database, rebuilds the caches, builds the customer website, starts the workers — and then asks the app whether it answers. Only when it does is the project marked installed there. You see each of those lines as it happens. A shop that keeps updating without the 6amMart addon (it was running before addons arrived) brings its addon along at this point: the other server installs the addon's code from its own SixPanel release, and the move's log says so. There is nothing to upload there (Addons).
9. Parks this copy.

While it is on its way, the other server lists it as Arriving from another server, a note at the top of its pages says the same, and it takes no changes there: no install, no saved setting, no restore, no deploy, no SSH access and no Open in phpMyAdmin — each would make the two copies differ. The note goes by itself when the move has finished. If a move stopped half-way and nothing is running any more, start the move again — it tidies up there first — or delete the project there with its database and files; the next move sends it again. (Deleted without them it is kept for a few days so it can be restored, and its short name stays taken for as long.)

It stays the project you know. Where its code comes from (the repository and branch), the access token or the deploy key each repository is read with, its push-to-deploy secret, its update history, the services you had switched off, and its licence all arrive with it, so Update works on the other server exactly as it did here.

Every stored time reads as it did. A database shows its dates through the time zone it runs on, and two servers need not run on the same one — an older server runs its database on the zone its owner chose when it was set up, a new one on UTC. The move asks both servers before it copies anything. When they read dates alike, nothing changes. When they differ, the move carries what every date reads here, and its log says so: the database here runs on UTC+05:30 and the one on … on UTC: every stored time is carried as it READS here. An order placed at 21:28 reads 21:28 on the new server. (Before this, such a move arrived with every order's time shifted by the difference between the two zones.)

One thing is yours to set again there: SSH access. Who may sign in to a project's account over SSH is decided on each server, behind your password — a move never opens a way in to another server. Turn it on again on the project's Terminal page there if you use it.

A website

A website moves in the same order, with less to do — about a minute for an ordinary one, most of it the other server setting it up:

1. Checks the other server is ready — it answers, its SixPanel can receive a website, the website's short name and every one of its addresses are free there, it has the PHP or Node.js version the website runs on, and it has enough disk space. If any of those fail, the move stops before anything is copied and tells you which.
2. Asks the other server to create the website — the same kind, with its own account, its own database and, for PHP and WordPress, its own PHP pool. The database keeps its password, so the settings file your app already has works there unchanged.
3. Sends its files — while the website is still serving.
4. Pauses the website here. Its PHP, its Node.js process and its scheduled jobs stop, so nothing can be written from here on. Nobody can sign in to its account over SSH meanwhile, a terminal open on it is closed, and anything else still running as its account — an upload, a worker you started by hand — is ended and named in the move's log, because nothing starts it again. A static website is not stopped: nothing of it changes, so it keeps answering. A WordPress website's WordPress page shows what it last read until the move has ended: reading WordPress checks for updates, and that writes to its database.
5. Sends what changed since, and then the database.
6. Brings it up on the other server. That server puts the files and the database in place and measures them as they arrived, installs and builds a Node.js app, serves the addresses with the certificate that came along, gets the scheduled jobs ready — and then asks the website whether it answers.
7. Compares both copies — every table's row count, whatever the table is called, and a fingerprint of every file. Only when both sides match does the other server keep the website, and that is when its scheduled jobs start there — not a moment earlier, because until then this copy is the live one.
8. Parks this copy.

While it is on its way, the other server lists it as Arriving from another server and takes no changes to it. If a move stopped half-way and nothing is running any more, delete it there — the next move sends it again.

No backup is taken first, as it is for a shop: the move changes nothing of this copy — it is stopped, not deleted — so it is itself the way back. Your scheduled backups keep carrying it as before.

What goes with it: its files and its database; its name and its addresses, with which one is the main one and which only redirect; how it is built and served; a Node.js app's environment variables; its scheduled jobs, on or off as they were; where its code comes from — the repository, the branch, the access token or the deploy key it is read with, automatic deploys and their secret — and WordPress's own record. So Update on its Deploys page works there as it did here, and says the website is up to date straight away.

What stays with this copy: the older versions on Deploys (the live one travels and is that server's first), the database exports kept on the Database page, WordPress restore points, its logs, and this server's backups. SSH access stays too: who may sign in to its account is decided on each server, behind your password, so turn it on again on the website's Terminal page there if you use it.

An app with a time zone of its own

When the two servers' databases run on different time zones, a move carries what every stored time reads here, so that it reads the same there. "Reads" means through the zone this server's database runs on — which is how an app reads its dates, unless it sets a time zone of its own on its database connection (a timezone on a Laravel mysql connection, a driver that sends SET time_zone). Such an app reads through its zone on both servers, so for it the carried times come out shifted by the difference between the two databases' zones — its TIMESTAMP columns only; DATETIME columns and everything else are as they were. The panel cannot see what an app sets, so a website's move says so in its log: note: that is right for an app that reads its dates through the database's own time zone… Neither 6amMart codebase sets one.

If your app does: when the move has finished, open the website on the old server, export its database on its Database page — a parked copy can still do that, and that export holds every time as it is stored, not as it reads — and import the file on the website's Database page on the new server. Do it straight away: the import replaces what the website has stored there since.

It arrives with HTTPS

The certificate the project has here goes with it, so the moment you point its domain at the other server it answers over HTTPS — no warning, nothing to set up. The other server then gets a certificate of its own by itself (see Point your domains).

That holds for a project that is moved on again before its domain was ever pointed, and for one that is moved back: the certificate it arrived with travels with it a second time. (A server on a SixPanel from before 5 Oct 2026 does not send it on — update the server you are moving from first.)

A certificate that has run out does not travel. One that has expired, or will within a day, is of no use on the other server, and the move's log says so there. What that server does instead depends on the address: behind a proxy (Cloudflare) it answers with a self-signed certificate for now — which a proxy that does not check takes exactly as it took the expired one; an address that is not behind a proxy is served over plain HTTP until that server has a certificate of its own. Either way, press Get HTTPS in the project's Domain & SSL there once the domain points at it.

What "parked" means, and why nothing is switched over

When the move finishes, your domain still points at this server, and this server still holds the project with all of its data. The only thing that changed here is that the project is stopped: its PHP and its background workers stay off — also when this server restarts — so it is not taking new orders.

That is deliberate. An order placed on this server after the copy was made would never reach the new one, so the old copy does not accept any. It also means that from the pause until you point the domain at the new server, the project's address shows an error page. For an ordinary shop that pause is a few minutes — most of it is the other server building the customer website; for a website it is under a minute. Start a move at a quiet hour, and be ready to point the domain when it finishes.

One thing is still answered from the old server: what it had already cached. A WordPress website's cached pages go on being shown from that copy for as long as visitors keep asking for them — a page nobody asks for is dropped after an hour. A 6amMart project's apps are still handed the settings and lists they ask for all the time, dropped a minute after the last request. Nothing new is accepted either way — no order, no sign-in, no comment — and every page PHP would have to build answers the error page (a file that is simply on the disk, a picture or a script, is still handed out). So an old address that still shows its front page has not come back to life: it is the copy, and it goes when the domain points at the other server.

A parked website says so on every page of it. A note at the top reads This website was moved to …, Projects shows it as Moved to … — parked here, and its Overview answers moved instead of live. Until you start it again this copy takes no changes: a deploy, a new address, a changed setting or an edited file is refused with that sentence, nobody can sign in to its account over SSH, and no terminal opens on it. A push from your git host is refused as well — it shows there as a failed delivery, which you can send again once the address points at the other server. You can still read everything, export its database, and delete it. Its address shows an error page until the domain points at the other server — or, for a page this server had already cached, that copy, for as long as visitors keep asking for it. A static website's parked copy keeps answering with the same files, and takes no changes either.

A parked project says so too. A note at the top of every page of it reads This project was moved to …, with Start it here again beside it, and Projects shows it as Moved to … — parked here. Until you start it again this copy takes no changes, exactly like a parked website: an update, a rollback, a restore into it, a changed setting or an edited file is refused with one sentence that says where it went; its saved commands that run in the app wait instead of running against a database nobody is served from, and the panel's own nightly database care skips it; nobody can sign in to its account over SSH, and no terminal opens on it. A push from your git host is refused as well — it shows there as a failed delivery, which you can send again once the address points at the other server. You can still read everything, export or back up its database, stop one of its services, and delete it. (A saved command you set to run as root on the server is the server's own, not the project's, and runs as ever.)

While the move is still running the same note reads This project is being moved to …, with a link to Migration, and Projects shows Being moved. Until the move pauses the project it keeps serving and may be changed — what you change is sent again after the pause, and the note says so. From the pause until the move ends, nothing about the project can be changed here: every change is refused with one sentence that names the move, a push deploys nothing, its saved commands wait, and SSH access and the terminal stay closed. Reading is never refused. The note follows the move by itself: when it ends it turns into where the project went — or goes away, when the move failed and the project was started here again.

A project is not deleted while it is being moved — from the first line of the move to its last, paused or not. Delete, and Restore of a deleted project, are refused while any move, a migration of the whole server or the maintenance window is running, with a sentence that says which: both change how many projects the server is sized for, in the middle of a copy. Wait for it to end; Migration shows where a move is.

Do not start the project's PHP or its workers from a shell while it is being moved. The move checks at every step that its PHP has been stopped ever since the pause; a start — even one you undo again — means the project may have taken an order after the copy was measured, and the move stops there and starts the project here again. A worker is looked for at the two moments described below. One that you start and stop again in between is the one thing a move cannot see: the copy on the other server may then lack what that worker wrote.

A job that is running for the project when the move comes to pause it — an update, an import, a restore — is never cut off: the move stops there, before anything is paused, and says which job it was. Start the move again when it has finished. The same for database work started from the project's Database page — Run migrations, an import — and for a change that is still being made: a large archive being unpacked, a folder being copied. Such a change counts as under way until the panel has finished it, also when the browser tab that started it was closed or lost its connection long ago.

The pause also waits for other work on the server. A restart of the database or of Redis, an update of the server and a tuning change each stop every project's workers for a moment and start them again. A move that comes to pause the project in that moment waits — up to three minutes — for the workers to be given back, and only then pauses it; its log says waiting for other work on this server. If that work has not ended by then the move stops, with nothing paused.

And it is checked again, twice. Before the other server is asked to bring the app up, and again before this copy is parked, the move asks the server whether any of the project's workers is running. One that is has been taking jobs against a database that was already copied, so the move does not go on as if it had not: the first time it stops and starts the project here again; the second time — the other server has the app up by then — this copy is left running, not parked, and the message says which copy to delete. The move's log names the workers.

Close phpMyAdmin — and anything else that uses the project's database — before a move. The pause stops what the panel runs of the project. It does not reach what uses its database from outside: a phpMyAdmin tab that was signed in already, another website on this server that reads and writes this database, a database client, a script of your own. Open in phpMyAdmin is refused for a project or a website while a move has it paused; a tab that is signed in already keeps working, and so does a sign-in you type by hand. A saved command you set to run as root on the server runs as ever, too.

So the move asks the database itself. At the same two moments it asks MariaDB whether any table of the project's database was written to after it was copied — a website's move asks once, before the other server is asked to accept the website. If one was, the move stops exactly as it does for a worker that was running, and its log names the table and the time. A move that found nothing says so in its log: MariaDB reports no write to its database since it was copied. MariaDB can answer this for the tables almost every app uses (InnoDB and MyISAM), on a database that runs on UTC or a fixed offset, and it forgets the answer when the database server restarts — so this is a tripwire, not a proof. The rule in bold above still stands.

Nothing is deleted either: until you have looked at the project on the new server yourself, this copy is the one you can go back to.

So the last part is yours:

1. Check the project on the other server.
2. Point the domain at the new server's address.
3. When you are happy — a day later, a week later — delete the old copy here by hand. For a website, Also delete its DNS records starts unticked on the copy that was moved: the website still exists, and that record is the one you pointed at the other server.

To go back to the old copy instead:

• A shop — press Start it here again in the note at the top of any of the project's pages. What the move stopped starts again: its PHP, its queue and its scheduler (a worker you had switched off before the move stays off), and live order updates and the customer website if this project had them on. A worker that was switched on but had stopped by itself before the move — the park switched it off with the rest, so that a restart of this server would not start it on a parked copy — is switched on again too. Its SSH access opens again as it was. (Advanced → Services refuses to start a parked copy and points at this button; from a shell, sudo sixpanel --project <name> service start php does the same for the note — the project is then in use here again.)
• A website — press Start it here again in the note at the top of any of its pages.

Either serves exactly what it held when the move paused it. The copy on the other server is not touched, so two copies are then running: point the domain at the one you keep, and delete the other.

The panel will not do those three for you, and it will not decide which server is live. That decision needs somebody who can look at the project.

If the copies do not match

The move fails and says what differed — a row count, a file count, a total size, or a file whose contents changed. Your project is still live on this server: a shop's PHP and its workers are started again, a website is started again, what was made for it on the other server is removed, and nothing was switched over.

That is the point of comparing. "The copy finished" and "the copy is complete" are not the same claim.

Move everything to a new server

On Migration → Everything, pick the linked server and press Move everything. It runs from the server you are leaving, and moves onto the one you linked.

Before you start

• The new server should be empty. A fresh install from your provider is ideal. If it already runs SixPanel, that is fine too; it will not be reinstalled.
• Room: the new server needs space for your databases and uploaded files, with room to spare. SixPanel checks this for each shop and each website before it sends anything, and refuses rather than filling the disk.
• Open the same ports in your provider's firewall on the new server: 22 for SSH, 80 and 443 for your shops and websites, and the port your panel uses (Firewall and ports).
• Time: installing takes a few minutes; each shop then takes as long as its files and database need, and each website about a minute.

What it does, in order

1. Looks at the new server — is SixPanel there already?
2. Installs SixPanel if not, on the same panel port as this one, so your firewall rule and your bookmark still make sense.
3. Sends your settings — your mail server, your timezone and contact details, your blocked-address list, the addresses allowed to reach the panel login, and the email address your certificates are registered under (the new server issues certificates for the same domains; if it already has an address of its own, it keeps it).
4. Moves each shop, one at a time, exactly as the single-project move above does: a safety backup first, then the app, the uploads and the database, a comparison of both sides — every table's row count and every uploaded file — and then the new server brings the shop up and asks it whether it answers, before calling that shop moved.
5. Moves each website, one at a time, after the shops and exactly as the single-website move above does.

Above the button the page says which websites go and names the ones that stay, each with its reason; the question you confirm repeats it.

You can watch it step by step, and every shop and every website gets its own line: moved, not moved and why, or — for a website that cannot be moved — stays here.

What does NOT get copied, and why

Your new server keeps its own panel address, its own login and its own sessions. That is deliberate. Copying this panel's login and web address onto the new machine would give you two servers answering to the same address and the same session. The new panel is a new panel.

Where to find the new panel's sign-in. When this server installed SixPanel on the new one, it kept the new panel's address, username and first password for you. Open Migration → Servers (or Everything) and press Panel sign-in beside the new server: the three are shown there, each with a Copy button. Sign in, set your own password, then press Forget it so this server stops keeping it. It is stored on this server only, in a file only the system administrator can read, and it is never written into the migration's log.

The new server's card follows what happened. A link to an empty server starts out saying "reached over SSH, but SixPanel is not installed there". Once a migration has installed SixPanel on it, the card says "reached, SixPanel …" by itself, and One project offers that server from then on — you do not have to press Check again first.

Your first sign-in there. A panel this server installed has never been set up, so it opens on its short setup — your own password, an address for the panel, two-factor login — the same three steps as any new server. It does not ask again for what travelled (the language, the timezone, the certificate email). Its last screen counts the projects that were moved there and says what is left for you: point each project's domain at the new server. It never tells you to create your first project — your projects are already there.

If the new server already had SixPanel before the migration, nothing is kept — that panel already has a password, and it is yours.

Websites that stay

Some websites are not moved, on either tab. Both tabs name them above their button with the reason, the question you confirm repeats it, and the run's closing list names them again. A website that stays keeps running here; nothing about it is sent or changed.

• A website made with Create with AI. Its chat, its history and its preview address belong to the server it was made on. To take its pages along, keep its code in git (Keep the code in git), then create a static website or a Node.js app on the other server and connect that repository there.
• A staging site. It stays beside the project it is a copy of. Make a new staging site on the other server instead.
• A website with nothing live yet — no version deployed, WordPress not installed, or a PHP website with no files. There is nothing to move: create it on the other server and send its files there.
• A website that was already moved and is parked here. If this is the copy you want to move, press Start it here again on it first.

The old server keeps everything

Every shop that moved stays on the old server, with all its data, stopped — its PHP and its background workers are off, exactly as after a single move. So if anything looks wrong on the new server you can start that shop again here (Start it here again, in the note at the top of its pages), point DNS back and carry on. Every website that moved stays too, parked: Start it here again on its page brings it back.

Shops and websites are moved one at a time, and each one is offline from its own pause until you point its domain at the new server. You do not have to wait for the last one: point each domain as soon as its line says moved.

Once you are happy, delete the shops and the websites on the old server yourself, and cancel it.

If a shop or a website does not move

The migration keeps going with the rest and tells you which one failed and why. The one that failed is untouched on this server, still holding all its data and serving again, and anything half-built for it on the new server is removed automatically — so you can fix the cause and move that one on its own afterwards.

A migration where something did not move is reported as partly done, never as finished.

Pressing Move everything a second time is safe. What an earlier move parked on this server is not sent again by itself. A website that moved is not on the list. A shop that moved is listed as already on that server when it went to the server you are moving to and is still there, and as one that stays here, with where it went, when it went to another server — neither counts as a shop that failed. To move a parked copy after all, press Start it here again on it first: it is then the copy in use, and moves like any other.

Two cases are reported as not moved, because in both something is yours to decide. A shop you had already started here again is not called moved: if the other server still has its copy, the run says so — the two copies may differ. And a parked shop that went to the server you are moving to, which no longer has it, is in use nowhere: the run says so, and that starting it here is what sends it again.

The server keeps this note for every shop it moves from this version on. A shop an earlier version moved gets its note when the server is updated: from the server's own record of that move, and only while the shop's PHP is still stopped here. It is then listed as already on that server by this server's record of an earlier move — not moved again, and not a failure. That record cannot say whether you used the old copy here again in the meantime; if you did, the two copies differ, so the run adds what to do: start it here again and move it on its own. (When the record of that move is no longer kept, there is no note: the run tries the shop, the other server refuses it by name, and the message says that nothing needs moving if it is the same project.)

Point your domains at the new server

Nothing is switched over for you. DNS is never touched. Until you change your DNS records, customers keep reaching the old server. A project you have not moved answers there exactly as before. A project you have moved is stopped there, so its address shows an error page until you point it at the new server — it does not go on taking orders that the new server would never see. (What the old server had already cached is still answered from that copy; What "parked" means above says what that is.)

So point each moved project's domain at the new server's address as soon as it is moved.

HTTPS works straight away, and there is nothing to set up. The project arrived with the certificate it had on the old server, so the padlock is there from the first visitor. (The last lines of the move's log say what it arrived with. When that is not its real certificate — it had a self-signed one, or its certificate had run out — they say so, and what to press on the new server.) That certificate is a bridge: within about ten minutes of the domain reaching the new server, the new server gets a certificate of its own — by itself — and renews it from then on. Domain & SSL on the new server shows which one is in use; while it still says the certificate this project arrived with, it also says what it is waiting for.

A website tells you the same on its own pages. On the new server a note at the top of every page of it reads Moved here from … for as long as it answers with the certificate it arrived with. The new server gets its own once every address of the website points there — a website with two addresses waits for both — and the note then goes away by itself.

Two things can keep it waiting, and Server → Health names both: the domain does not point at the new server yet, or the new server has no certificate email (a server you set up yourself before the move may not — set one in Settings).

The customer website of a shop starts working when the domain points at the new server, not before. Every page of it asks your shop for its data at the shop's public address, and until you change DNS that address is still the old server, where the shop is paused. The move's log says so in plain words, a sentence a line — "its pages answer HTTP 500 for now: every page asks the shop at …", "That address does not reach this server yet: …" with what its check saw, and "While it still points at the server this project came from, where the shop is paused, that is expected: the pages work once it points here." It also checks the thing it can check: that the website is running, on the build the new server just made.

Health on the new server says the same while it waits. Its Customer website row is a warning, not a failure: "… answers HTTP 500 on this server: every page asks the shop at …, and that address does not reach this server", with "This project was moved here: while its domain still points at the server it came from, where the shop is paused, that is expected." The fix it names is the one thing to do — point that address at the new server. (If the website's own address already reaches the new server and the shop's does not, the row is a failure and says so: visitors are getting that error page now. Point the shop's address too.)

If the domain already points at the new server when the shop arrives, its pages are expected to work at once, and the move checks that they do. Should the shop's address reach the new server and still be refused on the way, the log names it instead — "That address answers HTTP 526 when it is asked the way the website asks it.", then "It reaches this server, and this server itself answers it" — and the lines under those say what to do, which is nearly always Domain & SSL → Get HTTPS on the new server.

If you pointed the domain before the move, its last lines do not tell you to point it again. Each address of what moved is asked whether a request for it still ends on the old server — with a file only that server holds, because DNS cannot say where a name behind Cloudflare points. When another server answers, the lines read "This move changed no DNS — and … no longer reaches this server: if it points at … already, nothing is left to point". The old server cannot see where the name points, only that it no longer comes to it — so if you pointed it somewhere else, that is still yours to put right. An address that could not be asked at all (it did not answer, or a proxy answered an error of its own) changes nothing: the usual "Point … when you are ready" stands. With several addresses, the ones still to point are named and the others get a line of their own; a run that moved everything says it once for all of them.

How to check it worked

On the other server's panel, the project should appear in Projects, with its domain, its database and its uploaded files. Open the shop and look at a product image — that is the quickest proof that the uploads arrived, not just the database.

A website appears in Projects there too. Its Overview says it is live, its Deploys page names the version that was live on the server it came from, and its Files and Database pages show what arrived.

If it went wrong

• One project says "This server has no named projects to move", and it has some — an older SixPanel said this on every server. Update SixPanel on this server (Update SixPanel itself) and open the tab again. If it still says so, it is true: the server has only its main project, and test copies of it.
• One project says "Not offered here: …" — for a server, its last check failed, so it is not offered as a place to send a project: on Servers, press Check now; the card says what failed. For a website, the reason is beside its name — see Websites that stay.
• "already has a project called …" — the other server has a project with the same short name, and a move never writes over one. If it is this very project, moved there earlier and in use there, nothing needs moving. To send this copy all the same, delete the one there (with Also delete its database, files and certificates ticked, or its name is held for seven days) and start the move again. Giving it another name does not help: only the name shown in the panel can be changed, not the short name a move goes by.
• "… already has …: an earlier move from this server took it there …" — this server keeps a note of every project a move parks. When the message says There is nothing to move, the copy here is still the parked one and the project is where you sent it. When it says this copy has been started again since, two copies are in use or were: decide which one you keep, and delete the other before you move again.
• "… already has …: by this server's record an earlier move took it there, and its PHP is stopped here" — an earlier version of SixPanel moved this project, and this is what the server still knows of it. If you have not used the old copy since, the project is where you sent it and there is nothing to move. If you did use it here again and stopped it afterwards, the two copies differ: press Start it here again on it, then decide which copy you keep before you move again.
• "An earlier move took … to …, which no longer has it as that move left it …" — the project was moved to that server and is not there any more (deleted there, or the server was rebuilt), and the copy here is still the parked one. Press Start it here again in the note at the top of its pages; it is then in use here again, and you can move it.
• "… still has a half-built … that an earlier move from this server left there" — a move that failed could not tidy up after itself, usually because the other server was not answering. Start the move again: the leftover is removed first. If it says so twice, delete that project on the other server.
• "… was moved to … and the copy here is the one that move parked" — a parked copy is not moved by itself. If it is the one you want to send, press Start it here again in the note at the top of its pages first, then move it.
• "this project's PHP and workers were started again automatically while the copy was still running" — a project a move has paused is never left stopped by a move that hangs: each step of the move is given an hour and a quarter, and when one runs past that, the project is started here again by itself. The copy can then no longer be trusted, so what was made on the other server is removed and nothing is switched over. The project is live here as before. Start the move again; if the other server was slow or unreachable, check it first. (A move that is working keeps its project paused for as long as it takes — a large shop is not cut off at a fixed time.)
• "… is still live HERE and was not parked: its PHP was started again here while … was bringing the copy up" (or "… its workers were started again here …", or "… its database was written to here …") — the other server finished bringing the app up, but this copy was no longer the stopped one by then: somebody started its PHP or one of its workers during the move, something wrote to its database, or that last step ran past its time. It may hold orders the copy there does not, so it was not parked and is running here as before. The copy on the other server is whole as of the moment the project was paused: delete it there (Projects, with its data), and move the project again at a quieter moment. When it was a worker or the database, the move's log names the worker, or the table and the time.
• "Something wrote to this project's database after it was copied (table …, … UTC)" (or "… this website's database …") — the move asked MariaDB, and a table of this database was written to after the copy was made. The panel had stopped everything it runs of the project, so it was something else: a phpMyAdmin tab that was still signed in, another website or app on this server that uses this database, a database client, a script of your own. Nothing was switched over; what was made on the other server is removed and the project is live here as before. The move's log names every table and the time (in UTC). Close what uses the database, then start the move again.
• "this project's workers were started here while the copy was still running" — the same, found earlier: before the other server was asked to bring the app up, one of this project's workers was running again — started from a shell, or by something outside the panel. It could have written to the database after it was copied, so nothing was switched over; what was made on the other server is removed and the project is live here as before. The move's log names the worker. Start the move again.
• "Database work is running on this project — a migration or an import, started from its Database page" — the move came to pause the project while Run migrations or an import was still at work. Pausing ends everything running as the project's account, and a migration ended half way leaves a database no version of the app matches. Nothing was paused or switched over, and the work goes on untouched; start the move again when it has finished.
• "Other work on this server has this project's workers stopped right now" — a restart of the database or of Redis, an update of the server or a tuning change was running when the move came to pause the project, and had not ended three minutes later. It starts the project's workers again when it ends, which must not happen under a pause. Nothing was switched over. Wait for that work to finish — Activity shows it — and start the move again.
• "… still holds … as the copy it was moved away from, parked" — you are sending a project back to the server it came from, which still has its old copy. Start that copy there to use it, or delete it there and move again.
• "cannot take …: a project called … was deleted on … and is kept until …" — the other server had a project of that name, deleted less than a week ago. It is kept for seven days so it can be restored, and it holds its name until then. On that server open Projects, find it under Recently deleted, press Restore, and delete it again with Also delete its database, files and certificates ticked — or wait for the date in the message. Nothing was copied, and the project here was never paused.
• "cannot take …: the website … already uses the short name …" — on the other server a website has the same short name; projects and websites share one set of names. Remove that website there first. Nothing was copied.
• "cannot take …: … is already served by the project / the website …" — the other server already serves one of this project's addresses. Remove the address there, or move that one first. Nothing was copied.
• "the address … is already in use on that server" — the same, for a website: the other server already serves one of its addresses. Remove the address there, or move that one first. Nothing was copied.
• "it runs on PHP …, which that server does not have" or "it is built with Node.js …, which that server does not have" — the website uses a version the other server has not installed. Add it there (PHP and Node.js versions), or move the website to a version both servers have, here, and start the move again. Nothing was copied.
• "cannot take …: a folder … / a database called … already exists and no project owns it" (a shop), or "… is already on that server and no website there owns it" (a website) — something of that name was left on the other server, where the project or the website would be made: by hand, or by a SixPanel that was installed there before. The message says which. A move never writes over it: it would replace what is in it, and take it away again if the move failed. Move a folder away on that server (sudo mv /var/www/<name> /root/). A database is shown on that server's Server → Database as not made by this panel, with its size and its tables — look at it there, and when you are sure it is not needed, press Remove beside it; a copy is kept first (Remove a database). Then start the move again. Nothing was copied.
• "cannot take …: an account called … already exists and is somebody's" (a shop), or "… is already on that server and it is not one a website left behind" (a website) — the other server has a system account with the name the project's or the website's own account would get, and it is somebody's: its home is another folder, or it can sign in. Remove it there (sudo userdel <name>), then start the move again. Nothing was copied. (An account SixPanel itself left behind when a project or a website was deleted is not refused — the move takes it over.)
• "… still holds … as the copy it was moved away from, parked" — you are sending a website back to the server it came from, and its old copy is still there. Open it there and press Start it here again to use that copy, or delete it there and start the move again. Nothing was copied.
• "has … files — more than the … a move can compare one by one" — a move proves the copy by fingerprinting every file on both servers, and this website has more than it can. Clear out what it does not need (a cache folder, old exports), or bring it over with a backup instead. Nothing was changed.
• "… started for this website while its files were being sent", "a change to … was still being made here" or "a new version … went live while its files were being sent" — a deploy, a build, an import or an upload began after the move did. The move stops rather than copy a website half way through a change. The website was not paused, the job goes on untouched, and nothing was switched over; start the move again when it has finished.
• "… started for this website just as it was being paused, and the pause ended it" — the same, a moment later: the job got in as the website was being stopped, and stopping the website ended it. Nothing was switched over and the website is running here. Run that job again here first, then start the move again.
• "… started for this project while its files were being sent", "a change to … was still being made here when the move went to pause it" or "… started for this project just as it was being paused, and the pause ended it" — the same three for a 6amMart project: an update, an import, a restore or an upload was under way when the move came to pause it. Nothing was paused (or the project was started again at once) and nothing was switched over. Let it finish — or, for the last one, run it again here — then start the move again.
• "…'s database runs on a zone with daylight saving time and this server's on another" — the other server's database still follows a time zone that changes its clocks in summer (an older server, whose owner picked such a zone when it was set up), and this server's database runs on a different one. A time that falls in the hour that zone skips each spring could not be stored there, so nothing was copied. On the other server open Server → Database, change its time zone to UTC — every date there keeps reading as it does — and start the move again.
• "The database on this server is in the middle of moving to another time zone" (or "…'s database is in the middle of …", or, said by the other server, "cannot take …: its database server is part way through moving to another time zone") — a change of the database's time zone was started on that server and has not finished, or was stopped part way. Until it is finished or put back, part of what that database holds reads on the old zone and part on the new. Open Server → Database there, finish it or put it back, then start the move again. Nothing was copied.
• "note: … cannot say which time zone its database runs on" in a move's log — the other server runs an older SixPanel (or its database did not answer). The move carries what every date reads here, which is right whatever zone that database runs on, unless it has summer time. Update SixPanel there to have that checked as well.
• "The times in this database were carried as they read here … and one of them would not go in" in a move's log, above a failed import — the two databases run on different zones, and a date read here is one the other zone cannot store (a date at the very edge of what a database can hold, or two rows that came to read the same time where only one may). Change this server's database to UTC first (Server → Database — it names the rows in the way), then move again.
• "SixPanel is not installed there" — for a single-project move, install SixPanel on the other server first, then link it again. A move of everything installs it for you.
• "has N GB free and this move needs about M GB" — the other server is too full. It needs room for the files plus the database import, not just the files.
• "is running an older SixPanel … it is missing: …" — the other server's SixPanel is older than this one and cannot receive a project — or a website — the way this one sends it. Update it there (Settings → Updates, or sudo sixpanel server update), then start the move again. Nothing was copied.
• "could not bring … up: it stopped at …" — everything arrived and both copies matched, but the app did not answer on the other server. The message names the step and the reason. The project was not marked installed there, so it is removed there and started again here, exactly as for any failed move.
• "the customer website is running here but its pages fail (…), although the shop's address … already reaches this server and the shop answers there" — one reason a move stops at Ask the app whether it answers here. Every page of the customer website asks your shop for its data at the shop's public address. That address leads to the other server, the shop answered there, the website was asked three times, and its pages still failed — so the fault is in the website itself on that server, not in DNS or a certificate. Open the website's log on the other server's Activity page (the job named in the message) to see the error; the project is started again here, and nothing was switched over.
• "its pages answer HTTP … for now: every page asks the shop at …", followed by "That address answers … when it is asked the way the website asks it" and "It reaches this server, and this server itself answers it" — a note in the log, not a failure: the shop moved. Its domain already points at the new server and the app answers there, but a request for the shop's address is refused before it arrives. The lines under those — one sentence a line — say what was answered and what mends it:
• "The proxy in front of … checks this server's certificate and refuses it (HTTP 526)", or "The website's own request to … checks the certificate it is answered with, and that does not pass" — the certificate. The next line says what that server has for the address — none, a self-signed one, one that has expired or does not name it — and what to press: Get HTTPS in the project's Domain & SSL on the new server. When the customer website's own address is in the same position a line names it as well; press it for that address too. If the line says the server serves the address with a real certificate already, look at the proxy's SSL mode for the domain instead.
• "… could not open an HTTPS connection to this server (HTTP 525)" — no HTTPS connection was made at all. When the next line says that server has no certificate for the address, Get HTTPS mends it. When it says the server does answer … over HTTPS, a certificate is not what is missing: look at the proxy's SSL mode and the TLS versions it speaks.
• "The proxy in front of … cannot reach this server", "Nothing answers for … when it is asked from outside", or "… gives no answer when it is asked from outside" — open ports 80 and 443 on that server and at its hosting provider.
• "… sends the request round in a circle" — a proxy that talks to the server over plain HTTP while the shop sends every request on to HTTPS. On Cloudflare, set the domain's SSL mode to Full — after Get HTTPS when the line says that server has no certificate for the address yet.
• "… answers HTTP … when it is asked from outside, and that is not the answer this server's app gave" — something in front of the server answered by a rule of its own (a 403 from a proxy's firewall, for one). Look at the proxy's settings for the domain.
• "Apart from that, this server has … certificate for …", under any of these — not what stopped the pages this time, and worth mending anyway: Get HTTPS for each address those lines name.
• "… is already in use on this server" — the other server already serves one of this project's addresses, for another project or a website. Remove the address there, or move that one first.
• The move failed part-way — nothing is lost. This project is still the copy in use on this server, with all its data, and its PHP and its workers are started again for you — a website is started again the same way. The move's log says so, and says it when something did not start again (see "This project is DOWN here" below). For a shop a safety backup was taken before anything moved, so there is a copy to come back to either way.

The half-built project on the other server is removed automatically, so you can simply fix whatever the message said and start the move again. SixPanel only removes a project or a website it created for that move itself: one you made on that server, or one with a shop installed, is never touched. If the tidy-up could not run — usually because the other server's panel was down, which is also why the move failed — the log says so, and the next move of that project to that server removes it first, by itself. You can also remove it by hand: in that server's panel open Projects, the project, Delete, with Also delete its database, files and certificates ticked.

• "the other server has not answered for … minutes" — the other server went quiet while it was working on a website: its panel stopped, the connection dropped, or the machine went down. This server stops waiting rather than keep the website paused. Nothing was switched over, and the website is started here again. When the other server is back, start the move again — it removes what the earlier try left there first. (A shop's move waits longer, up to an hour: a shop that has started arriving cannot be called back, so giving up early would start it here beside one that then finishes arriving there.)
• "… was asked to accept …, its answer never arrived, and it cannot be asked now — it may hold this website as its own" — the last thing a move does is hear the other server say "it is mine now". The connection dropped at exactly that moment, and it stayed down, so nobody knows whether it did. The website runs here again — it is never left stopped on a guess. When the other server answers, open its Projects page. If the website is listed there as an ordinary website, it moved: keep the copy you want and delete the other, and point the domain at the one you keep. If it is not there, or it says Arriving, start the move again — it tidies up there first. Until you have looked, treat both copies as possibly running.

Most of the time you never see this: when the answer is lost but the other server can still be reached, this server asks it again before it starts anything here, and either parks this copy (it had accepted) or has the website taken back there (it had not).

• "… has a website called … — and it may be this one" — the next move after that message. The other server holds a website of that name, and the last move from here never learned whether it was accepted. Open it there. If it is this website, it has moved: point its domain there and delete the copy here when you are happy. To move it again instead, delete it there first. Nothing was copied.
• A move's row says "the panel stopped while … was taking this website over" — SixPanel on this server was restarted (an update, a reboot) in the last seconds of a move. When it started again it asked the other server. If that server had accepted the website, this copy is parked and the row reads as a finished move. If it had not, the website runs here again and the next move tidies up there first. If it could not be asked, the website runs here again and the row says both copies may be running — look on the other server as above.
• "the copy could not be compared with the original" — everything was sent, but the other server could not be asked to count it (its panel stopped, or the connection dropped). This does not mean the copy is wrong; it means nobody could look. Nothing was switched over, the project is running here again, and the message names what could not be read. Check the other server (sudo sixpanel service status panel), then start the move again.
• "the copy does not match the original" — both sides were counted and they differ; the message names the table or the files. Nothing was switched over. Start the move again; if it says the same, send a problem report with the move's log.

Your domain and DNS are never changed by a move, failed or successful — so once a failed move has started the project again, customers reach it on this server exactly as they did before. It was offline only while the move had it paused.

• "this website was started again automatically while the copy was still running" — a website a move has paused is never left stopped by a move that hangs: after an hour and a quarter it is started here again by itself. This move had not finished by then, so its copy can no longer be trusted and is removed. Nothing was switched over. Start the move again; if the other server was slow or unreachable, check it first.
• "… was moved to …, and this copy is stopped so nothing new is written to it" — you tried to change a website that was moved and is parked here. Make the change on the other server; or, if this is the copy you want to keep, press Start it here again in the note at the top of its pages.
• "… is being moved to another server right now" — the same, while the move is still running: a change, a terminal, or turning SSH access on waits until it has finished. Migration shows where it is.
• "… is being moved to … right now and is paused for it" or "… was moved to …, and this copy is parked" — the same two for a 6amMart project. The first ends by itself when the move does. For the second, make the change on the server the project lives on now; or, if this is the copy you want to keep, press Start it here again in the note at the top of its pages. A push that arrives meanwhile is answered with the same sentence and deploys nothing — send it again from your git host afterwards.
• "This project is DOWN here: its PHP did not start again when the move stopped (…)" or, on Health, "its PHP did not start again after it was paused" — the move failed (the rest of the message says why), the project was given back, and php-fpm refused to load its settings at that moment — the words in brackets are php-fpm's own, and usually name a file and a line. The project's workers are running; its pages answer an error. The panel tries again every minute and starts it by itself as soon as php-fpm accepts its configuration; Advanced → Services → PHP → Start does it by hand. Fix what is named first — one bad line in ANY project's PHP settings is enough to refuse them all. The same sentence when the project's pause ran out by itself while the move was still waiting for the other server: the panel starts trying at once, without waiting for the move to notice, and the reason then reads this project's pause ended by itself and its workers were started again.
• "… was not parked and is DOWN here: its pause ended while … brought the copy up, and its PHP would not start again" — the same, at the worst moment: the other server finished, this copy had been started again meanwhile (its workers ran), and its PHP would not come back. Health says why. The panel keeps trying. The copy on the other server is whole as of the pause; delete it there and move the project again once this one is up. The sentence reads its workers ran or its database changed in place of its pause ended when that is why the move would not park this copy, and gave it back.
• A move's row says "the panel stopped while … was bringing this project up" — SixPanel on this server was restarted (an update, a reboot) while the other server was bringing the project up, or in the middle of parking it. If the panel stops while the other server is bringing the project up, it asks that server when it starts again — also when the row already says that server had answered: a copy that was deleted there since is not a reason to park this one. If that server has the project installed, and this copy is still the stopped one — its PHP stopped ever since the pause, none of its workers running — this copy is parked and the row reads as a finished move. If that server has not got it, what it had half-made is taken back at once — a landing still running there stops at its next step instead of going live — and the project runs here again. In a few cases the panel cannot make one copy of two by itself, and the row's reason then says which, and what to do:
• "… could not be asked afterwards — it may run … as its own": that server did not answer.
• "… had not finished and could not be told to stop: … may yet go live there": it answered that the project was not up yet, and then could not be reached to be told to stop.
• "… has it installed — but … was already running here again. BOTH are live": the project's PHP was already serving here when the panel started (its pause had ended, or it was started from a shell while the panel was down), and the other server has it too.
• "… but … was started here again after its pause. BOTH are live": its PHP is stopped now, and was started and stopped again from a shell after the move had copied it — it served in between, so it is not the copy a move parks.
• "… but … had workers running here again. BOTH are live": its PHP stayed stopped, and its queue worker or its scheduler was running when the panel started. This is what a restart of the whole server in those minutes does: a pause stops the workers and leaves them switched on, so the server starts them before the panel is up. They took jobs against a database the other server has a copy of, so this copy is not parked — it is simply the live one again, which is where those jobs belong. The panel's log names them.

In each of them the project runs here: open the other server, and if the project is installed there, keep one of the two and delete the other — an order taken on one is not on the other. Activity carries the same line.

• "… had not finished bringing … up when this server stopped waiting (…), and was told to stop" — the move waited its full allowance for the other server and the landing was still running. That server was told to stop before anything was started here — it stops as its next step begins, and starts nothing more — so there is one live copy: this one. Start the move again; if it keeps happening, the customer website's build on that server is what takes the time — its Activity page shows the landing's log. When the reason ends what is half-built there is NOT removed, that server could not be asked to remove it afterwards; the next move removes it first.
• "… would not bring … up, so nothing was started there and nothing was switched over — this project is still live HERE. It said: …" — the other server answered the request, and refused it. What follows It said are its own words: most often its panel was being restarted at that moment (the panel must be running to take a project a move sends). Nothing was started there, so there is nothing to wait for or to look at: start the move again.
• "… has … installed, and it may be this project: the last move from here never learned how bringing it up there ended" — that move ended on did not say how … ended or on a row that says the panel stopped while …, and the other server finished after all. This copy runs here too. Open the project on the other server: if both copies run, keep one and delete the other — an order taken on one is not on the other. To send this copy again, delete the one there first.
• "This project's workers were running again a moment after it was paused" — the move stopped the project's workers and, a moment later, systemd said one of them was running: other work on this server (a restart of the database or of Redis, an update) had just ended and started them, or a worker was between its hourly exit and its restart. The pause was taken back and nothing was copied after it; start the move again.
• "… did not say how bringing … up ended and could not be told to stop — it may still make that copy live" — the same, and the other server could not be reached at all. This project runs here; look at the other server before you do anything else, and if the project is installed there, keep one and delete the other.
• "… is not parked — it already runs here" — Start it here again was pressed for a project whose PHP is serving already (started meanwhile from a shell, or in another tab). There is nothing to start; reload the page.
• "… is not a copy a move parked, so there is nothing for this to start — its PHP is stopped" — the same press, for a project that is no longer the parked copy and whose PHP is stopped all the same: it was started here after the move and stopped again, or its PHP was stopped by hand. Start it on Advanced → Services.
• "… was not started here: its PHP did not start (…). Nothing was changed — it is still parked, exactly as the move left it." — Start it here again could not start the project's PHP, and the words in brackets are why — most often php-fpm refusing a setting in one of its files, which it names. Nothing else of the project was started either, so the copy is exactly as parked as before. Fix what is named (or ask whoever changed it), then press Start it here again once more.
• "… is still arriving from … and cannot be changed until that move has finished" — on the receiving server, the website or the project is not its own yet. If no move is running any more, delete it there — a project with its database and files, or its short name stays taken for the days a deleted project can be restored — and the next move sends it again.
• "… is arriving on this server from … — only the server that sent it may change it" — two of your servers each have a website of that short name and both are being sent to the same third one. The second is refused; nothing of the first was touched.
• "… table(s) with an unusual name could not be compared" in a shop's move log — the other server runs an older SixPanel that counts only tables with plain names (letters, digits, underscore). The move still compares every table both servers can count, and names the ones it left out. Update SixPanel on the other server to have every table compared.
• "its scheduled jobs did not start on …" in a move's log — the website moved and was accepted, but that server could not start its timers. It tries again when its panel next starts; the website's Cron jobs page there shows them.
• "note: the database was not asked whether anything wrote to it since it was copied" in a move's log — the message says why. Either MariaDB did not answer that one question, or this server's database still runs on a time zone with daylight saving time, where the answer could be wrong for one hour of the year (Server → Database moves it to UTC). The move goes on as it would have: everything else it checks was checked.
• "… other processes of its account were ended" in a move's log — something was still running as the website's or the project's account when it was paused: an SSH or terminal session, a timed job half way through, or a worker started by hand. The log names it. Nothing starts it again, on either server — start it yourself where the website or project lives now.
• "could not stop PHP for this project" — the move stops before anything is copied, and the project keeps serving here. The message says why; the usual cause is a PHP setting the server will not load, which Server → Health names.

Questions people ask

Do I have to move everything? No. Move one project at a time, as often as you like. Two servers can each run some of your shops and websites indefinitely.

Can I run a move twice? Yes. Shops and websites that already moved will be refused by name, because SixPanel never writes over an existing one.

Does my main project move? No. Every SixPanel has one, so it cannot be sent to a server that already has its own. If your shop lives in the main project, move it with a backup restore instead — see Backups.

Is the old server changed? Only that what moved is stopped there — a shop's PHP and its workers, a website's PHP, Node.js process and scheduled jobs — and that a moved website's account takes no SSH sign-in while its copy is parked. Nothing is deleted, no DNS record is edited, no certificate is removed: the copy that travels is a copy.

How long is my shop offline? From the pause until you point its domain at the new server. The pause itself is a few minutes for an ordinary shop and under a minute for a website — the big copy happens before it, while it is still serving.

Is my shop offline during a move? The one being moved is, from the pause until you point its domain at the new server. That is what makes the copy exact: nothing can be ordered, uploaded or changed on the old server after it was copied. Your other shops and websites are not touched.

Does a website made with Create with AI move? Not yet — see Websites that stay for how to take its pages along.

I am moving a shop in from somewhere that is not SixPanel. Different job, two other pages: Move an existing site here if you have SSH access to the old server, or Bring your shop here from files if you only have a zip and a database export.