Which IT Term Fits a Paused Service: Teardown vs. Mothballing, Turndown, and Decommission

Introduction

Engineers often need to take a running service offline without deleting it, with the plan to bring it back later. The name you give that state matters. If a document calls the shutdown a “teardown,” a reader can reasonably assume that everything was destroyed, including configuration, credentials, and dependencies, and that the service cannot simply be restarted. This article explains why teardown is the wrong term for a preserve-and-restart shutdown, which terms fit better, and how to structure the documentation so that both the reasoning and the restart steps are clear.

One-line summary

Calling a service shutdown “teardown” when you intend to keep it and restart it later does not match standard usage. In standard IT, teardown refers to cleaning up or destroying one-off resources that were created for a task, and it has no concept of preservation. For this case, the accurate mapping is mothballing, hibernation, or pause (a preserve-and-resume shutdown), and for documentation, a combination of a handover doc and a restore runbook. Also, the formal SRE term for shutting down a production service is not teardown but turndown.

Core diagram

Lining up the terms along a single “permanence” axis (whether the intent is to turn the service back on) makes the choice clear.

Preserve + restart expected                                 Final shutdown / replacement expected
◄──────────────────────────────────────────────────────────────────────►
pause · suspend   mothballing · hibernation   deprecation · sunset · EOL   decommission · retirement
(state kept,       (deep freeze, config, IP,   (phased-out notice,          (permanent production stop,
 resume at once)    certificates kept, zero      still operating)            data kept, restart not
                    instances)                                               expected)

         ▲ This case (preserve in season 1, restart in season 2) sits here.   teardown is not on this axis;
                                                                              it is a different axis:
                                                                              "one-off resource cleanup/destruction"

The key point: teardown is not a point on this spectrum. It is not a lifecycle term for shutting services down. It is a cleanup term from testing and infrastructure, so it sits on a different axis entirely.

Core data

1. What teardown actually means in each context (both are “cleanup of one-off resources”)

• Testing (the most established usage). The pytest documentation defines teardown as “Teardown / Cleanup (AKA Fixture finalization).” In a yield fixture, the code before yield is setup and the code after it is teardown, and teardown runs in reverse order. The xUnit pattern (JUnit @After, setUp/tearDown) is the root. The target is state that is created and discarded for each test.
• Infrastructure and CI/CD. Terraform destroy is documented as a command that cleans up temporary objects in development ephemeral infrastructure once it is no longer needed. Teardown of a preview or ephemeral environment means destroying the environment when the pull request closes.
• In both standard usages, teardown means cleaning up or destroying consumable resources. That is different from “shutting down without deleting.”

2. Comparison of lifecycle shutdown terms

Term	Precise meaning	When it is used	Implication of permanent deletion or finality	Representative source
teardown	Cleanup or destruction of one-off state or resources created during setup	Test fixture cleanup, destroying ephemeral infrastructure	Yes (consumable, not preserved)	pytest, Terraform
turndown	Safely shutting down a production service or cluster (formal SRE term)	Shutdown or drain during operations	Usually a shutdown	Google SRE Book
deprecation	A warning stage meaning “stop using this,” still operating	Start of phased retirement of an API or feature	Planned (not yet happening)	Axway, Zuplo (vendors)
sunset / sunsetting	The transition from deprecation to shutdown, with reduced support	Between the retirement notice and the actual cutoff	Planned	Axway, Nordic APIs (vendors)
end-of-life (EOL)	A vendor’s declaration that support has ended	Product or version support stops	Strong	Nordic APIs (blog)
decommissioning	Stopping operation while keeping data and metadata for compliance	Final disposition of a resource, usually not restarted	Operation ends (restart not expected)	AWS COST04
retirement	End of lifecycle, usually replaced by a new system	Service retirement	Strong (replacement expected)	ITIL, Wikipedia
mothballing	Deep freeze with configuration and resources preserved, restart with minimal friction	Shutting down temporarily with plans to turn it back on	None (preservation and restart expected)	Fly.io
hibernation	Stop after saving state, restore state on resume	Pausing an unused app or system	None	Android, Fly.io
pause / suspend	Scale to zero instances while keeping state	Temporary pause with resume later	None	Fly.io

3. Standard types of shutdown and handover documents

• ADR (Architecture Decision Record): A short document capturing a single decision and its rationale (context, decision, consequences). It is the “why” layer (Martin Fowler).
• Runbook: The “how” layer for operations. It contains step-by-step procedures. The ADR community separates runbooks as the how layer.
• Handover / knowledge-transfer (KT) doc: A broader document for handing work between people or teams. ADRs and runbooks can feed into it.
• Decommissioning plan or checklist: Records resources, metadata, backups, and dependencies at shutdown (AWS COST04).
• A document that covers “what was shut down and how to turn it back on” is not a single type. It is a hybrid: (a) what was shut down and why is a handover doc (plus an optional ADR), and (b) how to turn it back on is a restore runbook. It is not a “decommissioning plan,” because that term does not assume restart.

4. Standard frameworks

