Introduction
Handing over a finished SaaS platform to its new owner is a critical milestone that requires more than just delivering code. Founders and product owners need a reviewable pack that identifies operating responsibilities, access and the evidence required for acceptance. This article details the essential components to include, practical steps to follow, and a worked example to guide your process.
1. Source Code and Version Control
The foundation of a SaaS platform handover is the complete source code repository. This must include:
- The full codebase with commit history in a version control system like Git.
- Branching strategy documentation and current main branch status.
- Configuration templates and an inventory of environment-variable names, purposes and vault references. Keep secret values out of the repository, pack and screenshots.
- Build and deployment scripts, including CI/CD workflows.
Agree who should own the repository and verify their account permissions before transfer. GitHub's repository transfer guidance describes preserved history, issues, pull requests and other repository data. It also notes that secrets, webhooks and deploy keys remain associated with the repository and the original owner can retain collaborator access. Inspect these after transfer, confirm the target account's available features, and remove or rotate access through the agreed handover sequence. Transferring the repository does not transfer a hosting account, domain registration, gateway merchant agreement or subscription billing account.
2. Environment Access and Credentials
Provide the new owner with access to all platform environments:
- Development, staging, and production environments.
- Cloud infrastructure consoles (AWS, Azure, GCP, or others).
- Database servers and management tools.
- Third-party services and APIs integrated into the platform.
Prefer named owner accounts and provider-supported invitations, with the roles required to operate each service. Confirm MFA and recovery contacts. Where a service requires secret handover, use an approved vault or provider procedure, record its reference and rotate credentials in a controlled order after dependencies are verified. Record service-account purpose and current owners. Least privilege and authorization checks remain necessary after ownership changes. OWASP authorization guidance
3. Operating Evidence and Monitoring
To demonstrate the platform's operational status and health:
- Provide recent logs and error reports.
- Share monitoring dashboards or observability tools access, e.g., Vercel Observability.
- Include incident history and any independently configured availability-monitor results, with the observation window and monitored route. Do not infer an uptime percentage from a screenshot of application request logs.
Record the deployed revision, environment, dates, sample coverage and gaps beside the evidence. Vercel Observability offers application telemetry with plan-specific features and retention; dashboard access does not prove customer delivery, every workflow's success, or a particular availability percentage. The owner's team must know which checks are instrumented and who receives actionable alerts.
4. Backup and Recovery Instructions
Document detailed procedures to backup and restore the platform:
- Database backup methods (e.g., PostgreSQL dump and restore commands as per PostgreSQL backup and restore approaches).
- File storage backup strategies.
- Disaster recovery plans, including contact points and escalation paths.
Test the documented recovery procedure in a verified isolated environment with live payments and outbound notifications blocked. Identify attachment backups, roles, authentication dependencies, extensions and encryption/signing keys separately from a database dump. Record the backup ID, cutoff, application revision, elapsed recovery time and existing-record workflow result. A completed database import is one recovery step, not proof of full service recovery.
5. Key User Journey Validation
Have the owner's representative complete a critical user journey to confirm platform functionality. This journey should cover:
- User registration or login.
- Core feature usage.
- A payment or subscription flow if applicable, with the provider and sandbox/live status stated. A sandbox payment demonstrates that test flow; a live delivery claim needs the corresponding provider and recipient evidence.
Refer to the User Journey glossary for structuring this validation.
6. Documentation and Knowledge Transfer
Include comprehensive documentation:
- Architecture diagrams.
- API specifications.
- Developer and operations manuals.
- Known issues and limitations.
Conduct knowledge transfer sessions to clarify any questions.
7. Legal and Commercial Considerations
Clarify ownership rights, licensing, and support terms. Record the agreed position and any unresolved questions:
- Repository ownership, rights in custom code, third-party licences and any required assignment documentation.
- Support period, response expectations, provider bills, renewal dates and maintenance responsibility.
Use the actual contract and qualified advice where needed. Receipt of source code or a completed technical checklist does not determine legal rights or certify regulatory compliance.
8. Final Acceptance and Sign-Off
Use an acceptance checklist to formalise handover. This should confirm:
- Receipt of all components listed above.
- Successful key journey completion.
- Owner's approval of operational readiness.
Practical Output: SaaS Platform Handover Pack Template
| Section | Details Provided | Owner Confirmation (✓) |
|---|---|---|
| Source Code Repository | Owner organisation, repository URL, branch and deployed commit; named role | |
| Environment Access | Environment/provider IDs, named accounts, roles, recovery contacts and vault references | |
| Operating Evidence | Scoped logs, availability checks, period, revision and known gaps | |
| Backup & Recovery | Procedures and test results | |
| Key User Journey | Description and validation outcome | |
| Documentation | Manuals, diagrams, API specs | |
| Legal & Commercial | Agreements and terms | |
| Final Acceptance | Signature and date |
How to Use
The SaaS development service provides a relevant scope for documenting a custom platform's operating and handover requirements. Fill in each section with the relevant information and have the owner's representative verify and sign off each item. This creates a clear, reviewable record of the handover.
Hypothetical invoicing handover exercise
This proposed example has no measured uptime, completed transfer, actual payment or signed acceptance. Use it to define the evidence an owner should request.
| Item | Proposed owner check | Evidence to record |
|---|---|---|
| Source | Open the repository using the owner's named account | Account role, commit and transferred repository identity |
| Hosting and domain | Open deployment settings, domain management and renewal information | Account/project IDs, responsible payer and renewal owner |
| Access | Verify ordinary operator and restricted customer roles | Positive and negative access results, without secret values |
| Recovery | Restore an identified database and attachment backup in isolation | Backup cutoffs, dependencies, elapsed time and workflow results |
| Invoice flow | Open a restored invoice, create a test invoice and use the gateway sandbox | Record IDs, generated PDF, provider test reference and observed status |
| Communication | Use a controlled inbox and verify the message's receipt | Test recipient evidence; separate any later live delivery verification |
| Acceptance | Review defects and remaining dependencies with the owner | Named reviewer, environment, date, decision and unresolved items |
A missing provider invitation or failed attachment download stays open even when the repository is accessible. Owners should be able to make an acceptance decision on specific requirements rather than a general assertion that the platform is finished.
9. Workflow Automation and CI/CD Pipeline Ownership
A critical yet often overlooked component in SaaS platform handover is the transfer of continuous integration and continuous deployment (CI/CD) workflows. These pipelines can automate testing, building and deployment when configured for the platform. Their actual checks, permissions and deployment effects need to be recorded and verified.
Actions to Include:
- Provide access to the CI/CD platform (e.g., GitHub Actions, GitLab CI, Jenkins) with appropriate permissions.
- Transfer ownership or admin rights for workflow configurations and secrets.
- Document the trigger conditions for workflows, such as branch pushes, pull requests, or scheduled runs.
- Document how to start and inspect a controlled workflow with the owner's named account. GitHub workflow reruns retain the original commit/ref and original triggering actor's privileges. A successful rerun therefore does not alone prove the new owner's ability to start a fresh release.
- Explain how environment variables and secrets are managed within the pipeline.
Decision Evidence:
- Confirm the owner’s team can trigger and monitor workflow runs.
- Trigger a fresh approved test/build workflow in the transferred repository and inspect its actual actor, permissions and result. Keep production deployment as a separate authorized action.
Recorded Fields:
- CI/CD platform URL, owner account role and controlled verification run ID.
- Names and descriptions of key workflows.
- Names and purposes of secrets/environment variables, their vault or provider locations and rotation owners; never their values.
- Last successful workflow run timestamp.
Expected Results:
- Owner can trigger and inspect the agreed controlled build/test workflow. Record deployment approval rules and verify deployment access separately.
- Automated tests run and pass consistently.
Recovery Steps:
- If workflows fail, check logs in the CI/CD platform.
- Verify that secrets are correctly configured.
- Follow the documented rollback procedure after checking database migrations, storage changes and external side effects. A previous commit is not automatically compatible with the current schema, and a workflow rerun can repeat a deployment.
10. Security assessments and unresolved obligations
Handing over a SaaS platform requires transparency about its security posture and compliance status.
Actions to Include:
- Provide a summary of recent security audits or penetration tests.
- List known vulnerabilities, their severity, and remediation status.
- Share actual assessment reports and applicable policy/contract records with their scope and dates. Do not describe a technical handover as a POPIA or GDPR certification.
- Document implemented security controls such as encryption, access control, and data handling policies.
- Include instructions for patching and updating dependencies.
Decision Evidence:
- Owner reviews and acknowledges the security and compliance summary.
- Agreement on ongoing responsibilities for vulnerability management.
Recorded Fields:
- Date and scope of last security assessment.
- List of open and closed security issues.
- Actual audit or assurance documents, scope, assessor and validity dates where such documents exist; unresolved obligations and named owners.
Expected Results:
- Owner understands the current security risks.
- Clear plan for continuous security maintenance.
Recovery Steps:
- Establish a schedule for future security reviews.
- Set up automated alerts for dependency vulnerabilities.
Owner workflow acceptance worksheet
For a hypothetical customer support product, use the following proposed journey. None of the rows is a recorded pass. Decide the test environment and requirements before execution, then retain observed evidence. Include one restored customer's ticket and a second tenant so the exercise covers historical state and access boundaries.
| Step | Owner action | Expected result | Observed evidence / decision |
|---|---|---|---|
| 1 | Sign in using an invited named account | Intended role and organisation are shown | Pending |
| 2 | Open a restored ticket and its attachment | Correct history and file bytes are accessible | Pending |
| 3 | Submit a new test ticket | One durable ticket appears with the expected status | Pending |
| 4 | Assign the ticket to an agent | Assignment persists; the configured test notification is received | Pending |
| 5 | Sign in as a second tenant | First tenant's ticket, search result and attachment are inaccessible | Pending |
| 6 | Resolve the ticket and run the report | Status, timestamp and report agree on the tested ticket | Pending |
| 7 | Inspect the controlled build and alert test | Owner can see results and the intended responder receives the alert | Pending |
If the ticket is saved but its notification fails, record those as separate outcomes. If a request times out, inspect durable state before submitting it again to avoid duplicate tickets. Capture correlation IDs and redacted error details before resetting a session or cache.
For a failed step, assign the issue to an owner, reproduce it in the stated environment and agree a retest. Avoid granting unrestricted administrator access merely to obtain a passing result. Acceptance may be deferred or conditional under the actual agreement, but the report must retain material failures.
Operating responsibility map
Include a compact map of the services needed after the developer leaves. For each service, record its owner, account or project identifier, payer, recovery contact, access role and next renewal or maintenance action. Cover hosting, domains/DNS, database, object storage, authentication, gateways, email/SMS, monitoring, scheduled jobs and AI providers where used.
Identify who approves releases, responds to incidents, renews subscriptions and can recover access if the usual operator is unavailable. Confirm these roles through the provider interface or a controlled test rather than relying on a list of proposed invitations. Transfer notification and incident destinations as well as administrative access.
Keep a dated known-issues register. Each entry should state the affected journey, severity, workaround, assigned owner and acceptance impact. Attach actual assessment scope and unresolved findings without calling an untested system secure. A handover closes a development milestone only to the extent its agreed checks and responsibilities have been accepted.
Frequently asked questions
What is the difference between handing over source code and transferring repository ownership?
Source code handover includes delivering the codebase and history, while repository transfer moves the repository to the owner's account preserving issues and settings. Use GitHub’s transfer process to maintain continuity.
How should sensitive credentials be shared securely?
Use encrypted channels or enterprise password managers. Avoid email or plain text sharing to prevent leaks.
Why is a key user journey validation important?
It supplies evidence about the agreed journey, environment and revision from the owner's account. It does not validate untested workflows or establish live delivery from a sandbox result.
What should be included in backup and recovery documentation?
Clear step-by-step instructions for backups, restoration, and disaster recovery tested in isolation.
Related guides
For further background, read our cms vs custom development and discovery phase checklist. The user journey glossary explains the terminology used in those guides.
If your business is preparing to hand over a SaaS platform, use this pack to make access, evidence and remaining responsibilities reviewable. If you need help with SaaS platform development or handover, get in touch with our team via our SaaS development service to discuss your project requirements.