Skip to main content

​
Overview

Every source environment registered to nxtMove has a stored credential that nxtMove uses for discovery, preflight, and migration. The credential is shared across every job against that source. This page covers how operators should design those credentials — scoping, least privilege, storage, and rotation.

​
Principles

One service account per source

Do not reuse a personal operator account for nxtMove. Create a dedicated service account in the source directory service and use it only for nxtMove — this keeps the audit trail clean and lets you rotate without impacting humans.

Scope to the datacenter you migrate

Assign the nxtMove role at the datacenter you are actually migrating — not at the vCenter root. This keeps blast radius small and prevents nxtMove from accidentally touching inventory in datacenters it should not see.

Separate read-only vs migration scope

For cautious rollouts, register the source with a read-only account for discovery and preflight first. Swap to the migration-capable account only when you are ready to run migrations.

Rotate credentials regularly

nxtMove stores source credentials securely and allows in-place rotation from the Dashboard or CLI. Build credential rotation into your standard operational cadence.
Create a dedicated role on the source vCenter and assign it to the nxtMove service account at the datacenter scope.
For discovery and preflight only, a read-only account with the System privileges above is sufficient. Add the Virtual Machine privileges only when you are ready to migrate.

​
Credential Storage

nxtMove stores source credentials in the platform secret store. Credentials are:
  • Encrypted at rest using the platform-managed encryption key
  • Never displayed after save — the Dashboard shows a placeholder on edit
  • Accessible only to the nxtMove control plane, which uses them to open vSphere API sessions on behalf of jobs
Operators cannot extract stored credentials in clear text from the platform.

​
Credential Rotation

Open the source details drawer

Navigate to Migration → Environments, select the source, and click Edit.

Update credentials

Enter the new username or password (or both) and click Test Connection to confirm the new credentials work against the source.

Save

Click Save. nxtMove re-encrypts the credential and closes any open session that was using the old credential.
Next discovery run uses the new credential.
Changing the username or password of an active source invalidates any in-flight discovery session. Re-run discovery after rotation so the inventory cache refreshes against the new credential.

​
Deleting a Source

Delete a source only when no active migration jobs reference it. nxtMove blocks deletion of a source that is the parent of any running job. After all jobs complete or fail, you can delete the source from the Dashboard or CLI, which also removes the stored credential.

​
Audit Trail

Source credential creation, update, and deletion events are captured in the platform audit log. Operators investigating an incident can trace which identity made credential changes and when, using the standard NxtSight audit tooling.

​
Next Steps

Prerequisites

Platform and project prerequisites for onboarding a source

Network Ports

Which ports must be reachable between nxtMove and source

Register Source

End-user steps for registering a source once credentials are ready