Impact analysis: what to assess before decommissioning a database

An application replacement is under way, and its database is on the decommissioning list. Before the decommissioning date is confirmed, one question remains open: which other applications still depend on it?

A reporting application may continue to read from it after the core system has been migrated. Preparing the decommissioning therefore means identifying these dependencies and the business capabilities they support.

Boldo’s impact analysis, introduced in the autumn release, traverses the relationships in your repository from the assets you select. It identifies the applications and capabilities to review with the relevant teams before decommissioning.

Start from the database in scope

Consider a fictional example. The “Legacy Customers” database is used by two applications: “Legacy CRM”, which is being replaced, and “Sales Reporting”. The former supports customer relationship management; the latter, sales management.

The migration team is already working on the CRM. It now needs to confirm whether the database can be decommissioned in the same timeframe. The analysis should therefore start from the database itself.

In Boldo, select it as the source. The analysis retrieves the applications linked to it in the repository, so you do not need to reconstruct these dependencies manually from what is already known.

If the review covers several databases, sources can also be defined by a filter, for instance on a status recorded in the inventory. Here, select “Legacy Customers” only.

Identify the consuming applications

The first stage identifies the applications that use the database. This requires choosing the relationship that links them to it and the direction in which to traverse it.

In the repository, the “Uses” relationship points from the application to the database. To identify the consuming applications, start from the database and traverse the relationship in reverse. The arrows displayed still point from the application to the database.

In our example, the traversal returns Legacy CRM and Sales Reporting. Decommissioning the database therefore also affects the sales reporting team.

Before confirming the decommissioning date, validate with this team whether the reporting still uses the database, which data it extracts and which source could replace it. Boldo surfaces the dependency documented in the repository; the application owners then confirm actual usage.

Extend the analysis to business capabilities

The list of applications defines an initial technical scope. To assess the potential business impact, extend the analysis to the business capabilities these applications support.

Boldo lets you chain several stages, each with its own relationships to traverse. Here, the first stage identifies the applications using the database; the second follows the relationships between those applications and their business capabilities.

Legacy CRM maps to “Customer relationship management”, Sales Reporting to “Sales management”. The CRM replacement project must therefore also secure the continuity of sales reporting.

To understand why a capability appears in the results, trace its path back to the database through the application concerned. You can then review that dependency with the relevant business owner.

Validate dependencies before reaching a decision

For Sales Reporting, confirm with the application owner whether it still reads from the database. Three outcomes are possible:

• The application still uses the database. Plan how this usage will be maintained after decommissioning.
• It now relies on another source. Update the repository so that future analyses reflect the change.
• Its usage remains unclear. Define the checks required before confirming the decommissioning date.

An application that does not appear in the results may still use the database. A missing relationship, an incorrect traversal direction, a filter, a stop condition or restricted access rights can explain its absence. Also review any warnings indicating that the calculation or the displayed paths are incomplete.

The analysis identifies the dependencies to validate with the teams. On its own, it does not establish that the database can be decommissioned.

Read the impact analysis guide

Prepare the decommissioning review with the teams

Save the analysis configuration to reuse it throughout the project. Saving does not freeze the results: they are recalculated from the data accessible at the time of viewing.

To prepare a workshop, convert the results into a diagram. You can then arrange the cards and add the annotations needed for the discussion.

In our example, a note next to the CRM states “In scope of the CRM project”. Another, next to the reporting application, states “Dependency to be validated before decommissioning”.

The steering committee can then address three specific questions:

• Is the migration of the CRM’s usages sufficiently prepared?
• Does sales reporting still rely on the database?
• Is an alternative data source required before decommissioning?

Before each review, reopen the saved analysis and check whether the dependencies have changed. Then confirm that the diagram still covers the items under review. For guidance on building a clear review deck, see our article on application architecture diagrams.