Introduction to migration rules 

Migration rules are used to define what happens to previously installed applications during an OS deployment. These rules can include usage criteria, allowing you to choose to only install previously installed applications if they were being used, or perhaps replace a rarely used application with a less costly alternative.

On this page:

A migration rule comprises the following elements:

Migration rule elementDescription
Rule type

Defines whether the rule will retain, upgrade or replace an application. An application will be removed during an OS wipe-and-load or device replacement if there is no rule defined. 

Source Application

Defines the application, identified by Vendor, Title, Version and Edition, that is to be migrated.

Target ApplicationDefines the application, identified by Vendor, Title, Version and Edition, that will be installed in place of the source application. For retain rules, the Target Application is the same as the Source Application. For upgrade rules, the Target Application is a different version of the Source Application.
Usage

Defines whether the source application will be migrated if it is used, rarely used, unused or any combination of these states. You can create multiple rules for the same Source Application with different usage settings. For example, you may want to retain an application if it is being used, but replace it with a cheaper alternative if it is not being used.

AssociationDefines the Configuration Manager Application or Package and Program that will install the Target Application. The association of a Configuration Manager Application or Package and Program with a Vendor, Title, Version and Edition can be made ahead of creating migration rules through Manage associations in the Tachyon Inventory app, or while defining the rule.

About Vendor, Title, Version and Edition

Application Migration identifies each application by Vendor, Title, Version and Edition as defined in the 1E Catalog. Some publishers use a 'colloquial version', such as 'Office 2019' or 'Acrobat Reader DC', to identify a broad major release, in addition to the full version that changes with each update. Where the 1E Catalog has a colloquial version defined for a given application, the Source Application and Target Application definitions in a migration rule will use the colloquial version. In some cases an application may have a mix of full versions and colloquial versions (typically when the adoption of colloquial versions came later in the product life cycle). Application Migration also includes the concept of a 'readable version', which is simply the full version truncated to the first two parts of the full version number (e.g. 16.0) to make managing rules easier.

When defining an Upgrade or Replace rules, the Source Application can be defined using a colloquial version (if available), readable version or full version. These rule types can also use a wild card (e.g. * or 16.*), which is useful for creating a single rule that will upgrade any version of an application to another version, or replace any version of an application with a different application.

If the selected Vendor, Title and Edition has already been associated with an Application or Package and Program in Configuration Manager, those associated versions will appear in bold at the top of the Version drop-down list when defining the target of any Migration rule or application in a Role-based Application set.

Understanding behavior of migration rules in different OS deployment scenarios