• ITIL: Service retirement and transition are covered in the Service Transition stage. Retire (take the service out of live operation) comes before decommission (final disposition).
• Google SRE: The lifecycle runs from inception to “eventual peaceful decommissioning.” Operational procedures explicitly include service turnup and turndown. Turndown depends on automation and idempotency, and the book includes an incident caused by a workflow that was made idempotent. For decommissioning, it recommends advance notice to users with a timeline. The gate for bringing a service back is the Production Readiness Review (PRR).
• AWS Well-Architected (COST04): Best practice at shutdown is to record metadata (IPs, Regions, VPCs), take backups and snapshots, capture dependencies, and notify stakeholders. The “what was preserved” section of this case matches this pattern exactly.

Insights

Verdict: teardown is inaccurate for this case

In standard usage, teardown (whether in testing or infrastructure) means cleaning up or destroying one-off state that was created and then discarded. pytest defines it as “cleanup/finalization,” and Terraform defines it as destroying temporary objects. This directly conflicts with the core intent of preserving the service and restarting it. A collaborator who reads only season1-teardown.md could reasonably conclude that traces were cleaned up and destroyed. In addition, the formal SRE term for shutting down a production service is turndown, so teardown misses on that point too.

Better alternatives

File names (in order of fit to intent):

• season1-pause.md: The most intuitive option, with the implications of preservation and resumption made clear.
• season1-mothball.md or season1-hibernation.md: These match the industry preservation terms exactly (per the Fly.io definitions).
• season1-handover.md: Emphasizes the handover, for cases where preservation and restoration are secondary.
• Avoid: decommission or retirement (too strong, implying final shutdown or replacement), and teardown (wrong axis).

Document structure (hybrid, recommended):

1. What was shut down and why: a handover doc, with an optional one-page ADR (Fowler format: context, decision, consequences).
2. What was preserved: the AWS COST04 pattern (tokens and App IDs, Edge Function and pg_cron definitions, Sheet IDs and service accounts, the list of secrets, dependencies).
3. Restore procedure: a restore runbook with step-by-step instructions. Following the SRE turndown lesson, make the restore scripts idempotent. Adding a PRR-style checklist for restart brings the document closer to the standard.

Applying this to the challenge project (content-designer-challenge)

The docs/season1-teardown.md file created in content-designer-challenge already follows the standard hybrid structure (handover plus restore runbook) in its content: what was shut down, what was preserved, and the restart procedure. However, the name does not match the meaning. Renaming it to season1-pause.md or season1-mothball.md and checking the preserved-items section against the AWS COST04 checklist (metadata, backups, dependencies, notifications) would align both the naming and the structure with the standard. (The actual rename is a separate decision.)

Sources

• pytest fixtures (teardown and finalization definitions): https://docs.pytest.org/en/stable/how-to/fixtures.html
• pytest xUnit-style setup and teardown: https://docs.pytest.org/en/stable/how-to/xunit_setup.html
• HashiCorp Terraform destroy (ephemeral cleanup): https://developer.hashicorp.com/terraform/cli/commands/destroy
• Martin Fowler, Architecture Decision Record: https://martinfowler.com/bliki/ArchitectureDecisionRecord.html
• adr.github.io (decision log): https://adr.github.io/
• endjin, ADR and knowledge transfer/handover: https://endjin.com/blog/architecture-decision-records
• Google SRE Book, Service Best Practices (turnup/turndown, peaceful decommissioning): https://sre.google/sre-book/service-best-practices/
• Google SRE Book, Automation at Google (turndown idempotency incident): https://sre.google/sre-book/automation-at-google/
• Google SRE Book, Evolving SRE Engagement Model (PRR): https://sre.google/sre-book/evolving-sre-engagement-model/
• AWS Well-Architected COST04-BP02 (decommissioning process, metadata and backups): https://docs.aws.amazon.com/wellarchitected/latest/framework/cost_decomissioning_resources_implement_process.html
• AWS Well-Architected COST04-BP03 (decommission resources): https://docs.aws.amazon.com/wellarchitected/latest/framework/cost_decomissioning_resources_decommission.html
• ITIL v3 Service Transition ch. 4 (retire and decommission order): https://www.hci-itil.com/ITIL_v3/books/3_service_transition/service_transition_ch4_4.html
• CIO Wiki, Retired Services: https://cio-wiki.org/wiki/Retired_Services
• Fly.io, Power Pause (mothballing as deep freeze, restart): https://fly.io/blog/fly-now-with-power-pause/
• Android Developers, App hibernation: https://developer.android.com/topic/performance/app-hibernation
• Wikipedia, Application retirement: https://en.wikipedia.org/wiki/Application_retirement
• Zuplo, Deprecating REST APIs (vendor): https://zuplo.com/learning-center/deprecating-rest-apis
• Axway, API lifecycle deprecation and sunsetting (vendor): https://blog.axway.com/learning-center/apis/api-management/api-lifecycle-management-deprecation-and-sunsetting
• Nordic APIs, Sunset and deprecate APIs (blog): https://nordicapis.com/how-to-smartly-sunset-and-deprecate-apis/
• Archondatastore, Application decommissioning and retirement (blog): https://www.archondatastore.com/blog/application-decommissioning-retirement/

Bottom line

Teardown describes destroying one-off resources, so it does not fit a service you plan to keep and restart. For a temporary shutdown, use pause or mothballing in the name, and document it as a handover doc with a restore runbook. Reserve turndown for the formal SRE act of shutting down a production service, and reserve decommission for final disposition with no planned restart.