Application Decommissioning Checklist (Dependency-First)

Most application retirements do not fail on the day the server is switched off. They fail three weeks later, when the month-end accounting batch finds an empty folder or a report nobody had listed returns zeros. The contract was cancelled, the virtual machine deleted, and only then did the dependencies show up. This checklist reverses the usual order: dependencies first, contracts and servers last.

TL;DR

• Incidents after a decommissioning usually come from a dependency nobody listed: a file transfer, a report, a scheduled job, a service account or a hard-coded connection string.
• Map every inbound and outbound dependency before you set a date, then have a named business owner and a named IT owner sign the decision.
• Treat data as its own phase: migrate what is still used, archive what the law or the business requires, delete the rest securely and keep the evidence.
• Switch the application off reversibly first, observe it over a full business cycle, then delete it for good and update your map.
• Download the free checklist (PDF, or XLSX with one sheet per application) and fill it in for every retirement.

Why do application retirements stall or break things?

Retirements stall because nobody owns the end of an application's life, and they break things because dependencies are discovered in production instead of on paper. Both problems share a root: the decision to retire is taken at portfolio level, while the knowledge of what depends on the application sits in scattered heads, scripts and spreadsheets.

The stall is familiar. A portfolio review classifies an application as "Eliminate"; two years later it still runs, because one team still needs a quarterly export, the contract renewed itself, and the project manager has moved on. The licence and run costs that justified the decision keep coming, which is why retirements are where most of the savings of an IT rationalisation effort are won or lost.

The breakage is worse. Most checklists are organised around the server (back up, shut down, wipe) or the contract (give notice, recover the data). They assume someone already knows what talks to the application. In a mid-sized organisation that has grown through projects and acquisitions, that is rarely true, and the dependencies that hurt are the undocumented ones: a nightly file picked up from a shared folder, a spreadsheet querying the database directly, a script on another server calling the API, a service account reused by another tool.

The six phases below start with dependencies because every later phase depends on what Phase 1 finds.

Phase 1: How do you map every dependency before you touch anything?

You map dependencies by combining what is documented (application map, interface specifications) with what the systems reveal (logs, schedulers, configuration files), and by asking the people who use the application. The goal is a list of every system, file, account, process and person that would notice if the application disappeared tomorrow.

Three rules make this phase reliable:

1. Observe, do not only read the documentation. Your map tells you what was declared; logs tell you what actually happens. Collect connection and access logs over a period that includes at least one month-end, and compare them with the declared flows. Every unexplained connection is a dependency to investigate.
2. Ask one level beyond the application. If application B receives a file from the application you are retiring, ask B's owner what B does with it. You do not have to trace the whole chain yourself, but every direct neighbour's owner must confirm they have a replacement.
3. Give every dependency an action. For each line: replace (by which system, ready on which date), remove (confirmed unused, by whom), or accept (the owner agrees to lose it). A dependency without an action blocks the go/no-go.

A current application map already covers the first two rows; the application ownership matrix gives you the names to call for the rest. On the business side, a process-to-infrastructure impact analysis shows which process steps rely on the application.

Do it by hand with the template: download the decommissioning checklist (PDF) or the XLSX version, one sheet per application. Or keep your applications and flows in a shared repository, so the next retirement starts from a current map: UrbaHive's free plan covers 1 user and 25 applications, no credit card.

Phase 2: Who owns the decision, and what does "done" mean?

A decommissioning needs two named people, not two teams: a business owner who confirms the business can live without the application, and an IT owner who is accountable for executing the retirement. Together they set the dates and write down the success criteria before any irreversible step.

What to record in this phase:

• Business owner: usually the head of the function that funds or mainly uses the application. They sign that every business process found in Phase 1 has a replacement or an accepted loss.
• IT owner: the person responsible for the application today. They own the plan, the cutover and the final deletion.
• Other sign-offs where relevant: security (identities, secrets, data destruction), the data protection officer if personal data is involved, purchasing or finance for the contracts.
• Dates: switch-off, end of observation, final deletion, contract ends (Phase 4).
• Success criteria: for example "no unexplained connection attempt during the observation period", "all users moved", "archive validated by finance", "licence cost stops on date X".
• Rollback trigger: which kind of incident during the observation period brings the application back.

If nobody accepts the business owner role, treat it as a finding: an ownerless application is often a good retirement candidate, but someone with authority must still accept the residual risk.

Phase 3: What happens to the data?

Every data set in the application ends up in one of four places: migrated to the replacement system, archived for legal or business reasons, handed over to another owner, or securely deleted. Decide per data category, not for the database as a whole, and keep evidence of each decision.

Work through the data in this order:

1. Inventory the data categories: customer records, transactions, documents, attachments, logs. Mark the ones that contain personal data.
2. Get the retention requirements: your legal or records-management team sets how long each category must be kept, based on accounting, tax, employment and sector rules. Do not guess. Ask, and write the answer and its basis in the checklist.
3. Migrate what the business still uses to the replacement application, and have a key user validate a sample after the migration.
4. Archive what must be kept in a readable, open format (CSV, PDF/A, a documented database dump) on storage that outlives the application, with restricted access and a named owner. An archive that needs the retired software to be read is not an archive.
5. Handle personal data: the storage limitation principle in article 5(1)(e) of the GDPR means that personal data you no longer need, and have no obligation to keep, must not survive the retirement in a forgotten copy. Check for pending erasure requests as well.
6. Delete securely whatever is neither migrated nor archived, including replicas, test copies and exports lying in shared folders. For a SaaS application, ask the vendor for written confirmation of deletion; for your own infrastructure, follow your security policy on media sanitisation.

