Application Details

Some projects may have information about applications that are not captured by the primary inventory source used by MigrationStudio.  For example, Apple applications or Web Apps.  In this case, project administrators can use an Excel source to manually import the information into MigrationStudio.  This document describes the fields that can be used.


For further information on data imports, please refer to 'Manually import migration data from Excel'.


Field NameDescriptionRequired?
Revision IDThe Revision ID is a unique reference created by MigrationStudio when an application is imported into the MigrationStudio database.  The use of this field will vary depending on the reason for a bulk import:
  • Creating a New Application: This field should be left blank when importing new applications. MigrationStudio will allocate a Revision ID as part of the import process.
  • Updating an Existing Application:The Revision ID is required to ensure the details in the bulk data import are mapped to the correct application. Revision IDs can be exported from MigrationStudio and manually integrated with the bulk data import file using Excel:
    • Switch to the AppTracker view (1) in MigrationStudio.
    • Click the Select All button (1) from the toolbar to select all applications.
    • Click the Export button and choose Excel (xml) from the drop-down menu (2).


Yes, when updating existing applications.
NameThe name of the application.  For example, Word.Yes, when importing new applications
VendorThe application vendor's name.  For example, Microsoft.Yes, when importing new applications.
VersionThe version of the application.  For example, 14.Yes, when importing new applications.
Boxed VersionThe boxed version of an application if using an off-the-shelf application (OTS).No
Also Known AsAlternative names that the application might also be known by.  For example Office Word.No
Rev MajorUsed to denote the major version of the packaged application (MSI, App-V, etc)No
Rev MinorUsed to denote the minor version of the packaged application (MSI, App-V, etc)No
ProcessThe application's process can be set during the import process.  

For example, if the application is already in UAT, this could be added to the import file to enable MigrationStudio to change the Process from the default value of 1. Identified to the current status of 5. UAT.		No
Sub ProcessThe application's sub-process can be set during the import process.  This should be used in conjunction with the Process section above to ensure the correct sub-category is selected.

For example, if 5. UAT is selected as the Process, the Sub-Process should be set to UAT Queue, UAT in Progress or On Hold.		No
DescriptionEnter a description of the application that is being imported.  For example, Word, part of the Microsoft Office suite.No
NoteNotes can be used throughout MigrationStudio to provide additional information about an application, action or decision. For example, Application added via manual data import.
No
LocalisationIf the application is available in a specific language, this should be recorded using the Location field.  For example, United Kingdom.No
TypeAn organisation might use different packaging technologies when deploying applications to their users.  The Type field allows an administrator to specify a particular packaging or delivery format.  For example, Citrix or MSI.No
PriorityThe priority of the application can be recorded using the Priority field.  Out of the box, an administrator can choose from Low, Medium and High. This field is often used to record the importance of an application during packaging.No
ComplexityThe complexity of an application can be recorded at any point during the packaging process.  Defining the difficulty of the packaging work is useful to understand the level of resources that might be required to complete the packaging.  Out of the box, an administrator can choose from Basic, Normal, Medium or Complex.No
Assigned ToWhen an application moves through the workflow, the individual that is working on the software should be recorded using the Assigned To field.No
ArchitectureApplications might have a different architecture for different systems or legacy platforms.  This should be recorded using the Architecture field.  For example, x84 or 64-bit.No
Estimated UsersThe Estimated Users field is used to project an approximate number of users that might require this application. This could be useful for validating license information or during early application rationalisation while inventory clients are still reporting usage.No
Date RequiredThe Date Required field records the date that an application is required to be ready for production.No
Is Core AppApplications that are core to the Windows build and should be delivered to all users are recorded using the Is Core App field.No
Master VersionThe Master Version checkbox is used to record the primary application version in a sequence of rationalised applications.No
Is ArchivedAny applications that have been rationalised will be marked as archived and moved from the primary application view.  When archived, the Is Archived checkbox will be ticked.No
Blueprint ID 1Applications can be linked to two Blueprints during each import.  The Blueprint should be specified using the Blueprint ID 1 field.No
Blueprint ID 2Applications can be linked to two Blueprints during each import.  The Blueprint should be specified using the Blueprint ID 2 field.No


Example

Creating new applications with the minimum information


In this example, the Type field will be automatically mapped to the matching field in MigrationStudio.  The remaining fields will need to be manually mapped:

  • App Vendor mapped to Vendor.
  • AppName mapped to Name.
  • App Version mapped to Version.

Renaming the headers in the source spreadsheet so that they match the fields in MigrationStudio will negate the need for manual mapping.