A CMDB Export Is Not Application Dependency Mapping

A CMDB export can contain valuable application and dependency information. Before using it to plan a migration, verify that the export includes the relevant relationships, reflects the current environment, and has been checked against the way the applications operate. The useful question is whether the information is sufficient for the change you intend to make.

Use this application dependency mapping checklist before a migration or data-center exit. It helps you turn existing records, technical observations, and owner reviews into a map that supports migration sequencing, testing, and recovery planning.

What a CMDB export may already tell you

A configuration management database, or CMDB, can hold configuration items such as applications, servers, and databases, along with relationships between them. ServiceNow’s documentation, for example, describes relationships that can be discovered, imported, or maintained by users.

Check what your export actually contains. An asset-only report may omit relationships that exist in the CMDB. A richer export may already include application components, owners, relationship types, and source information. Reuse reliable records rather than rebuilding them.

The remaining work is validation. Check the selected tables and filters, the source and age of the records, and any systems outside discovery coverage. A recently generated file can still contain older or incomplete information.

Compare the records with the migration requirements

Use this comparison to identify gaps. The middle column describes possible CMDB data, not a limit on what a CMDB can store.

Checks to complete before using a CMDB export for migration planning

Review area	What the export may contain	What to confirm for this change
Scope	Applications, infrastructure, and service records	Which components are moving, staying, being replaced, or being retired
Relationships	Connections and dependencies between configuration items	Whether the relevant application, shared-service, and external dependencies are included and current
Ownership	Business, technical, or support owners	Who validates each dependency and who can approve the migration decision
Evidence	Discovery sources and update timestamps	The observation period, known blind spots, and results of owner review or testing
Sequence	Related components and service groupings	Which changes must happen together, which can be separated, and the conditions for doing so
Acceptance	Linked procedures or supporting records	Business checks, technical tests, monitoring, and recovery decisions for the migration

1 Define the application and the planned change

Start with the business service the application supports and the reason for the move. Identify the production components in scope, the environments that are excluded, and the teams that will approve the outcome.

Record whether each component will move, remain in place, be replaced, or be retired. Include the deadline and any change restrictions that affect the plan. This makes it easier to distinguish an application dependency from a component that merely appears in the same inventory.

2 Validate dependencies using more than one source

Combine CMDB records and architecture diagrams with appropriate discovery or monitoring data and reviews by application owners. AWS guidance on detailed application assessment recommends validating existing knowledge and diagrams with programmatic information about components and their communication.

Understand what each tool observes. For example, Azure Migrate’s agentless dependency analysis captures TCP connection information from supported servers where analysis is enabled. Its findings should be interpreted within that collection scope.

Choose an observation period that reflects the application’s workload. Review scheduled jobs, month-end processing, infrequent integrations, and recovery procedures with their owners. As a practical consequence of limited observation windows, an unobserved connection should remain a question to investigate rather than automatic proof that no dependency exists.

Record disagreements between sources. Assign someone to resolve each material gap before the migration decision.

3 Document the dependency and its business effect

For each important dependency, record the consuming component, the service it needs, and the purpose of the interaction. Include direction, timing, technical requirements, an accountable owner, and a reference to the evidence used to validate it.

Check application interfaces, databases, file transfers, scheduled jobs, identity services, name resolution, shared infrastructure, and external services as appropriate to the environment. Ask what happens to the business process if the dependency is unavailable or changes during the move.

Keep sensitive diagrams, addresses, and configuration details in approved internal systems. The planning record can point to controlled evidence without copying it into a public form or an unrestricted document.

4 Use the map to decide migration order

Identify dependencies that require components to move together and those that can continue across the old and new environments. Validate the proposed connectivity, security, performance, and support arrangements for any period of coexistence.

A shared service does not automatically force every dependent application into the same migration wave. AWS’s portfolio-baseline guidance highlights this distinction when grouping applications. Review the actual requirement rather than grouping every system connected to a common service.

For broader sequencing and operating considerations, review our cloud migration planning overview. If a facility closure is driving the move, include the dependencies and deadlines in your data-center exit readiness review.

5 Agree on validation and recovery before cutover

Name the people responsible for the change, business validation, communications, and recovery decisions. Document how the team will detect a failed dependency and who can authorize the next action.

Define the checks that demonstrate the affected business workflows still work. Depending on the application, these may include authentication, a representative transaction, a scheduled job, an external interface, and monitoring. Agree on expected results and record exceptions.

Review rollback or other recovery options, their prerequisites, and the decision point beyond which they may no longer be practical. Test through approved change procedures. After the move, update the dependency records and resolve discrepancies found during validation.

Discuss your migration requirements

If scope, ownership, or readiness is still unclear, use our cloud assessment guide to organize the questions before evaluating options.

For help organizing the migration decision, contact The Data Partner with high-level business context. Do not submit credentials, system inventories, network diagrams, or other sensitive technical material through the public contact form.