Migrate from Ploi, VitoDeploy or another panel

Moving to SrvYard from another panel does not mean starting from a blank page. Your old panel knows things that the server itself does not: deploy scripts, the list of daemons and scheduled jobs, domains, notes and settings. SrvYard can read them with a read-only API token and turn them into drafts. Separately, SrvYard can scan a server you already run, read what is really on it and adopt it.

This article explains both halves, the order to do them in, what is never copied, and what to check afterwards. It describes the import for Ploi and VitoDeploy, which differ only in where you create the token. For the second half, Adopt a site that is already on the server has the details.

Before you begin#

• Permission to run migrations. The Import / migrate pages need migrations:view and migrations:run, and adopting needs migrations:adopt. Owners and admins hold them. Managers can view only.
• A read-only API token from the old panel. SrvYard never needs write access there.
• Access to the servers. A panel import creates drafts only. To manage a real server you connect it afterwards: see Connect an existing server.
• Room on your plan for the servers and sites you bring over: see Plans and limits compared.
• Time. A big account takes a few minutes, because each site costs several calls to the other panel's API.

1. Open Import / migrate#

Choose Import / migrate in the sidebar. The page opens with this: "Bring a server you already run into SrvYard. Start with a read-only scan: it lists every site, worker, scheduled job, database and certificate, and changes nothing."

1. Import from another panel. Pre-fills SrvYard with what only your old panel knows. "Nothing is changed in the old panel or on any server."
2. Scan a server. Reads a server that SrvYard can already reach: the web server, PHP, supervisor, cron, databases, certificates and firewall. "Nothing is installed or changed, and secrets are never read unless you allow it."

The two work well together. Import first so that SrvYard knows the deploy scripts, then scan and adopt so that SrvYard knows what is really running.

2. Choose the panel and paste a token#

Press Import from another panel.

1. Where do you come from? Two choices: Ploi (servers, sites, deploy scripts, queue workers, cron jobs, databases and network rules) and VitoDeploy (your own VitoDeploy: the same through its API).
2. API token. Paste a token that can read. The text under it says what happens: "The token is checked with one read call, kept encrypted for an hour and deleted when you finish."
3. Verify and continue. SrvYard makes one read call to check the token.
4. What the token needs. Create it in the API settings of the old panel. Read access to servers and sites is enough: no create, delete or manage abilities. If the panel has a separate permission for environment files, grant it only when you want .env files read. The card changes with the panel you choose.

Under it, What happens to your data is a promise worth reading: the token and what it reads are encrypted and deleted when you finish, cancel or after an hour; environment files are only read if you ask, and only imported for the sites you tick; deploy scripts are shown next to their translation and never run; and passwords, private keys and storage secrets cannot be read through any panel API.

3. Pick the servers and review the drafts#

After Verify and continue, the page lists what the token can see: "N servers found. Each site costs several API calls, so a big account takes a few minutes."

• Which servers should be read? Tick the servers to import, with their address and the number of sites on each.
• Environment files. The switch Also read the .env of every site is off by default, because environment files hold secrets. If you turn it on, you still decide per site later whether the values are imported.
• Read N servers. Starts reading. Warnings then appear under Things to know before you apply, including what "Cannot be read through the API".

When it finishes you review a plan. At the top, totals tell you how many new drafts will be created, how many existing rows will be updated and how many are already there or skipped. Each server is a card with its sites, daemons, scheduled jobs, databases and firewall rules, each with its own tick box and a badge for what will happen to it. Deploy scripts appear next to their translation into SrvYard's own script, so you can see what changed. Recipes are listed too (organisation-wide scripts from the old panel).

Before the Create N drafts button is enabled you must tick "I read the deploy scripts. They are saved as drafts and run on the server only at a deployment you start." and choose whether to delete the token when the drafts are created, which is recommended. Press the button and SrvYard shows Drafts created, with counts of created, updated and skipped items.

Nothing is installed by this step. Servers wait for access, and sites say "Needs provisioning". Daemons, scheduled jobs and databases are records that are applied to a server once it is connected.

4. Scan the real server#

Now connect the server itself, so that SrvYard can read it: see Connect an existing server. Then go back to Import / migrate and press Scan a server.

1. Server. Choose the server to scan. SrvYard connects with the management key it already holds.
2. Start scan. "Usually done in under a minute. The report is kept for 30 days." Private keys, database passwords and password hashes are never read.
3. What the scan may read. A list of consent boxes. Open Exact commands under any of them to read the commands that will be run. Anything you leave unticked is not read, and the report shows that part empty.

The groups are: Server facts, Users and SSH access, Web server and PHP configuration, Processes and services, Background workers and scheduled jobs, Databases (metadata only), TLS certificates (metadata only), Firewall, Application folders and Git remotes. Two more concern the application's environment file.

1. Environment file key names. Reads only the names of the variables, not their values. Safe and useful for checking that nothing is missing.
2. Environment file values. Marked as sensitive. Leave it off unless you need SrvYard to carry the values over.

5. Adopt, then finish the move#

The scan report lists every site, worker, scheduled job, database and certificate it found, and lets you adopt them: SrvYard registers the sites and takes over management without moving anything. See Adopt a site that is already on the server.

Then finish the job:

1. Connect your Git host under Settings > Source control (see Connect GitHub), so the sites can pull code.
2. Deploy once from each site to create SrvYard's own release layout.
3. Check domains and certificates (see Get a free Let's Encrypt certificate), and only then change DNS if you are moving the site to a new machine.
4. Leave the old panel running a few days as a safety net, then cancel it.

Troubleshooting#

• "Verify and continue" says the token is not valid. It was copied incompletely, has expired or belongs to another panel. Create a new read-only token and paste it again.
• The token cannot see any server. It belongs to an account or team without servers, or it was limited to resources that do not include them. The page says "The token cannot see any server."
• The import expired. A token is kept for an hour. The page says "This import expired". Start again with a new token.
• Environment values are missing. They were not read. Start again with Also read the .env of every site switched on and a token that may read environment files.
• Drafts exist but nothing runs. That is expected: servers wait for access and sites say "Needs provisioning". Connect the server, then adopt or deploy.
• The scan cannot connect. SrvYard needs the server to be connected first, with its management key. See Connect an existing server.

Related#

• Adopt a site that is already on the server: take over what the scan found.
• Connect an existing server: give SrvYard access to the machine.
• Connect GitHub: let the imported sites pull their code.
• Write and test a deploy script: check the translated deploy scripts.