Backups deserve their own line: decide whether they expire on their own (on what date) or must be purged earlier, and write it down.

Phase 4: Which contracts and licences must you end, and when?

Find every contract tied to the application, note its notice period and renewal date, and send notice early enough. Missing a notice deadline by a few days can mean paying another full term of the contract you set out to save.

Check:

• Licence or subscription: term, renewal date, notice period, automatic renewal.
• Maintenance and support: often a separate contract, sometimes with a different date.
• Hosting: dedicated servers, cloud subscriptions and managed services billed for this application only.
• Third-party services: middleware, monitoring, certificates, domain names used only by this application.
• Early termination terms: penalties, minimum commitments.
• Data return and deletion clauses: what the vendor must hand back, in which format, and how they confirm deletion. This links back to Phase 3.

The common trap: the notice deadline falls before the planned switch-off. Send notice on time and, if the vendor allows it, negotiate a short extension as a safety margin.

Phase 5: How do you run the cutover?

Run the cutover as a planned change, with a communication schedule, a freeze, a reversible switch-off and a tested rollback. The aim is that nobody is surprised, and that you can undo the switch-off within hours if a missed dependency appears.

The rollback plan must say what is restarted, by whom, how long it takes, and which data written to the replacement system meanwhile must be reconciled. Test it before D-day. On D-day, keep the server, the data and the configuration intact: the final deletion belongs to Phase 6.

Phase 6: How long should you wait before deleting for good?

Keep the application switched off but restorable for at least one complete business cycle, including the periodic jobs it served, then delete it for good, update your map and record what you learned. For many applications that means covering a month-end close. If the application touched quarterly, annual or audit activity, the observation period has to include that event, or you need written confirmation that it has been handled another way.

During the observation period:

• monitor attempts to reach the application: refused connections, failed jobs on other servers, support tickets;
• treat every alert as a dependency Phase 1 missed: fix it and add it to the checklist;
• keep the rollback option open until the Phase 2 success criteria are met.

Closing the decommissioning:

1. The business owner and the IT owner confirm that the success criteria are met.
2. Final deletion of servers, accounts, secrets, certificates, DNS entries and backups, as decided in Phase 3.
3. Contracts confirmed as ended; last invoice checked.
4. Update the application map: set the status to retired, remove its flows, update neighbouring applications. A map that still shows a retired application is a map people stop trusting.
5. A short lessons-learned note: which dependencies were missed, how they surfaced, and what to check earlier next time.

The checklist at a glance: phase, checks, owner, evidence

This table is the backbone of the downloadable template. Each phase has its checks, an owner, and the evidence you keep.

Download the PDF checklist to print, or the XLSX template with one sheet per application.

How does UrbaHive help with decommissioning?

UrbaHive keeps the information Phase 1 needs in a shared repository, so each retirement starts from a current picture. It does not run the decommissioning: the plan, the data and the contracts stay yours.

• Flows: each flow is recorded with a source application, a target application, a type, a frequency and a bidirectional flag. The application-flow diagram is generated from these records and exports to PNG or PDF, so you can attach it to the change record.
• Impact analysis: starting from an application, it shows the directly connected objects, upstream and downstream, on five layers (technical, application, functional, business, people): the server that hosts it, its program, the capabilities it supports, the business processes that use it and the people responsible. It goes one level only, does not follow application-to-application flows (read those from the flows and the diagram), and has no export, so copy what you find into the checklist.
• Owners: a responsible person per application, plus additional contacts.
• Status and custom fields: your organisation defines its own status typology (for example "Retiring" and "Retired"), and custom fields can carry a target date, a notice date or a TIME verdict. UrbaHive does not compute TIME scores or costs.
• Audit log: every creation, modification and deletion is recorded with before and after values, so you can see who changed the status or removed a flow. It is consulted in the app, not exported.
• AI agents: through the MCP connector, an assistant such as Claude or Cursor can answer "which flows touch this application?" or "which processes use it?" and, if you enable the write scope, update its status. No MCP tool can delete an application, a flow or any other object of the map.

UrbaHive is built for mid-sized organisations, roughly 50 to 5,000 employees, and you can start in a couple of hours. The free plan (1 user, 25 applications, no credit card, no time limit) is enough to map an application and its neighbours. Data is hosted in the EU.

FAQ

How long should the soak period be?

Long enough to cover one complete business cycle the application served, which usually means at least one month-end close. If it fed quarterly, annual or audit processes, include that event or get the business owner's written confirmation that it is handled another way. The rarest job that might still depend on the application sets the duration.

Who signs off a decommission?

The business owner signs that the business can live without the application; the IT owner signs that the technical retirement is complete. Add security, the data protection officer and purchasing where relevant. Named people, never teams.

What's the most common decommissioning failure?

An unlisted dependency: a file transfer, a report, a scheduled job or a service account nobody declared, which breaks after the switch-off. The second is the stall: an application everyone agreed to eliminate that keeps running because nobody owns the end of its life.

How do I find hidden dependencies?

Compare what is documented with what is observed: start from your application map, then read access logs over a period that includes a month-end, check schedulers on every server, search configuration files and the secret vault for the application's host names and accounts, and ask key users about rare tasks. A reversible switch-off catches what is left.

Retire applications with the map, not against it

Do it by hand with the checklist template, or let UrbaHive keep your applications, flows and owners up to date so the next retirement starts from a current map. Free plan: 1 user, 25 applications, no credit card. Create your free account.