# Move projects to another server > Source: https://test-allsweb.allsweb.net/sixpanel/docs/move-between-servers > Markdown for agents: https://test-allsweb.allsweb.net/sixpanel/docs/move-between-servers.md > Publisher: AllsWeb (www.allsweb.com) Part of: SixPanel documentation 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. Nothing has to be moved all at once, and a project you do not move keeps running exactly where it is. 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. (The same linking and single-project cards also appear under **Settings → Other servers** — one feature, two ways in.) **Your DNS is never touched, on either path.** Nothing is switched over for you. ## 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 on its own server for their peace of mind. **Everything** — this whole server, settings and all shops, 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. --- ## Move one project On **Migration → One project**, choose the project and the server, and press **Move it**. Read the confirmation before you press it. Then 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. **Pauses this project here.** Only this one. Your other shops keep serving. 5. **Sends the configuration, the uploaded files, then the database.** 6. **Brings the app up on the other server** — migrations and caches. 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. 8. **Parks this copy.** ### 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's background workers are stopped, so it is not taking new orders. Nothing is deleted. That is deliberate: until you have looked at the shop on the new server yourself, this copy is the one you can go back to. So the last part is yours: 1. Check the shop 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. 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 shop. ### 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, its workers are started again, 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 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 the port your panel uses (**[Firewall and ports](https://test-allsweb.allsweb.net/sixpanel/docs/firewall)**). - **Time:** installing takes a few minutes; each shop then takes as long as its files and database need. ### 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, and your blocked-address list. 4. **Moves each shop, one at a time**, exactly as the single-project move above does: a safety backup first, then the configuration, the uploads and the database, and then it compares both sides — every table's row count and every uploaded file — before calling that shop moved. You can watch it step by step, and every shop gets its own line: moved, or not moved and why. ### What does NOT get copied, and why Your new server keeps **its own** panel address, its own login and its own sessions. The installer prints them when it finishes — run `sixpanel info` on the new server to see them again. 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, and would make the address you were just given stop working. The new panel is a new panel; set its password the first time you log in. Certificates are not copied either. The new server issues its own, free, once your domains point at it. ### The old server keeps everything Every shop that moved stays on the old server, with all its data, just with its background workers stopped. So if anything looks wrong on the new server you can point DNS back and carry on. Once you are happy, delete the shops on the old server yourself, and cancel it. ### If a shop does not move The migration keeps going with the rest and tells you which one failed and why. The shop that failed is untouched on this server, still holding all its data, and anything half-built for it on the new server is removed automatically — so you can fix the cause and move that one shop on its own afterwards. A migration where some shops did not move is reported as **partly done**, never as finished. --- ## 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 your shops on the old server exactly as before — so there is no rush and no moment where a shop is unreachable. When you are ready, point each domain at the new server's address, then set up SSL there: **[Domains and HTTPS](https://test-allsweb.allsweb.net/sixpanel/docs/domain-ssl)**. ## 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. ## If it went wrong - **"already has a project called …"** — the other server has a project with the same name. Rename or remove it there; this will not write over an existing shop. - **"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. - **The move failed part-way** — nothing is lost. This project is still live on this server, with all its data, and its workers are started again for you. 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 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, the log says so and names what to remove by hand. Your domain and DNS are never changed by a move, failed or successful — so customers went on reaching the shop on this server throughout. ## 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 indefinitely. **Can I run a move twice?** Yes. Shops that already moved will be refused by name, because SixPanel never writes over an existing shop. **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](https://test-allsweb.allsweb.net/sixpanel/docs/backups)**. **Is the old server changed?** Only that the moved shops' workers are stopped. Nothing is deleted, no DNS record is edited, no certificate is removed. **I am moving a shop in from somewhere that is not SixPanel.** Different job, two other pages: **[Move an existing site here](https://test-allsweb.allsweb.net/sixpanel/docs/move-existing-site)** if you have SSH access to the old server, or **[Bring your shop here from files](https://test-allsweb.allsweb.net/sixpanel/docs/bring-your-shop-here)** if you only have a zip and a database export.