Applications
Applications track the software systems, services, and business apps running on your migrated infrastructure. Linking applications to devices and databases gives Clarity Migrate the dependency intelligence needed to sequence migrations safely and avoid co-dependency failures.
Overview
The Applications module is your application portfolio register. It tracks every software system — from homegrown line-of-business apps to commercial off-the-shelf packages — that has a stake in the migration. Each application record captures business context (owner, business unit, lifecycle phase), technical context (classification, risk level), and migration intent (migration plan).
Applications become most powerful when they are linked to the devices that host them and the databases they depend on. This relationship data underpins the dependency graph, which Clarity Migrate uses to recommend co-migration groupings and flag risks when a device is assigned to an earlier wave than one of its dependent applications.
The Application Portfolio view aggregates all applications by lifecycle phase, giving leadership an at-a-glance picture of the estate being migrated. The Application Discovery workflow guides users through an intake survey to capture risk and classification data for each app.
When to use this
- Application portfolio review: Catalogue all apps at project initiation. Assign lifecycle phase and risk level before wave planning begins.
- Dependency mapping: Link apps to hosting devices and backing databases so the dependency graph is accurate.
- Wave sequencing: Filter by Risk Level to identify Critical and High-risk apps and push them to later waves with more preparation time.
- Stakeholder communication: Use the Portfolio view to show leadership which apps are being retired, rehosted, or replatformed.
- Cost allocation: Business Unit field enables cost tracking per department across the migration programme.
- Post-migration validation: Application records drive the post-migration validation checklist — each app should have a test confirmed before the wave is signed off.
Key features
Step-by-step instructions
Adding a new application
Enter the application Name and Description. Then set:
- Lifecycle Phase — Active, Legacy, Retire, or Decommission
- Risk Level — Low, Medium, High, or Critical
- Classification — Internal, External, or SaaS
- Owner and Business Unit
Linking an application to devices
Bulk editing applications
Exporting the application portfolio
Important fields
| Field | Required / Optional | Description |
|---|---|---|
| Name | Required | The application's display name. Should be the recognised business name (e.g., SAP ECC, Finance Portal). |
| Description | Optional | A brief description of the application's purpose. Helps team members who are unfamiliar with the app understand its business role. |
| Owner | Required | The person accountable for this application's migration. Receives notifications and is listed on T-Minus runbook tasks. Must be set for notifications to work. |
| Business Unit | Optional | The department or business unit that owns this application. Used for cost allocation reporting and filtering. |
| Lifecycle Phase | Required | Current lifecycle state: Active (in use), Legacy (old but in use), Retire (planned for retirement), or Decommission (being decommissioned). |
| Risk Level | Required | Business risk of migrating this application: Low, Medium, High, or Critical. Drives wave sequencing recommendations. |
| Classification | Optional | Whether the app is hosted Internally, accessed by External users/customers, or is a SaaS subscription (and therefore not migrated). |
| Migration Plan | Optional | The intended approach: Rehost (lift-and-shift), Replatform, Refactor, Replace, or Retire. Used in portfolio analysis and executive dashboards. |
Example workflow
A project manager is preparing the final wave plan before the migration programme kicks off. Leadership has asked for all Critical-risk applications to be migrated in Wave 3 or later, after the team has built confidence with lower-risk workloads.
She navigates to CMDB → Applications and uses the Risk Level column filter to show only Critical applications. The filtered list shows eight applications. For each, she opens the detail page, checks the Linked Devices tab to confirm all hosting servers are identified, and reviews the linked databases.
Two applications — ERP Core and Treasury Platform — have no linked
devices. She contacts the relevant application owners (via the Owner field), who confirm the
hosting servers. She adds the device links and then returns to the Device List to assign those
servers to the Wave 3 — Critical Systems Move Group via Bulk Edit.
She then filters the Application List by Risk Level = Low and uses Bulk Edit to set all Low-risk applications to the Wave 1 — Non-critical Migration Plan. The Portfolio view now shows a clean, risk-aligned wave breakdown ready for stakeholder sign-off.
Tips & best practices
Unlinked applications are invisible to the dependency graph. This means Clarity Migrate cannot warn you if the hosting device is assigned to an earlier wave than the app's dependent services. Link every application to at least one device as soon as the hosting server is confirmed.
Set Risk Level before you begin assigning Move Groups. The migration command centre uses Risk Level to flag sequencing conflicts — for example, if a Critical-risk application's hosting device is assigned to Wave 1. Accurate risk levels prevent costly mistakes.
The Application Portfolio view summarises your entire app estate by lifecycle phase and migration plan. It is ideal for steering committee presentations. Export it as a PNG or include a link in your status reports.
Common mistakes
This is the most common and most costly mistake. Without device links, the dependency graph is incomplete and Clarity Migrate cannot generate accurate co-migration recommendations. After adding an application, always navigate to its Relationships tab and link all hosting devices.
When risk levels haven't been properly assessed, teams sometimes default everything to Low to move quickly. This defeats the entire purpose of risk-driven wave sequencing. Take the time to assess each application properly, or use the Application Discovery workflow to collect risk data from application owners via a structured intake form.
The Business Unit field drives cost allocation reports that are often required by finance teams and programme sponsors. Missing Business Unit data means the cost reports are incomplete and departmental chargebacks cannot be calculated. Set this field during initial application registration, even if only an approximate business unit is known.