Cancellation & decommission

Cancellation is a lifecycle, not immediate deletion. Stripe controls the commercial end date; Mivama preserves service long enough for backup/recovery, then removes the exact tenant.

Cancellation timeline

What happens at period end

1. Stripe subscription status and cancellation timestamps are mirrored.
2. Core queues a final Backup job.
3. After backup succeeds, the service is suspended.
4. Core revokes all Studio sessions for the service.
5. Core requests Studio workspace archive and waits for a confirmed result.
6. Service enters Cancelled Retention with a deadline.
7. The hourly cancellation processor advances due records.
8. At expiry, a Decommission job removes the tenant.

The default retention is 30 days and is controlled by mivama_hosting_cancellation_retention_days. Changing it changes customer expectations and legal documentation.

Reversal before deletion

If Stripe cancellation is reversed before the paid period ends or commercial access becomes valid during retention, lifecycle reconciliation can stop the cancellation path and resume service where policy permits. Once exact decommission succeeds, data must be restored from an available backup or reprovisioned; it is not a simple Resume.

Customer communication

Localized email and Portal notifications explain scheduled cancellation, suspension, retention deadline and final deletion. Messages are essential service communication. Dates must come from persisted Stripe/Core fields, not client clocks.

Failure behavior

Backup failure blocks suspension/deletion. Studio archive failure blocks final deletion. Decommission failure records Needs Attention and retries only through the controlled processor; it never marks the service deleted optimistically.

Relevant sources: provisioning/lifecycle.py, jobs.py, _portal_studio.py, decommission-tenant.yml and hooks.py hourly scheduler.