Migration rules will behave differently depending on the type of OS deployment being performed, If the existing OS is being reinstalled ('wipe-and-load'), or a new OS is being installed on a replacement device and you are using Application Migration to migrate applications from an old device, all migration rules will be applied. Any previously installed applications for which no migration rule has been defined will not be migrated (effectively these applications will be 'removed', although technically they are simply not reinstalled in the new OS. Replace rules will install the replacement (target) application in the new OS and the original (source) application will not be installed, so the application is effectively replaced in the new OS. 

An In-place upgrade behaves differently, as the disk is not wiped during an in-place upgrade, so the previously installed applications remain installed after the upgrade. For this reason, any rules defined to retain an existing application are ignored by Application Migration during an in-place upgrade as the application will be retained anyway. Upgrade rules will be applied, and in most cases the installation of the later version will simply upgrade the previously installed application. However, in some cases, installing a later version of an application on a device that has an older version installed may result in both versions being installed 'side-by-side' - this all depends on how the vendor has implemented their installer.

Rules defined to replace an application will result in both the original (source) application and the replacement (target) application being installed during an in-place upgrade. This is because Application Migration does not actually remove the source applications when replacing an application. However, you can use Application Supersedence in Configuration Manager (refer to https://docs.microsoft.com/en-us/mem/configmgr/apps/deploy-use/revise-and-supersede-applications for details on how to configure Application Supersedence to have Configuration Manager uninstall the replaced (source) application when the replacement (target) application is installed. 

Migration Rules and Management Groups

By default, migration rules are Global - they apply to all devices in your organization. In some cases you may want to define different migration rules for an application on different devices. For example, you may want to upgrade AutoCAD 2018 to AutoCAD 2019 everywhere except in the Seattle office, where they need to retain AutoCAD 2018 as they are working with a client on the older version. If you have Management Groups defined in the Tachyon platform, you can create rules that apply globally or to a specific Management Group. Management Group migration rules take precedence over Global migration rules, so in our example, you would create a Global rule to upgrade AutoCAD to 2019 and a Management Group rule for the Seattle Management Group to retain the 2018 version. Devices in the Seattle Management Group will apply the Management Group rule, not the Global rule,

It is possible for a device to exist in multiple Management Groups, so it is also possible for conflicts to arise, where a device is in multiple Management Groups, each with different rules defined. If this occurs, the rule will be shown as a Conflict on the Installations page that must e resolved in order for any rule to apply during OS deployment. Refer to Viewing and resolving migration rule conflicts for details on how to identify and handle this situation.

Adding Migration Rules

Migration rules can be added from the Installations page or the Manage Rules page.

Adding rules for installed applications

Typically, you will work from the Installations page to identify an installed application that you want to migrate, selecting it and clicking the Add Rule button. This will take you to the Add Rule page, but will pre-populate the Source Application Vendor, Title and Edition according to the application you selected in the Installations page. If you want to create a rule for a specific version of an application, from the Installations page click on the application title to view the installed versions and click the Add rule link in the Action column for the version you want to migrate. Again, this will take you to the Add Rule page, but with the Source Application Version pre-populated along with the Vendor, Title and Edition.

You will not be able to add a rule for a specific version if that version and usage combination is already covered by another rule, for example a wild-card upgrade rule.

The following pages provide step-by-step instructions for adding different types of rules from the Installations page.

Auto Install for Migration Rules

Application Migration uses the Install Application and Install Package steps in a Task Sequence to install migrated applications and packages. These Task Sequence steps are dependent on the relevant checkbox (auto install flag) being enabled for each application and package:

  • Allow this application to be installed from the Install Application task sequence action without being deployed
  • Allow this program to be installed from the Install Package task sequence action without being deployed.

If a checkbox is not enabled, the software installation will fail for that application or package. An administrator can enable this checkbox for each application and package by using either of the following methods:

  • in Configuration Manager during or after creating each application and package
  • using the Auto Install feature in Application Migration when creating application associations, rules or Role Based Application sets.

For information about manually enabling these checkboxes for Configuration Manager applications and packages, please refer to Using Application Migration in a Task Sequence: Auto Install for Configuration Manager Applications and Packages.

Application Migration's Auto Install feature is able to read the checkbox (auto install flag) for applications and programs, but in order for Application Migration to enable them for you, you'll need to configure related providers in the Settings application of the Tachyon Platform. These should already be configured as a post-installation step. For configuration details, please refer to Post-install configuration.

Once the provider configuration is configured, you can use the Auto Install feature to enable Configuration Manager checkbox from the Manage Rules page.

When you create or edit a migration rule you will be prompted to check Configure CM Application/Program to enable installation in a Task Sequence when you click Save and Close.

Save Rule

On the Manage Rules page, the Auto Install column displays a status for each migration rule. Our example shows two differant types of status, In-Progress and Not Checked.

Auto Install statusDescription
CheckedAuto install flag for Configuration Manager application or package program is set.
Not CheckedAuto install flag for Configuration Manager application or package program is not set.
In-Progress Application Migration has triggered an operation which attempts to set the auto install flag of Configuration Manager application or package program.
Failed Application Migration triggered an operation which failed while trying to set the auto install flag of Configuration Manager application or package program.
Not ApplicableA rule has broken association and the application migration report is not run.

Auto install column

If a rule has Auto Install unchecked, you will be prompted to edit that rule and set Auto Install to enabled. You can view this type of rule by filtering the Auto Install column by Not Checked.

You will also see a similar message on the following Application Migration pages and a prompt to take action if the Auto Install is unchecked:

  • Installation
  • Preview Device→Existing Device
  • Preview Device→New Device.

CM rule message

Adding rules for applications that are not reported as installed

The Installations page can be used to add migration rules for applications that are already installed in your estate. If you want to add a migration rule for an application that is not yet reported as installed on any devices in your estate, you will need to use the Manage Rules page.

  1. From the Application Migration navigation menu on the left, select Manage Rules.
  2. In the Manage Rules page, click Add (top right). 
  3. In the New Migration page screen, choose the rule type (Upgrade application, Replace application or Retain application as is) for the new rule. 
    1. If you choose to upgrade the application:
      1. In Source Application , choose the Vendor, Title, Version and Edition.
      2. Choose a Usage category (Any Usage, Used, Rarely Used, Unused or Unreported) the application must meet in order to be upgraded during the migration. If the application does not meet the criteria, it will not be installed.
      3. In Target Application, choose the Version and Edition to upgrade to.
    2. If you choose to replace the application:
      1. In Source Application , choose the Vendor, Title, Version and Edition.
      2. Choose a Usage category (Any Usage, Used, Rarely Used, Unused or Unreported) the application must meet in order to be upgraded during the migration. If the application does not meet the criteria, it will not be installed.
      3. In Target Application, choose the Vendor, TitleVersion and Edition in this order and choose the attributes for the replacement product.
    3. If you choose to retain the application as is:
      1. In Source Application , choose the Vendor, Title, Version and Edition.
      2. Choose a Usage category (Any Usage, Used, Rarely Used, Unused or Unreported) the application must meet in order for it to be retained during the migration. If it does not meet the usage criteria, it will not be installed.
  4. Associate the target with a Configuration Manager package or application.
  5. Click Save and close.

Modifying an existing rule

Migration rules are modified from the Manage Rules page. For convenience, you can access the Manage Rules page from the Installations page by selecting an application then clicking the Manage Rules button. This will take you to the Manage Rules page, filtered to show the rule(s) for the selected application, Alternatively you can go to the Manage Rules page to view all migration rules and manually select the rule you want to modify, In either case, from the Manager Rules page select the rule and click the Edit button.     

In this example, we are going to modify the existing retain Acrobat Reader migration rule by:

  • Changing its behavior from retain to replace.
  • Replacing all instances of Acrobat Reader with Nitro Reader.

To modify the existing retain rule for Acrobat Reader:

  1. On the Installations page, on the Vendor column click the filter icon and narrow the results down with the criteria: Vendor contains Adobe
  2. In the table, locate and select Acrobat Reader, then click the Manage rules button.
  3. On the Manage Rules screen, select the rule and click Edit.
  4. In the Edit Migration Rule screen, the original rule configuration is displayed.
  5. Click Replace application to change its behavior and under this, choose the attributes for the replacement application by clicking:
    1. Vendor and from the list, select Nitro Software, Inc.
    2. Title and from the list, choose Nitro.
    3. Version and from the list choose 12.4.0.259.
  6. Associate the target with an existing Configuration Manager Application/Package.
  7. Click Save and close.
  8. On the Application Migration page, the migration rule for Adobe Acrobat is updated from Retain to Replace.

Modify an existing rule.

Manage Rules

 Edit Migration Rule

Deleting an existing rule

Migration Rules are deleted from the Manage Rules page. For convenience, you can access the Manage Rules page from the Installations page by selecting an application then clicking the Manage Rules button. This will take you to the Manage Rules page, filtered to show the rule(s) for the selected application, Alternatively you can go to the Manage Rules page to view all migration rules and manually select the rule you want to delete, In either case, from the Manager Rules page select the rule and click the Delete button.     

In our example, we are going to delete an existing rule for Acrobat Reader.

To delete an existing rule for Acrobat Reader:

  1. On the Installations page, on the Vendor column click the filter icon and narrow the results down with the criteria: Vendor contains Adobe
  2. In the table, locate and select Acrobat Reader then click the Manage rules button.
  3. On the Manage Rules screen, select the rule to be deleted and click Delete
  4. You will be prompted to confirm your actions. 
  5. Click Delete to remove the rule.


Exporting and importing migration rules

You can export your installed applications to an Excel format file that can be worked on offline, with template columns that let you define new migration rules. Once you've finished defining the rules you can then import them back into Application Migration.

Refer to Working offline on migration rules for more information.