Theme
Import users from another product Preview
If you are moving to SFTP.cloud from Syncplify Server, Cerberus FTP Server, SFTPGo, FileZilla Server, or a hosted service such as Files.com, Couchdrop or MOVEit, you do not have to create your users one by one. The Portal reads the user export of the product you are leaving, shows you what every account will become, and creates the accounts for you. Your files never move: each Storage Connector then reads the same export and points at the folders it already holds.
The import has two halves, in the two places where SFTP.cloud keeps its two kinds of facts:
- In the Portal (this page): the accounts, their passwords or keys, their allowed protocols and their sign in restrictions. The Portal never sees a storage path.
- On each Storage Connector: the folders, and which account may reach which folder with which permissions. See Import storage and access from a file.
Do the Portal half first. A Connector can only grant users it has already received from your site.
What you need
- The user export of the product you are leaving. The import file formats page says how to produce one for each product, and describes the SFTP.cloud CSV template you can fill from anything else.
- A site with an active subscription. Every active imported user takes one of the accounts your plan includes, exactly like a user you create by hand. Disabled users take none.
- The Technical or Admin role on the account (see Your team and their roles).
Run the import
- Open your site, then Users, then Import users.
- Drop the export file on the dialog, or choose it. Files up to 16 MiB are accepted; a very large Syncplify Server backup is better exported to CSV first.
- Leave the format on Detect from the file unless the preview says the file was not recognized. For a Cerberus export, enter the PBKDF2 round count from the server's settings.xml (5000 unless it was changed); the export itself does not record it.
- Decide whether to Import everyone as disabled. A disabled user takes no account from your plan, and you enable people in batches once their storage is in place. This is the safe choice for a large migration or a rehearsal.
- Choose Preview. Nothing is created yet.
Read the preview
The preview lists every account in the file and what it becomes.
| Column | What it tells you |
|---|---|
| In the file | The name exactly as the old product spelled it. |
| Becomes | The SFTP.cloud username. A Renamed badge means the old name held characters a username cannot carry (spaces, uppercase letters, backslashes) and was rewritten. The rewrite is deterministic: the Connector import arrives at the same name. |
| Sign in | How the person will sign in: an existing password carried across, a password read from the file, SSH keys only, or a generated password. |
| Folders | How many storage locations the file gives this account. The Connector half creates them. |
| Outcome | Ready will be created. Already exists is skipped, never overwritten. Cannot import names the reason. |
Above the table, the counts say how many accounts need a seat and how many seats are free. When the plan is short, either import everyone as disabled or add capacity first; the import stops cleanly at the ceiling and tells you which rows were not created.
Passwords
- Existing password (carried): the old product stored a password hash the import can carry. The person keeps signing in with the password they already know. The first successful sign in converts the hash to the form SFTP.cloud uses; nothing changes for the person.
- Password from the file: the export held the password itself. It is used as is, even when it falls below your site's password policy; the preview counts those rows so you can ask people to change them. The policy governs passwords chosen in SFTP.cloud, not passwords people already have.
- SSH keys only: the account signs in with its keys; there is no password.
- Generated password: the export held no password and no key. The import makes a strong random password for the account and shows it to you exactly once, in the result file at the end. It is not stored anywhere else.
What does not carry: unsalted MD5 passwords (old FileZilla Server versions), passwords of accounts a hosted service exports (no service exports password hashes), and the "must change password at next sign in" flag, which SFTP.cloud does not have yet.
Import
- Choose Import N users. Keep the window open; the accounts are created in batches and delivered to your site's server as it goes.
- If your site's server cannot be reached mid way, the import pauses. Choose Retry to continue where it stopped, or stop and rerun the import later: accounts already created are skipped.
- When it finishes, choose Download the result file. It is a CSV with the outcome of every row and the generated passwords. Keep it somewhere safe and hand the passwords out; you cannot download it again.
Imported users show an Imported badge in the Users list, and No storage yet until the Connector half is done. The filter row above the list narrows it to From an import and to No storage yet, so you can watch the second half land Connector by Connector.
Next: the storage half
On each Storage Connector that holds folders the file names, open Users in the Connector Admin UI and choose Import from a file with the same export. Start with the Connector that holds the home folders: your site's server treats the storage that was granted first as a user's home. Import storage and access from a file walks through it.
Rerunning an import
Running the same file again is safe on both halves. Accounts that exist are skipped, storage that exists is reused, permissions you changed by hand are left alone, and nothing is ever deleted. That is what makes a rehearsal possible: import everyone as disabled, walk the Connector half, sign in as one imported user, then enable the rest.
Cutting over
When the accounts and their storage are in place:
- Point people at your site's address (or your own domain, see Site settings).
- Expect a new host key. SFTP.cloud never copies the host key of another server, even when it could: a key that another party still holds is a key nobody can vouch for. SFTP clients warn once about the change; automated transfers that pin the old key need the new one.
- Tell people what changes: the address, the host key, and for accounts that received a generated password, the password. Usernames on a shared server carry your site's suffix (see Users).
- For a hosted service you are leaving, move the files last: a Connector can read the old service over SFTP and copy everything into your storage; see Storage backends and Transfers.
What the import never does
- It never overwrites an existing account, and never deletes anything.
- It never imports server settings, certificates, host keys, scripts or event handlers.
- It never stores a generated password; the result file is the only copy.