Application decommissioning is the process of permanently retiring a piece of software your business no longer needs, while keeping access to the data you're still required to hold. For a typical small or mid-sized business, retiring one app safely takes 4 to 12 weeks, and most of that time goes into data and dependencies, not the shutdown itself.
Quick answer: To decommission an application, first confirm nothing still depends on it, then export and archive the data you must keep (often 3 to 7 years for financial records), move users to the replacement, run both systems side by side for a short period, and only then shut it down and cancel the hosting, licenses and contracts behind it.
Most businesses don't wake up wanting to retire software. It happens because you switched to Shopify, HubSpot or a custom system, and the old tool is still sitting there costing money. Or a developer left, and nobody fully understands the old app anymore. Either way, leaving it running "just in case" feels safe, but it rarely is.
Why does application decommissioning matter for your business?
Old software costs money even when nobody uses it. You're paying for hosting, licenses, domain renewals, backups and the occasional emergency fix when something breaks. Large organizations show how big this gets: the US government spends over $100 billion a year on IT, and agencies typically report about 80 percent of that going to operating and maintaining existing systems, according to the U.S. Government Accountability Office.
Your numbers are smaller, but the pattern is the same. Every dollar spent keeping a dead app alive is a dollar not spent on something that grows the business. The bigger issue is security. An app that no longer gets updates is an open door. It still holds customer names, emails and sometimes payment history, and nobody is watching it.
Unsupported software is a real and dated problem, not a theory. Microsoft, for example, ended support for Windows 10 Home and Pro on October 14, 2025, per its official lifecycle page. Any old internal tool that only runs on a machine like that stopped getting security fixes the same day.
An app nobody uses but everybody forgot about is the most expensive and least protected software you own.
Should you decommission, modernize or keep the old app running?
Not every old system should be switched off. Some still do something useful that no off-the-shelf product handles well. The honest answer depends on two questions: does anyone still need what it does, and is there something better that does it today?
| Option | Best when | Typical cost | Main risk |
|---|---|---|---|
| Decommission | A replacement covers the job, or nobody needs it | Low: mostly data export and cleanup | Losing data you were required to keep |
| Modernize or rebuild | The app does something unique your business relies on | Higher: a rebuild project | Scope creep if goals aren't clear |
| Replace with SaaS | A tool like Salesforce, HubSpot or Toast does 90% of it | Monthly subscription plus migration | Rented data and per-user fees that grow |
| Keep running as is | Short term only, while you decide | Ongoing hosting, licenses, fixes | Security holes and staff who can't fix it |
Buying is often the right answer. If your old custom CRM only tracks contacts and deals, HubSpot or Salesforce will likely do it better for less effort. Decommission the old one and move on. But if the app runs your pricing logic, scheduling rules or a workflow that sets you apart, retiring it without a replacement can hurt. That's when a legacy modernization project usually makes more sense than a shutdown.
If you're unsure which path is cheaper over three years, the build vs. buy calculator gives a fast rough comparison before you talk to anyone.
What data do you need to keep after shutting down an app?
This is where most businesses get burned. Deleting an app can delete records you're legally required to keep, or records you'll need in a dispute, audit or tax question two years from now.
Tax records are the clearest example. The IRS says to keep most income tax records for 3 years, 6 years if you underreported income by more than 25 percent, 7 years for bad debt or worthless securities claims, and employment tax records for at least 4 years. If your old app holds invoices, payroll data or sales history, those rules apply to its data.
Healthcare, finance, legal and anything involving children's data often carry longer or stricter rules, and state laws vary. Check with your accountant or lawyer before you set a retention date. The software side is simpler: decide what to keep, then put it somewhere you can actually search.
- Must keep: invoices, payments, payroll, contracts, customer agreements and anything tied to taxes or regulations.
- Nice to keep: customer history, notes and reports that help sales or support.
- Safe to delete: temporary files, old test data, duplicate copies and logs past their useful life.
- Delete on purpose: personal data you no longer have a reason to hold. Keeping it adds risk, not value.
The best archive is boring. Export the important tables to a standard format like CSV or a simple read-only database, store it in secure cloud storage with access limited to a few people, and write a one-page note explaining what each file contains. A spreadsheet export someone can open in 2030 beats a perfect backup of an app nobody can run.
How do you find everything that depends on the old application?
Dependency mapping sounds technical, but it just means finding everything that talks to the old app. Old systems collect hidden connections over the years: a nightly export to QuickBooks, a form on your website that posts into it, a report your operations manager opens every Monday, an API (a way two programs send each other data) another tool relies on.
Switching the app off without this list is how a business discovers, three weeks later, that online orders stopped flowing into the warehouse system. Practical ways to find dependencies:
- Ask every team lead what they use the app for, and what would break if it disappeared tomorrow.
- Check the app's logins and activity history to see who still actually uses it.
- Look for scheduled jobs, exports and email reports it sends.
- Review integrations in tools like Zapier, Make, Shopify and your accounting software for anything pointed at it.
- Turn off access for a week (a "scream test") before deleting anything, and see who notices.
The scream test is the step people skip, and it's the cheapest insurance you'll ever buy. Disabling an app is reversible. Deleting it isn't.
