End-to-end process for building a complete, accurate CMDB from scratch using Clarity Migrate's integration capabilities. The first thing a migration team does at the start of a new project. A complete CMDB is the foundation for all migration planning.
Overview
Discovery is the process of finding and recording all assets that exist in your environment. Without a complete and accurate picture of your estate, migration planning is guesswork — you'll inevitably encounter surprises mid-migration when an unknown dependency surfaces or an untracked server goes offline during cut-over. Infrastructure discovery eliminates those surprises by ensuring every asset is catalogued before planning begins.
Clarity Migrate supports automated discovery via VMware vCenter, Nutanix Prism, Microsoft Azure, and Amazon Web Services. For any other source — physical servers, mainframe systems, network devices, or assets tracked in external CMDBs like ServiceNow — the CSV Import pipeline provides a flexible path to bring that data in. Each integration is designed to pull asset metadata, configuration details, and relationship data directly from the source, minimising manual data entry and reducing the risk of transcription errors.
This workflow has three phases. In the Connect phase you configure your integration endpoints and validate that all connections are working. In the Discover phase you run initial imports across all sources and review the results. In the Enrich phase you improve data quality — filling in missing fields, normalising inconsistent values, and mapping asset relationships — until your CMDB reaches the completeness threshold required for planning to begin.
When to Use This Workflow
At project kick-off — the very first step for any new migration engagement.
When expanding scope to new environments — adding a new data centre, cloud region, or business unit to an existing project.
After major infrastructure changes — following a hardware refresh, cloud lift-and-shift, or network redesign that changes your estate significantly.
When integrating data from a new source system — connecting a newly deployed vCenter instance, onboarding a Nutanix cluster, or adding an additional AWS account.
Quarterly as a health check — even on live projects, running discovery periodically catches newly provisioned assets that haven't been added to the CMDB and ensures scheduled syncs haven't silently failed.
Key Features
VMware vCenter Integration
Automatically discover all VMs, hosts, clusters, and datastores from one or more vCenter instances.
Nutanix Prism Integration
Pull VM and node inventory directly from Nutanix Prism Central or Prism Element endpoints.
Azure & AWS Cloud Discovery
Enumerate virtual machines, resource groups, and tags from Azure subscriptions and AWS accounts.
CSV Import
Import assets from any source — IPAM, ServiceNow exports, manual spreadsheets — using the flexible CSV pipeline.
Scheduled Recurring Sync
Keep your CMDB up to date automatically by scheduling integrations to run on a daily, weekly, or custom cadence.
Deduplication & Reconciliation
Intelligent matching prevents duplicate records when the same asset appears in multiple source systems.
Completeness Dashboard
Visual breakdown of CMDB completeness by field and asset type, with drill-down to individual gaps.
Normalisation Rules
Define automated rules to standardise inconsistent field values (e.g. OS names, environment labels) across all records.
Step-by-Step Workflow
1
Plan your discovery sources
Before touching the application, take stock of every system that hosts assets you need to migrate. Common sources include: VMware vCenter instances (each managing a set of hosts and VMs), Nutanix Prism Central or Prism Element clusters, Azure subscriptions (each subscription requires a separate endpoint), AWS accounts (each account requires a separate endpoint), physical servers tracked in an IPAM tool or ServiceNow, mainframe LPARs, and network devices. For each source, document the API endpoint URL, the type of service account you'll need, and whether any firewall rules need to be opened to allow Clarity Migrate to reach the API. Completing this inventory before you start prevents you from discovering halfway through that a critical vCenter instance wasn't included.
2
Create credentials in the Credential Vault
Navigate to Administration → Credentials → Add for each source system. Use dedicated service accounts rather than personal user accounts — this ensures that credentials don't expire when someone changes their password and that permissions can be scoped precisely to what the integration needs (typically read-only). Enter the credential name, username, and password (or API token for cloud sources). Make a note of the credential name for each source — you'll reference it in the next step when configuring endpoints. If your organisation uses a password manager or secrets management tool, ensure the service account passwords are stored there as well.
3
Configure integration endpoints
Navigate to Integrations → [Source Type] → Add Endpoint for each source system. Enter the endpoint URL (e.g. https://vcenter.corp.local for vCenter), select the credentials you created in Step 2, and configure any source-specific options — for vCenter, this might include selecting which datacentres to include or exclude; for AWS, you'll specify the region. Give each endpoint a clear, descriptive name (e.g. "vCenter — London DC", "Azure — East US Prod") so it's easy to identify in integration history and status panels. Save each endpoint before moving on.
4
Test all connections
For each configured endpoint, click Test Connection. Do not proceed to the import phase until every endpoint shows a successful connection result. If a test fails, the error message will indicate whether the problem is a network connectivity issue (firewall rule, incorrect URL), an authentication failure (wrong credentials, account locked, insufficient permissions), or a TLS/SSL certificate problem. Resolve each issue and re-test. A successful test confirms that Clarity Migrate can reach the source API, authenticate successfully, and receive a valid response — which is a prerequisite for a reliable import.
5
Run initial discovery
For each endpoint, click Run Sync Now to trigger the first import. The duration of the sync varies depending on the number of assets: a small vCenter instance with 200 VMs may complete in under a minute, while a large environment with 5,000 VMs across multiple vCenters could take 15–20 minutes. You can run multiple syncs in parallel — there's no need to wait for one to finish before starting another. Monitor progress in the integration status panel, where each sync shows its current phase (connecting, fetching, processing, complete).
6
Review import results
Navigate to Integrations → History to see the results of each sync. For each completed sync, review: the total number of assets imported (does this match your expected estate size?), any errors that occurred (individual record failures are normal in small numbers, but a high error rate indicates a data quality problem at the source), and the number of duplicates detected and merged. If the total asset count is significantly lower than expected, check whether any datacentres or resource groups were inadvertently excluded in your endpoint configuration.
7
Check CMDB for completeness
Navigate to Inventory → Completeness dashboard. This view shows your overall completeness percentage and a breakdown by field. The overall percentage represents the proportion of all field-value combinations across all assets that are populated. Note your starting completeness — it's common to see 45–60% immediately after initial automated discovery, since technical fields (hostname, IP, CPU, RAM) are well-populated but ownership and business context fields (Owner, Business Unit, Application Tier, Environment) are often missing. Identify the 3–5 fields with the lowest completeness scores — these are your enrichment priorities.
8
Identify missing data critical for planning
Some fields are particularly important for migration planning and must be populated before planning begins. Review the following fields and note which are largely empty: Owner (who is responsible for the asset), Environment (Production / Non-Production / DR), Business Unit (which part of the organisation owns the asset), Application Tier (Web / App / Database / Infrastructure), and Dependencies (what other assets does this one communicate with). If any of these are below 50%, prioritise them in the enrichment phase. Migration planning cannot proceed reliably without Owner and Environment at minimum.
9
Enrich data via CSV Import
The fastest way to populate missing fields for hundreds or thousands of assets is the CSV enrichment approach. Navigate to Inventory → Export to download the current CMDB as a CSV. Open the file in Excel and add the missing data — Owner and Business Unit typically come from HR systems or ServiceNow CMDB, while Application Tier and Environment may come from application team knowledge. Once the CSV is enriched, navigate to Integrations → CSV Import, select your file, and choose Update Existing mode (not Create New). Review the deduplication preview to confirm the import will update existing records rather than creating duplicates, then run the import.
10
Apply normalisation rules
When data comes from multiple sources, the same value is often represented differently: "Windows Server 2019" vs "Microsoft Windows Server 2019 Datacenter" vs "Win2019", or "Prod" vs "Production" vs "PRD". Navigate to Administration → Field Management → Normalisation. Create rules for fields that have inconsistent values — typically OS Name and Environment are the worst offenders. Each rule specifies a source pattern (e.g. contains "Win2019") and a target normalised value (e.g. "Windows Server 2019"). Once your rules are defined, click Run Normalisation to apply them to all existing records. This significantly improves the usefulness of CMDB filters and reports.
11
Map asset relationships
Relationship mapping is the most time-consuming part of enrichment but also the most valuable for migration planning. For each application, you need to know which devices it runs on (the hosting relationship) and which other applications it communicates with (the dependency relationship). Navigate to each application record → Relationships tab → Add Relationship. If your application portfolio is large, prioritise Tier 1 / business-critical applications first. Relationship data may be available from your existing ServiceNow CMDB, network discovery tools (if you have Infoblox, SolarWinds, or similar), or application team interviews. Correctly mapped dependencies are the foundation of wave design — assets in the same dependency chain must be migrated together.
12
Validate final completeness
Re-open Inventory → Completeness dashboard. The target before migration planning begins is 80%+ overall completeness, with Owner, Environment, and Business Unit at 90%+ each. If you're below 80%, drill into the remaining gaps — some may be assets where the data genuinely doesn't exist (e.g. decommissioned systems without an owner), in which case a placeholder or "Legacy/Unknown" value is acceptable. If large numbers of assets are still missing key fields, identify the responsible team, assign them an enrichment task, and set a deadline before planning begins. Once you reach 80%, you're ready to move on to the Migration Planning workflow.
Real-World Example
Acme Corp — Datacentre Migration Kick-Off
Acme Corp kicks off a major datacentre migration with a single administrator responsible for establishing the CMDB. On Day 1, the admin connects two vCenter instances (the London and Frankfurt datacentres), discovering 1,200 VMs. A Nutanix Prism Central cluster in a satellite office adds another 300 VMs. The Azure East US subscription — used for development workloads — contributes 140 VMs. By end of Day 1, the CMDB contains 1,640 assets, but completeness is only 52% — technical fields are fully populated, but Owner, Business Unit, and Environment are almost entirely empty.
Over the following week, the admin runs three enrichment cycles. First, a ServiceNow CMDB export is processed through CSV Import (Update Existing mode), populating Owner and Business Unit for 1,510 of the 1,640 assets. Second, application team interviews via email produce an Environment mapping spreadsheet, which is imported to set the Environment field for all assets. Third, normalisation rules are applied to OS Name (consolidating 23 distinct OS strings down to 8 standard values) and Environment (mapping "PRD", "Production", "Prod" all to "Production"). Final completeness: 83%.
The admin then schedules recurring syncs: daily for both vCenter instances (to catch newly provisioned VMs immediately), weekly for Nutanix (lower churn rate), and weekly for Azure (dev workloads change frequently but daily is overkill). Relationship mapping for the 45 Tier 1 applications is completed by the application owners using the bulk relationship import template. With completeness at 83% and Tier 1 relationships mapped, the team moves to the Migration Planning workflow.
Tips & Best Practices
Run all integrations before any manual data entry. It's tempting to start entering data the moment you have the system configured, but wait until all automated discovery has run first. You'll avoid duplicating effort on assets that would have been imported automatically, and you'll have a much clearer picture of which gaps actually need manual enrichment.
Use CSV Import for bulk enrichment, not record-by-record editing. If you have more than 20 assets that need the same field updated, export the CMDB, update the field in Excel, and re-import. The time saved compared to editing records individually is enormous — what would take days in the UI takes 30 minutes via CSV.
Set up scheduled recurring syncs immediately after your first run. Don't leave CMDB maintenance as a manual task. Configure recurring schedules on Day 1 so that newly provisioned assets are automatically added and changes to existing assets are reflected in Clarity Migrate. A stale CMDB at the start of cut-over is one of the most common sources of migration surprises.
Use the deduplication preview in CSV Import before committing. Before finalising any CSV import, review the deduplication preview screen carefully. It shows you exactly which records will be created as new vs updated as existing. If you see an unexpectedly high number of "Create New" records when you expected only updates, there may be a mismatch in the key field (usually hostname or IP address) between the CSV and existing CMDB records.
Common Mistakes to Avoid
Starting migration planning before CMDB completeness is 80%+. Every missing field you discover during planning — or worse, during cut-over — causes rework. If Owner isn't populated, you don't know who to notify when an asset is being migrated. If dependencies aren't mapped, you'll break applications by migrating assets separately that need to move together. Invest the time in enrichment upfront; it always pays off.
Running only one integration and assuming all assets are covered. It's common for assets to exist in systems you didn't initially expect. Physical servers might not appear in vCenter. DR systems might be in a separate vCenter instance that wasn't included. Always cross-check your CMDB asset count against the known estate size (check with infrastructure and operations teams). If the numbers don't add up, find the missing source.
Not setting up scheduled recurring discovery. A CMDB that's accurate on Day 1 but never updated becomes a liability. New VMs get provisioned, old ones get decommissioned, IPs change, applications get moved to new hosts. Without recurring syncs, your CMDB drifts away from reality, and you'll encounter surprises during cut-over that wouldn't have been surprises if the data had been kept current.
Skipping relationship mapping and discovering critical dependencies mid-migration. The most painful scenario in any migration is discovering at 2am during a cut-over window that Application A depends on Application B, which is still sitting in the old datacentre. Relationship mapping is tedious, but it's far less painful to do it in advance than to deal with unexpected outages during a live migration event. Start with Tier 1 applications and work outward.