# Move an existing site here

> Source: https://www.allsweb.com/sixpanel/docs/move-existing-site
> Markdown for agents: https://www.allsweb.com/sixpanel/docs/move-existing-site.md
> Publisher: AllsWeb (www.allsweb.com)

Part of: SixPanel documentation

**What this page is for.** Move a 6ammart shop that is already running somewhere else — aaPanel, cPanel, or any Linux server — onto SixPanel, with almost no downtime.

**You need**

- SixPanel installed, and this project's domain saved
  (**[Domains and HTTPS](https://www.allsweb.com/sixpanel/docs/domain-ssl)**).
- The 6ammart **code installed here already**
  (**[Install your 6ammart code](https://www.allsweb.com/sixpanel/docs/install-app)**). Transfer moves your
  *data* into that install.
- SSH access to the **old** server: its address, a user, and either that user's
  password or a private key.
- The path of the 6ammart folder on the old server.
- A quiet hour.

---

## What is copied, and what is not

**Copied**

- **Settings** — the important values from the old `.env` file: licence, mail,
  payment keys, `APP_KEY`, everything the shop needs to keep working.
- **Uploaded files** — product images, logos, documents.
- **The database** — every order, user, and shop setting.

**Not copied**

- **The code.** SixPanel installs that fresh — from your git repository or your
  zip — so the new server starts clean.

Your old server is only **read** from. Nothing on it is changed.

> **This cannot be undone** — anything already in this server's 6ammart is
> replaced by the old server's data. On a brand-new install that is exactly
> what you want. On a shop that has been taking real orders here, it is not.

---

## 1. Find the folder on the old server

You need the folder that contains `artisan` and `.env` — the "Laravel root".

| Old panel | Where it usually is |
|---|---|
| **aaPanel** | `/www/wwwroot/<site-name>/` — sometimes the folder itself, sometimes an `admin/` folder inside it. |
| **cPanel** | `/home/<user>/public_html/` for the main domain, or `/home/<user>/<subdomain-folder>/` for a sub-domain. |
| **A plain server** | Often `/var/www/<something>/`. Look at the web server's site configuration and go one level up from `public/`. |

Not sure? Log in to the old server and run:

```bash
find / -maxdepth 4 -name artisan 2>/dev/null
```

The 6ammart root is the folder that holds it, with a `.env` beside it.

## 2. Pick your moment

Orders placed on the old server **after** the database is copied do not follow.
Either do this during your quietest hour, or put the old site into maintenance
mode first.

## 3. Run the transfer

1. Open **Deploys**.
2. Open the section for moving a project from another server and start the
   wizard.
3. On the **old server** step, fill in:

| Field | What to enter |
|---|---|
| **Old server address** | the old server's IP address or hostname |
| **SSH port** | usually `22` |
| **SSH user** | `root`, or the aaPanel / cPanel account user |
| **SSH password** | leave empty if you paste a key instead |
| **6ammart folder on the old server** | the full path from step 1, starting with `/` |
| **SSH private key (instead of the password)** | paste the whole key file, if you use a key |

   Give either a password or a key — one of the two is required. A pasted key
   is used for this job and deleted when it finishes.

4. On the review step, read what will be copied, tick the box that says you
   understand the data on **this** server will be replaced, and start the
   transfer.

Watch the live log. In order, the panel:

1. Prepares SSH access and tests the connection.
2. Reads the old `.env`.
3. Writes it here, then puts this server's own database, cache and domain
   settings on top of it.
4. Copies the uploaded files, and sets their ownership to this project's own
   Linux user so PHP can write to them.
5. Copies the database out of the old server and loads it in here.
6. Applies database changes and rebuilds the caches.
7. Starts PHP, the web server, the queue worker and the scheduler.
8. Deletes the temporary key and the temporary database file.

How long it takes depends on your images and your database. Minutes for a small
shop, longer for a large one. You see live progress the whole way.

**Running it a second time is safe.** It re-copies the files and re-loads the
database.

## 4. Test before you switch anything

The site already answers on this server. Your visitors are still going to the
old one, because DNS still points there.

This is your one chance to check the new server with real data before any
customer touches it. Take it.

To do that, you tell **your own computer only** that the domain lives at the
new server. Every other computer in the world keeps going to the old one. The
file that does this is called the `hosts` file.

You need the new server's IP address. The **Domain & SSL** page shows it as
**This server's IP address (for the A records)**, with a copy button.

### The line you add

One line, the IP address first, then a space, then the domain:

```
203.0.113.10  your-domain.com
```

Use your real numbers and your real domain. If your site also answers on `www`,
add a second line for it.

### On Windows

The file is at `C:\Windows\System32\drivers\etc\hosts`. Editing it needs
administrator rights.

1. Press the **Start** button and type `Notepad`.
2. Right-click **Notepad** in the results and choose **Run as administrator**.
   Answer **Yes** to the question Windows asks.
3. In Notepad choose **File** → **Open**.
4. Paste `C:\Windows\System32\drivers\etc\hosts` into the **File name** box.
   The file will not show in the list until you change the file-type drop-down
   from **Text Documents** to **All Files**.
5. Add your line at the bottom. Choose **File** → **Save**.

If Notepad says the file is read-only or cannot be saved, you did not open it
as administrator. Close it and start again at step 2.

### On Mac or Linux

Open Terminal and run:

```bash
sudo nano /etc/hosts
```

Type your own computer's password when it asks. Move to the bottom with the
arrow keys, add your line, then press **Ctrl+O** and **Enter** to save, and
**Ctrl+X** to leave.

### Check that it took effect

Open a **new** browser window in private or incognito mode and go to your
domain. Browsers hold on to old answers, so an old tab may still show the old
server.

To be certain, open Command Prompt on Windows or Terminal on Mac and run
`ping your-domain.com`. It prints the address it is using. If that is the new
server's IP address, the line is working.

Your browser may show a certificate warning here. That is expected while DNS
still points at the old server: the new server cannot get a certificate for a
name that does not resolve to it yet. Continue past the warning for this test.
Step 5 gets the real certificate.

Now log in to the shop admin, open an order, and check that images load.

### Remove the line when you are finished

> **Do not skip this** — the line pins your domain to one fixed IP address on
> your computer, and it stays pinned after you switch DNS in step 5. You could
> never tell whether the real switch worked. Worse, if the server's address
> ever changes, or you put Cloudflare in front of the site, yours is the one
> computer that cannot reach your own shop. People lose hours to this.

Open the same file the same way, delete the line you added, and save.

## 5. Switch the domain over

1. If you can, lower the domain's TTL to 300 an hour beforehand.
2. At your domain provider, change the **A record** to this server's IP
   address. If Cloudflare is connected to the panel, the panel can create the
   record for you instead — proxied, so the address stays hidden.
3. If the certificate was not issued yet — because DNS pointed elsewhere — get
   it now: **Domain & SSL** → **Get free SSL**.
4. Open **Server → Health** and check everything is green.
5. Run a first backup: **Backups** → run a full backup.
6. Leave the old server switched off but not deleted for a few days, then
   cancel it.

---

## Bringing a dump and uploads by hand

Use the transfer wizard above whenever you can — it does all of this for you.
This section is for the other case: you have no SSH access to the old server,
only a `.sql.gz` file and a folder of uploads someone sent you.

> **Three of these four steps are easy to miss, and each one looks like the
> site is simply broken.** Do all four, in this order.

**1. Import the database**

```bash
sudo sixpanel db import /root/your-dump.sql.gz
```

**2. Run the database changes** — do not skip this

```bash
sudo sixpanel db migrate
```

A dump taken from an older 6ammart than the code installed here is missing
tables the new code needs. Without this step every page shows a **500** error
naming a table that does not exist, even though the import said it succeeded.
It takes a few seconds.

**3. Put the uploads in place, then fix their ownership**

Unpack your uploads into `/var/www/admin/storage/app/public/` — then give them
to the project's own Linux user:

```bash
sudo chown -R six-default:six-default /var/www/admin/storage/app/public
```

> **Ownership is the step people skip, and it fails in a confusing way.** Your
> project's PHP does not run as `www-data` on this server. Each project runs in
> its own PHP-FPM pool under its own user — `six-default` for the first
> project, `six-<short id>` for any other. Files left owned by `root` or by
> `www-data` are readable but not writable, so pages render and then the app
> fails the moment it tries to write its own log or a new upload. Use the
> project's own user, exactly as above.
>
> For a project other than the first one, the path and the user both carry its
> short id: `/var/www/<slug>/admin/storage/app/public` and `six-<slug>`.

**4. Clear the caches**

```bash
sudo sixpanel cache clear
```

**Then check it:** `sudo sixpanel doctor`. Every line should be a green tick
except the ones about things you have not set up yet (backups, SSL).

---

## How to check it worked

- The transfer log ends by saying the site now runs at your domain.
- Your real orders, users and products are in the shop admin here.
- Product images load.
- **Server → Health** is green, and the queue worker and scheduler are running.

## If it went wrong

**The transfer section is not on the page**
That is deliberate. It hides itself once a working project is installed here,
so nobody overwrites a live site by accident. Move a shop **before** you
install anything else in that project.

**"this project is already installed and running"**
You reached the last step of the wizard on a project that already has a live
site. The panel stops and asks you to type a confirmation word before it will
replace it. Do not do that unless you have a fresh backup — the shop that is
here now is replaced completely. See **[Backups](https://www.allsweb.com/sixpanel/docs/backups)**.

**"could not read .env"**
The folder you gave is not the Laravel root, or the SSH user cannot read it.
Check it with the `find` command in step 1.

**Images are missing**
The folder was wrong, or uploads live somewhere else on the old server. Fix the
path and run the transfer again — the copy step lists what it moved.

**"invalid sshHost" / "remotePath must be an absolute path"**
The address or the folder is not in the shape the panel accepts. The path must
start with `/`, for example `/www/wwwroot/example.com`.

**Odd login or session behaviour after the move**
Clear your browser's cookies for the domain. Sessions from the old server do
not carry over.

**The old shop took new orders during the move**
Run the transfer again. It re-loads the database, which means anything that
changed on **this** server since the last copy is overwritten.

More causes and fixes: **[When something is broken](https://www.allsweb.com/sixpanel/docs/troubleshooting)**.