How to Import WinSCP Sessions into Naucturne

Recreating dozens of saved servers by hand is slow and error-prone. A transposed port or old remote directory can make a migration look like a connection failure. Naucturne therefore reads WinSCP’s exported session data and presents a preview before anything is saved.

The importer is intentionally selective. It migrates connection fields that Naucturne supports and flags data that cannot be decoded or mapped. Keep the original export until every critical connection has been verified, then remove plaintext or reversibly encoded copies according to your security policy.

What the importer supports

Step 1: export from WinSCP

Open WinSCP and use its export or configuration-backup command. Create either:

• a WinSCP .ini configuration file; or
• a WinSCP XML export containing the saved sessions.

Store the export in a temporary protected location. Depending on WinSCP settings, the file can contain usernames, reversibly encoded passwords and paths to private keys. Treat it as sensitive even when it does not display a plaintext password.

Step 2: open the Naucturne importer

In Naucturne, unlock the credential vault and open the site manager. Select Import from WinSCP, then choose the .ini or XML file.

Naucturne parses session sections and builds a preview containing:

• session name;
• protocol;
• host and port;
• username;
• password status;
• warnings for unsupported or incomplete sessions.

Supported sessions with a host are selected by default. Review the list rather than importing blindly, especially when the WinSCP file contains old customers or decommissioned servers.

Step 3: choose the destination team vault

The current importer targets a Naucturne team for which the user has the team encryption key. Select the correct team before confirming.

Each selected connection is recreated and saved through the normal credential service. Sensitive fields are encrypted for the target vault before cloud synchronisation. The imported WinSCP file itself is read locally; it is not used as the ongoing source of truth.

If no eligible team appears, confirm that the account belongs to a team and has received its encryption key. Do not work around the issue by pasting the export into a shared document.

Step 4: handle password warnings

WinSCP can store passwords with a documented reversible encoding based on the username and hostname. Naucturne can decode that format during import.

When WinSCP master-password protection is active, the importer cannot decrypt the saved value and marks the password for manual entry. This is expected behaviour, not a damaged export.

Re-enter the secret from its authoritative source. If nobody can identify that source, create or rotate the server credential instead of preserving an unknown shared password.

Step 5: reattach SSH keys and verify trust

The parser recognises WinSCP’s private-key file path, but the current conversion to a Naucturne credential does not copy or attach that key. Select the correct private key manually and protect it according to the operating system and team policy.

On the first SFTP connection, compare the SSH host-key fingerprint with a value obtained through a trusted administrative channel. An imported hostname is not proof of server identity.

For FTP or FTPS, verify the expected encryption mode and certificate. The same saved-site name can point to a changed or retired service years later.

Step 6: test before deleting anything

1. Connect to a non-critical site

   Confirm protocol, port, username and initial remote directory.

2. Check authentication

   Test the password or manually attached key without changing remote content.

3. Verify file permissions

   List the expected directory and perform a controlled transfer if authorised.

4. Review team visibility

   Ensure only the intended members can use files, terminal, database or DNS features.

5. Retire the export

   After all required sessions are validated, remove temporary export copies and document the new source of truth.

What is not migrated

The importer is not a full WinSCP configuration clone. It does not reproduce every interface preference, script, transfer setting, tunnel option, WebDAV or S3 profile. Private-key files are not copied. Unsupported protocols are explicitly skipped.

On Windows, Naucturne can also read sessions from the WinSCP registry when you choose that source in the importer. WinSCP folder hierarchies are not recreated as Naucturne folders, and importing the same file again does not deduplicate previously created sites.

WinSCP itself runs on Windows. To import on a Mac, create the INI or XML export on the Windows machine, transfer that sensitive file through a protected channel, then select it locally in Naucturne.

Naucturne’s product model is also different: a saved site can participate in an encrypted team inventory and open files, SSH, databases and DNS. Review permissions instead of assuming the WinSCP profile’s local ownership model carries over.

After migration

Open the imported site in dual-pane transfers, then add only the database and DNS profiles required for that customer. The guide to sharing SFTP access with a team covers permission and offboarding decisions.

For a visual overview of the supported migration route, visit Migration and import. For cryptographic details, read Naucturne security.

A successful migration is not the number of sessions imported. It is the number of current, verified connections that now have a clear owner, destination team and revocation path.