V1 to V2 Migration

V2 requires a new deployment, not an in-place upgrade

Overview

Floating Server V2 is a complete rewrite of the on-premises licensing server. Because V2 does not share a data store or API surface with V1, the migration is a new deployment rather than an in-place upgrade. V1 data is not read or imported by V2 , all configuration, users, and license records must be re-created from scratch.

What Changes in V2

Area	V1	V2
Data store	Legacy data store	SQLite or PostgreSQL
Provisioning	Manual CSR only	CSR or YubiKey, managed via Vendor Platform
API surface	V1 endpoints	Fully redesigned, new endpoints throughout
Configuration	config.yaml	default.yaml with expanded options
UI	Legacy interface	Redesigned React UI aligned with Vendor Portal
SDK compatibility	V1 SDKs	Requires SDK versions with V2 support

Server-Side Migration Steps

Plan for a migration window during which V1 remains live while V2 is stood up alongside it. Only decommission V1 once V2 is fully operational and validated.

1

Deploy The Floating Server as a new Instance

V2 must be installed as a new instance. Do not attempt to point V2 at an existing V1 data directory, V2 will not read it.

Follow the Overview & Installation guide to get a clean V2 instance running.

2

Re-Provision the Server

V2 introduces credential provisioning managed directly through the LicenseSpring Vendor Platform. Provision the new V2 instance from scratch, existing V1 provisioning credentials do not carry over.

Navigate to Enterprise Company → Licenses → Floating Servers → Provision the Floating Server and complete provisioning using either the certificate-based (CSR) or hardware key (YubiKey) method.

3

Recreate Configuration

V2 uses a default.yaml configuration file with a new structure. Your V1 config.yaml values cannot be copied directly. Recreate the configuration for V2, including:

• Database connection (SQLite or PostgreSQL)
• API or OAuth credentials
• Server port and sync interval
• Provisioning certificate paths

Refer to the Configuration & Provisioning guide for the full schema.

4

Re-Add Licenses and Users

V2 does not import V1 license records or user accounts. All floating licenses and user accounts must be re-added manually through the V2 Admin UI or API.

5

Validate V2 Before Decommissioning V1

Run V1 and V2 in parallel during the transition period. Validate that V2 is correctly handling license registrations, syncing with LicenseSpring Cloud, and serving SDK clients before taking V1 offline.

Client-Side Impact

SDK Clients (Recommended Path)

Client applications using LicenseSpring SDKs C++, .NET, Java, Python, Go, or node.js, do not need changes to their integration logic. The floating license flow (register, unregister, consume) remains the same in V2.

The only requirement is that SDK clients are updated to a version that supports V2 endpoints, and that the Floating Server address in the client configuration points to the new V2 instance.

Direct API Clients

If your application calls Floating Server API endpoints directly (not via an SDK), updates are required. V2 has a completely redesigned API surface, endpoint paths and request structures have changed. Review the V2 API documentation and update all direct API calls before decommissioning V1.

Migration Checklist

• Deploy a new Floating Server V2 instance on the target host
• V2 server provisioned via LicenseSpring Vendor Platform
• default.yaml configured with correct database, credentials, and sync settings
• All floating licenses re-added in V2
• All users and roles recreated in V2
• SDK clients updated to a version supporting V2 endpoints
• Client configuration updated to point to V2 server address
• Direct API integrations updated to V2 endpoint paths (if applicable)
• V2 validated in parallel with V1 before cutover
• V1 decommissioned after successful validation