Moving to Cloud v2

Cloud v2 uses organization and device UUIDs, browser sign-in through Wendy Auth, and an authorized service catalog for remote connections. Cloud v1 uses the legacy dashboard and numeric asset identities. They are separate enrollments. Updating the CLI or signing into v2 does not migrate a device, its applications, stored data, or access grants.

Start with the Cloud v2 guide for a new deployment. If you already operate devices on v1, keep their legacy context while you validate v2 on a spare device.

Compare the workflows

See tunnel limitations and service-account authentication. Do not assume a service account can replace a human operator for remote device access merely because its API sign-in succeeds.

Keep both contexts available

Update to the current CLI, then inspect your saved sessions:

wendy cloud status

If your legacy session is missing or expired, restore it with wendy cloud login --legacy. Add a v2 session with wendy cloud login and choose the intended organization in the browser. Use the context names shown by status to select each one:

wendy auth use <legacy-context-name>
wendy cloud discover --all

wendy auth use <v2-context-name>
wendy cloud discover --all

When multiple contexts exist, signing in does not necessarily change the active one. Verify the selected context before each operation. A saved default device also retains its Cloud and organization binding; switching context does not retarget that device. Select the new target explicitly when validating v2.

Inventory what the deployment depends on

Record the current device names and IDs, app manifests and image versions, persistent data locations, users, and access requirements. Include the exact ports and protocols used by dashboards, cameras, collectors, and external APIs. Check which scripts run unattended and how they authenticate.

If a workflow needs a custom application port or UDP tunnel, v2 requires the updated Cloud service and CLI and Wendy Agent 2026.10.22-211023 or newer. Test that exact port and protocol on the spare device, and keep the workflow on v1 until it passes. Check Companion's v2 support for the features your operators use, including cameras, app controls, logs, and notifications. App Store availability alone does not establish v1/v2 feature parity.

Validate a spare device

1. Sign into v2 with an owner or admin account and enroll a spare device using the Cloud guide. Confirm it appears in the correct organization.
2. Select that Cloud device explicitly, deploy the application, and check app state, logs, and expected output through the connection you intend to use.
3. Check every required external connection. Include custom ports, service accounts, notification recipients, and the intended Companion build.
4. For Data, verify capture, upload if required, and access to the resulting episode. For BI, verify the actual data connection and query result separately.
5. Restart the test device and confirm it reconnects and resumes the expected application behavior before scheduling the production change.

Move an existing device

Arrange a maintenance window and retain physical or local access. Back up required application data and configuration before changing enrollment. Confirm with the Wendy team how existing Cloud records, grants, and stored data will be handled for your deployment; this guide does not provide an automatic transfer.

Use the device unenrollment guide for your device's identity and installed versions, then enroll it in the intended v2 organization. Unenrollment changes credentials and can remove remote access. Flashing is not a substitute for revoking the previous Cloud identity.

After enrollment, update scripts and saved defaults to the new device identity, restore the required app assignments and grants, and repeat the checks from the spare-device validation. Keep the deployment's previous configuration and a local recovery path until the new setup is accepted. Switching CLI context alone does not restore a device's old enrollment.

If something does not work

See deployment troubleshooting for build, device, and application readiness failures.