Go-Live Readiness Checklist
Go-live readiness confirms that DeskDox has been deployed, secured, validated, backed up, and handed over according to the selected customer-managed deployment model. This article is a documentation checklist for operational readiness; it is not a formal completion certificate.
Readiness Checklist
| Area | Expected result | Status |
|---|---|---|
| Infrastructure | Host, CPU, RAM, storage, Docker runtime, and persistent paths match the sizing baseline. | To be confirmed |
| Deployment model | Selected deployment model and support classification are documented. | To be confirmed |
| Services | frontend, backend, postgres, gotenberg, preview-worker, and index-worker are running. | To be confirmed |
| DNS/FQDN | Production FQDN resolves correctly. | To be confirmed |
| TLS | HTTPS certificate is valid and trusted. | To be confirmed |
| Firewall | Only the approved public endpoint is exposed; internal service ports are not public. | To be confirmed |
| Configuration | Production secrets, image tag, public URL, and required environment values are configured. | To be confirmed |
| Security | Admin account control, least privilege, auditability, and backup key custody are documented. | To be confirmed |
| Storage | Database, uploads, previews, FAISS/index data, backups, logs, and licensing paths are understood. | To be confirmed |
| Backup | Initial backup completes and backup location is documented. | To be confirmed |
| Restore | Restore validation is completed or a deferred validation plan is recorded. | To be confirmed |
| Functional smoke test | Login, upload, preview, OCR/search, workflow, email, public URL, and audit logs are validated as applicable. | To be confirmed |
| Operations | Monitoring, patching, backup review, escalation, and maintenance windows are assigned. | To be confirmed |
| Handover | Deployment notes, owners, open items, and support boundaries are documented. | To be confirmed |
Functional Smoke Test
At minimum, production validation should include:
- Login with customer-approved admin account.
- Login with non-admin test account.
- Folder/document access check.
- Upload a representative PDF.
- Upload a representative Office document if Office preview is in scope.
- Confirm preview generation.
- Confirm OCR/search for a representative searchable or scanned document.
- Start and complete a representative workflow.
- Send or validate email notification if SMTP is in scope.
- Confirm public URL links use the production FQDN.
- Confirm audit/history entries for representative actions.
- Complete an initial backup.
- Review restore procedure and complete restore validation or record a deferred validation plan.
Restore Validation Deferral
Production deployments should include a restore validation exercise before go-live. If restore testing is deferred, deployment handover notes should state:
- Reason restore testing was deferred.
- Operational owner.
- Target date for first restore test.
- Interim recovery approach.
Restore validation should not be silently omitted.
Handover Roles
| Role | Operational responsibility |
|---|---|
| Infrastructure owner | Host, storage, Docker/runtime, monitoring, and backup destination. |
| Network/security owner | DNS, TLS, firewall, endpoint security, and public exposure. |
| Application owner | Functional validation, admin ownership, user readiness, and go-live coordination. |
| DeskDox deployment engineer | Installation evidence, service validation, known issues, and handover completeness. |
| Operations/support owner | Escalation path, maintenance process, and ongoing monitoring readiness. |
Handover Record
Deployment handover notes should include:
- Customer name and environment name.
- Deployment date.
- Release/image tag.
- Deployment model.
- Public URL.
- Data paths and backup path.
- Restore validation result or deferred validation plan.
- Open issues and mitigations.
- Named operational owners and dates.