Devices
Devices are the foundational asset type in Clarity Migrate. Every virtual machine, physical server, and workstation in your migration scope lives here. Accurate device records drive wave planning, dependency graphs, dashboards, and Nutanix Move execution.
Overview
The Devices module is the primary inventory register for all compute assets involved in your migration project. Each device record captures identity, configuration, ownership, and migration assignment — giving your team a single source of truth throughout the entire migration lifecycle.
Devices feed directly into migration wave planning (via Move Groups), capacity planning (by aggregating CPU and memory), and the execution layer (Nutanix Move pulls device records to create migration plans). They also drive dependency analysis: when applications and databases are linked to devices, Clarity Migrate can surface which assets must be co-migrated.
The Device List page is a full-featured DataTable with column-level filtering, bulk edit, inline editing, and export. The Device Detail page shows all relationships, history, execution status, replication metrics, and data quality scores.
When to use this
- Initial inventory: Import or manually register all in-scope servers at project kick-off.
- Scoping: Mark devices as in-scope or out-of-scope as the migration scope is agreed with stakeholders.
- Wave planning: Assign devices to Move Groups aligned to migration waves.
- Discovery updates: Add newly discovered servers that weren't in the original inventory.
- Pre-migration checks: Review the Device Detail page to confirm all fields are populated before execution begins.
- Post-migration: Use execution and replication screens to track cutover status per device.
Key features
Step-by-step instructions
Adding a new device
At minimum, complete the following required fields:
- Name — the hostname or display name of the device
- Environment — Production, Development, Test, or DR
- Scope — In Scope or Out of Scope
Editing a device
Enter to save or Escape to cancel. Useful for quick field corrections.Bulk editing multiple devices
Assigning devices to a Move Group
Exporting device data
Important fields
| Field | Required / Optional | Description |
|---|---|---|
| Name | Required | The hostname or display name of the device. Should match the actual system hostname where possible. |
| IP Address | Optional | Primary IPv4 address. Used for network mapping and deduplication during discovery imports. |
| FQDN | Optional | Fully Qualified Domain Name. Important for applications that reference servers by FQDN rather than IP. |
| Operating System | Optional | OS name and version (e.g., Windows Server 2019). Use normalisation rules to standardise OS naming across imports. |
| CPU Count | Optional | Number of vCPUs or physical cores. Feeds into capacity planning calculations for target hosts. |
| Memory (GB) | Optional | RAM in gigabytes. Used alongside CPU Count in capacity planning dashboards. |
| Scope | Required | Indicates whether this device is In Scope, Out of Scope, or Unknown. Only In Scope devices appear in migration dashboards and planning views. |
| Environment | Required | The environment tier: Production, Development, Test, or DR. Drives dashboard segmentation and migration sequencing rules. |
| Owner | Optional | The person or team responsible for this device. Used in email notifications and RACI reports. Set this to avoid missed notifications. |
| Migration Plan | Optional | The high-level plan for this device (e.g., Rehost, Replatform, Retire). Useful for portfolio analysis and executive reporting. |
| Move Group | Optional | The Move Group (wave) this device is assigned to. Links the device to a migration event for execution scheduling. |
Example workflow
During a pre-migration health check, a migration engineer notices a server called
APP-SVR-042 responding on the network but missing from the CMDB. The server
hosts a legacy batch-processing service that was overlooked during initial scoping.
The engineer navigates to CMDB → Devices, clicks + Add Device,
and enters the hostname, IP address (10.10.5.42), FQDN, and operating system
(Windows Server 2016). They set Environment to Production,
Scope to In Scope, and assign the device owner to the application team lead.
With the record saved, the engineer navigates to the Device Detail page, opens the
Relationships tab, and links the device to the BatchProcessor application
already in the CMDB. They then return to the Device List, select APP-SVR-042,
and use Bulk Edit to assign it to the Wave 2 — App Servers Move Group.
The device now appears in the Wave 2 capacity planning view, the data quality score prompts the engineer to add CPU and Memory figures, and the application team lead receives an automated notification that they have been assigned as owner of a newly registered asset.
Tips & best practices
The Environment field is used to segment devices in migration dashboards, capacity planning views, and executive reports. Leaving it blank means the device won't appear in environment-based filters and aggregations. Set it at the time of record creation — don't come back to fix it later.
When assigning dozens of devices to a Move Group, use Bulk Edit rather than editing each record individually. Filter the Device List to your target subset first (e.g., Environment = Production, Scope = In Scope), then select all and bulk-assign the Move Group in one step.
Only devices with Scope = In Scope appear in migration dashboards, wave planning views, and capacity calculations. Out-of-scope devices remain in the CMDB for reference but are excluded from planning. Review the Scope field whenever you add a new device.
For large inventories, use the CSV Import or VMware/RVTools integration rather than adding devices manually. This ensures consistent data quality and saves significant time. See the Integrations section of this guide for details.
Common mistakes
If the Owner field is blank, email notifications for this device will not be sent. This means the relevant application or infrastructure team won't receive pre-migration warnings, T-Minus task assignments, or post-migration confirmation requests. Always assign an owner at the point of record creation.
A device with Scope = Unknown will not appear in migration planning dashboards, wave assignment views, or capacity calculations. It effectively becomes invisible to the planning process. Review all Unknown-scoped devices regularly and resolve them with your project stakeholders.
Free-text OS entries like "Win 2019", "Windows Server 2019", and "WS2019" all refer to the same OS but will appear as three separate values in filters and reports. Use the Field Management → Normalisation rules to standardise OS values across your entire inventory. This is especially important when data comes from multiple import sources.
If a device already exists from a previous CSV import or discovery run, adding it manually creates a duplicate. Before adding a device, search for its hostname, IP address, or FQDN to check for an existing record. Use the deduplication tools in the Data Quality screen to merge duplicates if they already exist.