An internal tool created three years ago was scheduled to be decommissioned this fiscal term. Hardly anyone uses it anymore. Shutting down the server was supposed to be all it took.
Once you actually begin, that is not how it goes. Where was the domain registered? Which service processed payments? Emails from monitoring tools are still arriving, but under whose name was that subscription created? It turns into an investigation rather than a decommissioning task.
The reason the article "How to Shut Down a Web Service" on Zenn resonated so accurately is that the original author fell into the exact same situation. Cloudflare Workers, Supabase, billing SaaS, AI, monitoring. In modern development, the marginal cost of adding external services is practically zero, making it easy and fun to pile them on. Then, when closing down, you find yourself touring admin dashboards one by one, confronting the reality: "I registered all of these myself."
If even the original creator experiences this, sunsetting an externally commissioned system becomes vastly more burdensome.
What you shut down is contracts, not servers
The reason decommissioning turns out far heavier than expected is simple: what needs to be shut down is not servers.
Bringing down servers and containers takes an instant. What consumes time are the contracts and access permissions dangling from them.
- Contracts with recurring billing — Domains, certificates, CDNs, databases, storage, monitoring, error alerting, billing, and email delivery. Even if individually only a few hundred yen per month, neglected subscriptions continue billing for years.
- Contracts registered under personal names — Services acquired under the accounts of agency staff or former employees. Attempting cancellation requires the individual's direct intervention.
- Assets referenced by other systems — Direct image hotlinks, redirect source domains, URLs embedded in internal docs. Deleting them immediately breaks other locations.
- The data itself — Whether customer information and transaction histories must be retained or purged in compliance with laws and internal regulations. You cannot shut it down until this is decided.
Among these, what causes the biggest gridlock in practice is the second point. If contract ownership is not registered to the organization, there is nothing that can be done technically. When an agency registered a domain on your behalf, transfer procedures become necessary, and if relations with that firm are not amicable, the process stalls right there.
The cause of the burden is documentation, not technology
Decommissioning is not difficult because of technical complexity. It is difficult because an inventory of dependencies exists nowhere.
During development, there is no incentive to record each dependency as it is added. If it works, it is correct, and at that moment everyone understands it. Documentation is needed only after the people who understood it are gone. In other words, the timing when records are required and the timing when records can be (or feel like being) written are completely out of sync.
Moreover, dependencies cannot be fully grasped just by reading code. Code does not state which service tier or plan an API key in an environment variable belongs to. Looking at invoices, service names alone do not clarify what they are being used for. It forms a structure that cannot be reconstructed without cross-referencing both code and invoices.
We organized what needs to be handed over in Four types of handover deliverables, and the materials outlined there apply directly to decommissioning. In other words, what cannot be handed over cannot be sunset either.
Four items to establish during the ordering phase
If you wait until after a service is running to determine exit terms, no one will be able to decide them. This is because stakeholder interest has waned, and the information needed to make decisions has already been lost. The following four items should be included in your contracts or specifications at the time of ordering.
1. Register external service contracts under the organization's name. Contract all domains, cloud infrastructure, and SaaS products using accounts owned by your company, granting permissions to the production agency as needed. Simply deciding this upfront fundamentally changes how difficult shutdown operations will be.
2. Include an inventory of service dependencies in deliverables. Service name, purpose, plan, billing amount, contracting entity, and impact of cancellation. A single table containing these six items is sufficient. Update it whenever a dependency is added and during your annual inventory audit.
3. Specify data return formats and deadlines. Write down specific formats, such as "data will be delivered as CSV and image files upon termination." If this is omitted, you risk being handed proprietary database dumps that are practically unusable.
4. Decide what to do with the digital footprint after shutdown. Will you maintain the domain and post an informational notice, set up a redirect, or release it entirely? Domains that are let go become targets for "drop catching"—the practice of acquiring expired domains the moment they lapse. Domains with past traffic and established search authority are especially targeted, and incidents of them being exploited for scam sites or spoofed email addresses have been documented. For domains containing company or service names, you must decide policies in advance on the assumption that you will maintain ownership for a specified period after putting up a closure notice.
These four points are not agreements made solely for shutdowns. The exact same conditions remain fully effective when switching production agencies. Viewing them as the cost of securing future freedom to switch provides strong motivation to negotiate them at the time of ordering. What actually becomes problematic when taking over an existing site is summarized in Taking Over and Maintaining Legacy Sites.
Effective actions to take while services are running
For systems that are already up and running, you cannot go back to the ordering stage. Even so, conducting an inventory audit traced backward from payment records remains highly effective.
Line up a year's worth of credit card statements and invoices, and extract payments made to overseas SaaS providers. Because smaller amounts receive less scrutiny, this is precisely where contracts accumulated for unknown purposes tend to hide. Anything not in use can be cancelled on the spot, while active services form the initial draft of your dependency list.
There is solid evidence behind the effectiveness of this practice. SaaS management surveys report that roughly 40% of SaaS purchases bypass the IT team, with the IT team in mid-sized enterprises typically aware of only about half of all active applications. In short, starting from financial statements yields far more comprehensive coverage than tracing from system architectures. While it might look like mere housekeeping to cancel unused services, it is actually a method for discovering dependencies you never knew existed.
Because this is the same work as auditing licenses and accounts, it is more efficient to handle them together. For your approach, you can adapt the procedure covered in Google Workspace License Inventory Audits.
What to do next
Pick one running system and try writing down: "If we had to shut this down next month, what would we need to cancel?" Any item you cannot list points directly to missing records. Even if you have no immediate plans to shut it down, that void will become a critical issue the moment the person in charge changes.
If you plan to place a new order, include the four items above in your requirements. These items do not incur additional costs; the only difference lies in whether you decide on them beforehand.
GleamHub provides consultations on auditing existing system dependencies and organizing contractual terms with an eye toward future shutdowns and migrations through our custom development, AI, and automation advisory services. Because the approach varies depending on technical architecture and contractual history, please reach out for personalized advice via our contact form.
Sources
- How to Wind Down a Web Service — Zenn
- Domain Management Fundamentals and Decommissioning Risks: Countermeasures and Precautions to Prevent Abuse — Web Tan
- Think Twice Before Cancelling a Domain Name: Risks of Abuse and Key Precautions — Sakura Homepage Classroom
- Before Letting Go of a Domain: Understanding Drop Catching and How It Is Exploited — NetAssist
- What is SaaS sprawl? Causes, risks & how to fix it (2026) — Corma
- SaaS Sprawl Audit in Mid-sized Companies 2026 — Cloudmagazin
