Updates and upgrades#
Introduction#
There are 2 classes of software version changes for SFTPPlus:
updates, where the same first digit in the version number is kept, and
upgrades, where the first digit in the version number is incremented.
Updates add new functionality, fix defects, and improve security.
Upgrades include all of the above, but also remove functionalities and introduce backward-incompatible changes.
The backward-incompatible changes introduced in upgrades are typically due to increased security standards. However, for most such changes, there are backward-compatible options that can be manually enabled.
Upgrades are also used to remove support for obsolete protocols, outdated security mechanisms, and end-of-life versions of supported operating systems.
You can temporarily suspend automatic transfer activation during an update or upgrade to test transfers individually after restarting the updated installation. See activating and suspending transfers for the procedure.
Before proceeding with an update or an upgrade, ensure that SFTPPlus and all its file transfer services are stopped.
Then, make sure to backup the SFTPPlus configuration located inside the "configuration" directory of the installation path.
The previous configuration is automatically updated to the newer version as needed. Reinitializing the configuration or the service account and groups is not required.
Note
When configuration options are moved or renamed, values defined in external override files or cluster node variables require manual migration. Update those values to use the new option names and sections on each affected instance or cluster pool.
Consult the Server Release Notes, as they contain detailed information on the steps required for updating between specific versions.
Updating to latest version#
SFTPPlus version 6 was released in 2026. Version 6 is under active development and support.
To update from an older version 6 to the latest version 6 release, follow the general update procedure for your operating system.
It is important that you check the latest version and changes, as well as recommended update procedures in the Server Release Notes.
AS2 location profiles#
AS2 locations store local identity and remote partner settings in separate [profiles/UUID] INI configuration sections. Each [locations/UUID] section references these profiles through as2_local_profile and as2_remote_profile. Message transmission settings, such as encryption, signatures, compression, and MDN handling, remain in the location. The rules for which files to move remain in transfers.
Existing AS2 locations are automatically migrated when the configuration is loaded. The migration creates enabled local and partner profiles and updates the location to reference them. Existing AS2 identifiers, certificates, receiving URLs, HTTP credentials, and TLS settings are preserved. No manual conversion of existing AS2 locations is required when their values are defined in the main configuration file. Move any AS2 values defined through external overrides or cluster node variables into the corresponding profiles manually.
Update custom configuration templates or scripts that create AS2 locations to define and reference the separate profiles. See AS2 profiles for the new configuration options.
AS2 locations no longer offer the configuration Test action. Send a file through a transfer to verify AS2 delivery and receipt handling.
AS2 receiving services#
HTTP and HTTPS services now reference an as2-local profile through as2_local_profile to receive AS2 files. The profile's private_certificate replaces the service's as2_receive_private_certificate setting. The AS2 URL name is now configured on the local profile as as2_receive_name. The file paths and HTTP POST upload settings remain on each service.
Existing HTTP and HTTPS services are automatically migrated after vault items are migrated. The migration creates local AS2 profiles and updates those services to reference them. Services that used the same private certificate and receive URL name share one local profile. Distinct URL names result in separate local profiles, even when the services share a private certificate. Services without an explicit private certificate use the default server certificate and are migrated too. No manual conversion is required for AS2 settings defined in the main configuration file. Cluster node overrides for as2_receive_private_certificate are migrated with their services. If an external configuration template or script sets that option, update it to set private_certificate on the selected local profile. Existing service as2_receive_name values are copied to their local profiles. Previously empty receive URL names continue to use /as2receive; only an explicit / selects the root URL. Update external configuration templates and overrides to set the URL name on the selected local profile. Node-specific overrides of the old service option are not moved automatically; those nodes use the profile's URL until you move their overrides to the profile. Receiving file path and HTTP POST overrides remain on the service.
Update custom configuration templates or scripts that create HTTP or HTTPS services to define and reference an as2-local profile when AS2 file receiving is required. See AS2 profiles for the profile settings.
The service's selected local profile is used for all accounts receiving through it. The account's home folder, login credentials, groups, and source IP rules continue to control incoming AS2 transfers.
Accounts with AS2 trusted certificates and no explicit as2_partner_profile option are automatically copied to as2-partner profiles and associated through that option. The legacy as2_trusted_certificates option is then removed from each account. The migrated profile supplies trusted certificates for incoming signatures, the AS2 HTTP authentication requirement, and trusted HTTPS certificates for asynchronous MDNs. The account's legacy AS2 HTTP authentication value is transferred to the partner profile and removed from the account. When the legacy HTTP authentication requirement varies between the account's groups or nodes, migration requires HTTP authentication if any of those paths required it. Node-specific certificate and asynchronous MDN trust values remain node-specific on the migrated profile. The legacy group option is then removed from every group. An account without a selected partner profile cannot receive AS2 messages. The account continues to control login authentication and file storage. External accounts from HTTP and other external authentication methods cannot receive AS2 messages. The as2_trusted_certificates and as2_partner_profile keys are no longer accepted in external account responses.
Web Client generations#
The first-generation Web Client (ui-gen-1) is no longer available. Existing HTTP and HTTPS services configured for ui-gen-1 use ui-gen-2 when loaded. Upgrade to ui-gen-3 for the current Web Client. Choose ui-gen-2 if users still need to transfer files with Internet Explorer 11.
Updating from trial version#
Once you have obtained the full version of the software, follow the regular updating instructions using the full version software.
The configuration defined during the trial period is kept and automatically migrated to the fully-featured version.
Upgrading from version 5#
Review the compatibility and connector changes below before upgrading an existing SFTPPlus 5 installation to version 6. Complete any required connector installation and startup configuration before restarting SFTPPlus.
Deny usernames and ban IP authentication methods#
The deny-username and ip-time-ban authentication methods have been deprecated. They were replaced with the security policies. The configuration is automatically migrated.
LDAP Python API extension#
The LDAP Python API extension authentication support has been removed. There is no direct replacement for this extension in version 6. Contact us if you require assistance with migrating from the LDAP Python API extension. The configuration is automatically migrated.
Service configuration API#
The Web Manager JSON-RPC API now returns common and protocol options in the same service configuration object. For example, port and idle_connection_timeout are both direct properties of a service. The nested configuration object has been removed.
Update integrations that create services to send protocol options directly in the service object. For updates, use paths such as services/UUID/idle_connection_timeout instead of services/UUID/configuration/idle_connection_timeout. Read protocol options from the same flat structure in configuration responses and service startup snapshots. Update administrator role permission paths that target protocol options to use these flat paths. Python extensions that access a service manager must use service.configuration.OPTION instead of service.configuration.configuration.OPTION.
HTTP authentication and event handlers#
HTTP authentication methods and HTTP event handlers no longer support fallback URLs. Existing comma-separated URL lists are automatically migrated to their first value; all remaining values are discarded. HTTP event handlers continue to support retrying the configured URL using retry_count and retry_increase.
The obsolete legacy-webadmin HTTP event format has been removed. Event handlers configured with this format fail to start with an unknown format error. Update these handlers to use a supported format and ensure that the receiving endpoint accepts it. See the HTTP event handler configuration for supported formats.
HTTP authentication permissions#
HTTP authentication responses now support separate default_permissions and path_permissions members. The legacy permissions member is still accepted for compatibility. Its first list supplies default permissions, and subsequent lists supply path rules. If the first list is ["inherit"], default permissions are inherited and the account path rules are empty. Explicit default_permissions and path_permissions members take precedence over legacy values. See the HTTP authentication API for the current response format.
Event handler group filters#
The event handler groups configuration option has been renamed to event_groups to distinguish it from account group filters. Existing configuration files are automatically migrated, preserving the event group filters. If both options are configured, the event_groups value takes precedence, including an empty value. Update any custom configuration templates or scripts that use the old option name to use event_groups.
Analytics activity database#
Analytics now starts automatically with SFTPPlus and manages the embedded activity database. The separate sqlite resource and the analytics enabled option have been removed. The database path setting from resources/DEFAULT-SQLITE is automatically moved to activity_database_path in resources/DEFAULT-ANALYTICS. Custom database paths are preserved.
The default database file is renamed from configuration/cache.db3 to configuration/activity-records.db3 during configuration migration. Existing login and transfer records are retained. Update backup jobs and configuration templates that refer to the old path or resource.
If configuration/activity-records.db3 already exists, migration keeps the old database path and leaves both files unchanged.
Runtime and browser compatibility#
SFTPPlus 6 uses Python 3.14 and OpenSSL 4. Internet Explorer 11 is no longer supported by Web Manager or the third-generation Web Client. Use a modern browser to access these applications. The second-generation Web Client remains available for Internet Explorer 11 users.
IBM MQ and Microsoft Purview on Linux#
On Linux, the IBM MQ C client and Microsoft Purview SDK libraries are now available as extra connectors. Install the separate archive when upgrading if you use either connector. The extra-connectors guide describes how to extract the archive and set ownership of the connector directories.
For IBM MQ, update your installed systemd unit or other startup script to include the new library paths in LD_LIBRARY_PATH:
/opt/sftpplus/ibm-mq/lib64:/opt/sftpplus/ibm-mq/gskit9/lib64
Replace the old /opt/sftpplus/lib/ibm-mq paths and adapt /opt/sftpplus to your installation directory. Retain any other required directories already present in LD_LIBRARY_PATH. Follow the extra-connectors startup configuration instructions to apply the changes before restarting SFTPPlus.
Windows packages continue to include these libraries.
Migrating from node-based to pool-based cluster configuration#
In SFTPPlus version 6, the cluster configuration has changed from a nodes-based approach to a pool-based approach.
When migrating a cluster to v6 you will need to follow the following steps:
Upgrade the controller instance first
Upgrade each node instance
The pool configuration replaces the individual node configuration from earlier versions. Existing cluster-nodes/UUID sections are automatically migrated to cluster-pools/UUID, preserving their UUIDs and configuration options. An existing deployment can continue to use one pool per node.
Upgrading from version 4 or earlier#
If you are using SFTPPlus version 4 or earlier, you will first need to upgrade to SFTPPlus version 5. Once your SFTPPlus installation is on version 5, you can upgrade to latest SFTPPlus.
Reference documentation for upgrading to version 5. Version 5 is no longer in active development. Version 5 is still supported until 2029.