Key Takeaways:
- A cloud migration cutover and asset retirement are separate milestones with different evidence and ownership requirements.
- Asset discovery identifies resources, but reconciliation and dependency validation are needed to support retirement decisions.
- Every migration handoff should establish what changed, what remains, who owns it, and what happens next.
- Legacy assets can remain after migration when retention conditions, owners, review dates, and closure requirements are documented.
- ITAM platforms should be tested by tracing one migrated workload across on-premises assets, cloud resources, ownership, and open decisions.
- Migration exceptions should remain visible to receiving teams after project closure, with review outcomes and extensions documented.
The application is live in the cloud. Cutover checks have passed. The migration tracker says complete.
Then the CIO asks: “Can we retire the original servers?”
That question can leave a successful migration review with several decisions still unfinished. Infrastructure wants to preserve rollback. The application owner expects the cloud team to take over. Finance wants to understand why costs continue in both environments.
Those are reasonable positions. The team still needs a shared understanding of what remains and who will decide its future.
I would add an asset visibility milestone to each migration wave’s operational handoff: a review of what moved, what stayed, what was created, and who has accepted responsibility for the next action. It should cover the assets identified for the workload, make known coverage gaps explicit, and carry unresolved decisions into operations with an owner and a review date.
Follow one workload through the handoff
Consider a hypothetical claims-processing application one week after cutover.
The infrastructure team has retained the legacy database server for rollback. In AWS, production resources are running, and EC2 instances created for load testing remain active. They carry the migration project’s tag.
During the review, an infrastructure engineer points out that the legacy server also runs a scheduled job used in finance’s month-end reconciliation. That job was missing from the application inventory.
Now the team has three distinct decisions.
The legacy server must remain available during the rollback. It also cannot be retired until the finance job has a validated destination. Someone needs to determine whether testing is finished. The production environment needs an accepted operating arrangement once the migration project closes.
The cutover checks don’t answer any of those questions.
Keeping the server running may be the safest decision. But “keep it for now” needs conditions: who owns the server, who will move the job, what evidence will confirm that move worked, and who can authorize retirement afterward.
Finding an asset does not establish its purpose
IT asset management gives the team a place to organize asset information. During migration, that information must support decisions across both environments.
Three steps deserve separate treatment.
Discovery identifies resources within its configured coverage. It can collect identifiers, configuration, state, and tags. A project tag may help locate test instances, but it doesn’t show whether another team now relies on them or has accepted responsibility.
Reconciliation matches records that describe the same resource. If two sources report the same server, identifiers and matching rules help resolve the duplicate. The team must also distinguish a physical host from a virtual machine running on it; related resources are not necessarily duplicate records.
Dependency validation establishes what still relies on the resource. In this example, the infrastructure engineer’s information leads to a check with the finance process owner. Matching the server’s records alone would not reveal an undocumented scheduled job.
Some evidence will be available in asset records, cloud inventory, or project plans. You still need to gather other evidence. A useful handoff shows both.
Give the wave review four concrete outputs
The milestone should produce a reviewable record for each workload. It can reference existing asset, service, and change records; teams should not have to copy every detail into another document.
| Review question | Evidence to retain | What it resolves in this example |
| What changed? | Original asset identifiers, current cloud resource identifiers, workload relationships, source, and last update | Which resources supported claims processing before and after cutover |
| What remains? | Retained or temporary resources, purpose, retention conditions, review date, and known gaps | Why the legacy server and test instances are still active |
| Who owns it? | Accepted service accountability, technical operating responsibility, and an owner for each exception | Who supports production and who resolves the finance job and test-resource decisions |
| What happens next? | Decision or investigation, responsible person, due date, approval reference where required, and closure evidence | What must happen before retention ends or retirement proceeds |
A name in an ownership field is useful only when its meaning is clear. The application owner may be accountable for the service while the cloud operations team runs its infrastructure. The finance process owner validates the scheduled job’s output. Retirement approval follows the organization’s change authority.
The review should make those responsibilities explicit instead of assigning every decision to “the cloud team.”
Close the review with conditions, not assumptions
For the claims-processing workload, the handoff could record three outcomes.
Retain the legacy server under infrastructure ownership. Record the rollback end date separately from the finance job’s move. Assign the job migration to a named technical owner, with the finance process owner responsible for validating the result. Review the server for retirement only after both conditions are satisfied, subject to the applicable change approval.
Assign the load-testing instances for review. A named cloud engineer confirms with the testing lead whether further tests are planned. If the instances are no longer required, the team records the approved action and verifies the resulting state. Until then, their status remains an open decision.
Accept production responsibilities. The application owner accepts service accountability. Cloud operations accepts the technical support responsibilities, including where incidents and changes should go after the project team disperses.
This allows handoff with documented exceptions. It does not require retiring every old asset immediately. It does require the receiving team to accept the remaining work and understand what evidence will close it.
For overlapping software use, the team should also record any license review needed before an action. An inventory record alone does not settle what the relevant agreement permits.
Test the platform with one migrated application
The most useful ITAM demonstration starts with a workload the CIO recognizes.
Ask the team or vendor:
“Show me this application’s former on-premises assets, its current cloud resources, where those records came from, when they were updated, and every open ownership or retirement decision.”
Then follow the unresolved finance job through the proposed process.
Can the platform distinguish a duplicate server record from a dependent resource? How is a workload relationship established: discovered through a supported method, imported, or maintained by a team? Where does conflicting information go for review? Can the receiving owner see the reason for retention and the evidence required for closure?
Ask which steps the platform supports directly and which require an integration or operating procedure. A convincing inventory view still needs a workable route from an exception to a responsible person and a recorded outcome.
For a concrete product example, AssetSonar’s AWS integration imports supported resource types from selected AWS regions, including EC2 instances and storage volumes. Its documentation also describes how to check the latest completed sync. That provides an inventory input for the review; the team must still validate workload relationships, accept responsibilities, and authorize retirement.
Coverage is part of the demonstration. Ask what the selected accounts, regions, resource types, and permissions include, and how the team will account for anything outside that scope.
Carry the exceptions beyond the project
Across multiple migration waves, use the same minimum review fields and assign responsibility for following up on accepted exceptions. An unresolved item is visible to their receiving owner after the migration tracker marks the workload complete.
At each review date, record whether the condition has been satisfied, remains open, or needs escalation. Retain the reason for any extension. This prevents the next team from having to reconstruct why a resource was left running.
The asset visibility milestone earns its place when the next decision-maker can find the relevant evidence without locating the original project team.
At the next wave review, choose one workload marked complete and ask:
“Can we show what moved, what is still running, who has accepted responsibility for both, and which decision is due next?”
