Why this matters
How to inventory applications before a migration starts with a simple shift: count applications, not machines. One business app may run on several servers, a database, a scheduled job, and an identity integration. If your list only names virtual machines, you miss the parts that make the app work.
A good inventory answers four questions for each app: who owns it, what it depends on, what data it holds, and how bad a failed move would be. Those answers drive sequencing, test plans, access changes, and support handoffs. They also expose apps nobody owns, which are the ones that cause late surprises.
The inventory becomes the shared reference for engineering, security, finance, and support. When someone asks why an app is scheduled early or late, the catalog should show the reason and the evidence. Without that record, migration meetings turn into arguments about memory.
Before you start
Pick the boundary before you collect anything. A common boundary is all applications used by a business unit, or all apps that touch a data center you plan to leave. Write down what is in scope and what is out. Include SaaS apps that hold company data, even if nobody in IT bought them.
Define the columns in your catalog. At minimum: app name, business purpose, owner, technical contact, users, criticality, hosting, operating system or runtime, database, integrations, data class, license or contract, support status, and last review date. Add a confidence field: confirmed, probable, unknown. That field stops a guess from looking like a fact.
Choose a place to keep it. A spreadsheet works for a first pass if you set validation and one editor per row. A CMDB or application portfolio tool works better when you need history and links to servers. Do not run two lists. Pick one source and make every export land there.
Name one person to run the inventory and one reviewer from each major group. Set a deadline for the first draft. Tell people the draft is for planning, not performance review. Owners share more when they know the list will not be used to rank them.
How to do it
Start with machine evidence: discovery scans, hypervisor exports, cloud billing exports, endpoint agents, and network flow logs. Machine data gives you hosts, open ports, and traffic patterns. It does not tell you why an app exists or who pays for it.
Then interview owners with the catalog open. Ask them to correct rows and fill gaps rather than answer blank questions. Walk through a normal day for the app: who signs in, what it calls, what it stores, and what happens when it fails. Capture the answers in the owner's words, then normalize the terms later.
Finish with a dependency pass. For each app, list inbound and outbound connections, identity providers, DNS names, certificates, file shares, mail relays, batch jobs, and third-party APIs. Mark each link as confirmed by logs, confirmed by an owner, or assumed. Assumed links need a test before migration.
Run the steps in order. Do not wait for perfect data. A catalog with open questions is more useful than a polished list built after the migration date is set.
- Set the scope and schema. Write down which business units, data centers, and app types are in scope. Define the catalog columns and the confidence values before anyone fills a row.
- Pull machine and contract exports. Collect hypervisor, cloud, endpoint, network flow, and finance exports into one working file. Use these sources to seed the rows and find apps that owners forgot to mention.
- Add SaaS and shadow IT. Check SSO logs, DNS logs, and recurring software charges for apps outside central IT. Add each one to the catalog with the person or team that uses it.
- Interview each owner. Open the catalog during the interview and ask the owner to correct it. Walk through a normal day, a busy day, and a failure day for the app.
- Map dependencies and data flows. List every inbound and outbound link, including identity, DNS, storage, mail, batch jobs, and external APIs. Mark each link with the evidence that proves it exists.
- Rate criticality and data sensitivity. Ask the owner and the business sponsor what happens if the app is down for an hour, a day, or a week. Record the data class and any regulatory or contractual handling needs.
- Record lifecycle and support facts. Capture the version, end-of-support date, vendor contact, license renewal, custom code, and runbook location. These facts decide whether an app can move as is or needs work first.
- Mark open questions. Give every unknown a named person and a due date. Do not hide gaps in a comment field that nobody reads.
- Review with security and finance. Walk security through data classes, access paths, and certificates. Walk finance through contracts, renewals, and unused apps that could be retired before migration.
How to check it worked
Compare the catalog to independent sources. Export the server list from the hypervisor, the app list from SSO, and the vendor list from finance. Every app in those sources should map to a row or a documented exception. Every row should map back to at least one source.
Pick three apps and trace one transaction end to end. Start at the user login, follow the DNS name, the load balancer, the app server, the database, and any queue or external API. If the catalog does not show the full path, your dependency data is too shallow.
Ask each owner to sign off on their rows. Sign-off means the owner has read the criticality, data class, dependencies, and support notes. It does not mean the app is ready to move. It means the facts are right enough to plan with.
Run a tabletop review. Give the team one app and ask what breaks if its database is unavailable for a day. Use only the catalog. If the answer is not in the catalog, add the missing field or dependency before you call the inventory done.
Mistakes to avoid
The first mistake is treating a server list as an application inventory. Servers are hosts. Applications are business services with owners, data, and connections. If you cannot name the owner and the users, you have not finished the row.
The second mistake is collecting too much detail too early. You do not need every log line or every port for planning. You need enough to judge risk, dependencies, and support needs. Extra fields that nobody updates make the catalog look complete when it is not.
The third mistake is skipping finance and support. Finance knows about SaaS renewals and vendor contracts that IT may never see. Support knows which apps generate calls and which ones have fragile workarounds. Leave either group out and your list will miss real costs and real pain points.
The fourth mistake is leaving confidence blank. Mark what you know, what you think you know, and what you still need to prove. Review the open questions every week. If you need outside structure, one option among others is the Cloudverg Discovery and roadmap sprint at a fixed price of $9,500. It runs two weeks and ends with an architecture, a phased roadmap with risks, and a fixed quote for phase one.
Frequently asked questions
What should an application inventory include?
It should include the app name, business purpose, owner, technical contact, users, criticality, hosting, runtime, database, integrations, data class, contract, support status, and last review date. Add a confidence value and an open questions field. The list should be useful to engineering, security, finance, and support, not only to the migration team.
How do I find shadow IT before a migration?
Check SSO logs, DNS queries, expense records, and vendor invoices for tools that central IT did not approve. Ask team leads what they buy with a company card. Add every hit to the catalog, even if the app is small or temporary.
Who should own the application inventory?
One person should run the process and keep the catalog current. Each application still needs a business owner who signs off on criticality, data class, and dependencies. IT can supply the tooling and evidence, but business owners must confirm what the app does and what happens if it fails.