Inventory File Usage
This guide explains how to work with the Inventory Mapping file used by Dr Migrate, including how it is auto-populated, how to validate the mappings, and how to manage special cases such as unassociated servers and backup replicas.
How the File is Populated¶
When using the Workload Mapping → Bulk Upload method:
Open Workload Mapping¶
Go to Discover → Workload Mapping and open the Bulk Upload tab.
Let Auto-Detect pre-populate¶
Auto-Detect populates key fields for you, including: - Assessment Scope - Application Name - Environment
Download the pre-filled template¶
Click Download Pre-Filled Template to generate a spreadsheet that includes: - Discovered servers - Operating system information - VM descriptions - SQL detection status - AI-populated fields in blue columns
These values appear in the blue columns of the template. You are only expected to edit these blue columns.
Key Columns to Complete¶
| Column | Header | Notes |
|---|---|---|
| B | Assessment Scope | In Scope if the AI has mapped it to an app; Out of Scope otherwise |
| C | Application Name | Name of the application the server supports, or Unassociated |
| D | Environment | Prod, Dev, Test, UAT, Unknown, or TBC |
Validating AI-Populated Data¶
The AI-generated mappings are a starting point. You are expected to:
Assessment Scope¶
- Confirm that servers marked In Scope are actual application servers.
- Exclude infrastructure VMs such as jumpboxes or test clones by marking them Out of Scope.
Application Name¶
- Consolidate inconsistent naming (e.g., BizTalk, BIZTALK Server, biztalk → BizTalk).
- Group all components of an application (web, DB, etc.) under the same application name.
- Leave as Unassociated if no link can be confirmed.
Environment¶
- Fill in the known environment for each server.
- If the environment is unknown or pending confirmation, enter TBC or Unknown.
- Do not infer environment from the server name.
Handling Unassociated Servers¶
Some servers may be marked as Unassociated. These are not confidently mapped by the AI but may still be relevant.
Sort and Group Servers¶
Sort and group by OS, Data Center, Power Status, SQL Detected, or VM Description.
Look for Patterns¶
Look for shared naming patterns or common descriptions.
Map to Applications¶
If a group of unassociated servers appears to serve a common purpose, map them to a new or existing application.
Mark for Review¶
If you cannot determine the specific application name, assign a descriptive name that clearly indicates the server's purpose. For example: - Infrastructure_Unknown - for infrastructure servers with unclear purpose - Support_Unknown - for support or utility servers - Legacy_Unknown - for older systems with unclear application names - Test_Unknown - for test environments
Avoid using "Unassociated" as the application name, as this makes it difficult to identify these servers in reports and visualizations. Choose a name that will be meaningful when reviewing the resulting data and insights.
Potential Application Review¶
The AI may also generate placeholder groups such as Potential_App_110 when it sees a pattern among servers but cannot determine the application name.
These potential applications appear in the Application Name column and are set to In Scope. They include supporting metadata to help you investigate: - Server count - Confidence score - Description, software, naming, and communication similarity
Find the potential applications¶
Review the pattern-detected (potential) applications surfaced by Auto-Detect in Workload Mapping.
Review Server Relationships¶
Review server relationships under the AI Analysis and Server Details tabs.
Replace Placeholder Names¶
If you identify the actual application, replace the placeholder name in the inventory file with the real application name.
Representing Multi-Role Servers¶
If a server supports multiple applications, it must appear in the file multiple times, once for each application it supports. Each row should reflect a distinct server-to-application relationship.
Example¶
| Server | Scope | Application Name | Environment | SQL Detected |
|---|---|---|---|---|
| SQL-SHARED01 | In Scope | HRSystem | Prod | Yes |
| SQL-SHARED01 | In Scope | PayrollSystem | Prod | Yes |
| SQL-SHARED01 | In Scope | AuditLogs | Prod | Yes |
Avoid listing a shared server only once and assuming Dr Migrate will map it to all applications.
Common Pitfalls to Avoid¶
Do Not Modify Server Name or Add Servers¶
- The Server field is auto-populated by Dr Migrate and should not be edited.
- Do not add new servers manually. This can cause upload errors or invalid mappings.
Backup or Replica Server Objects¶
Some servers may appear with names followed by a long GUID (e.g., STR-APP1_3ECE5A884CAA4EBB92C20E538519C988). These typically originate from backup or replication systems like Veeam or SRM.
These are not true servers but replication artifacts. Mark these entries as Out of Scope and ensure that the real, corresponding server remains In Scope if applicable.
Summary¶
When using the inventory mapping file:
- Only edit the designated blue columns.
- Validate scope and environment values.
- Use Unassociated or TBC where information is missing.
- Use the Potential Application Review process to rename placeholder applications.
- Represent multi-role servers with multiple rows.
- Exclude replication artifacts and avoid structural edits to the file.