Move an existing site here

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).
• The 6ammart code installed here already (Install your 6ammart code). 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".

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

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:

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.

1. 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:

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

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

2. Run the database changes — do not skip this

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:

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

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.

"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.