Accepting a web project: access, source code and a repeatable launch

A website may look finished while its owner still cannot renew the domain, identify the code running in production or restore the database. Project acceptance should resolve these questions before handover. The exact deliverables depend on the agreed scope and the third-party services involved.

1. Map ownership and access

List the domain registrar, DNS, hosting, source repository, email, analytics and external services. For each, record the account owner, billing contact, sign-in method and recovery contact. Business-critical accounts should remain under the company’s control. Give contractors separate access appropriate to their tasks.

• Verify that the owner can sign in and manage the domain and DNS.
• Identify recurring costs and who receives renewal notices.
• Arrange a recovery method before the engagement ends.
• Transfer passwords and recovery codes through an agreed protected channel, not a broadly shared task.

2. Identify the source version running in production

A source folder alone does not identify the live release. Record the repository, release branch or tag and commit identifier. Include dependency and build instructions and a list of required environment variables without secret values. Clarify licence and transfer restrictions for third-party components; possession of source code does not imply ownership of every dependency.

3. Repeat deployment on a separate environment

Ask the team to deploy the release using the handover instructions. Use test data and keep email, SMS, payments and external automations in test mode. The exercise should demonstrate that another team can repeat the launch without guessing settings from the production server. Record the commands, migration order, checks and rollback procedure.

4. Test complete business workflows

Describe a few scenarios with expected outcomes. For example, a visitor submits an enquiry, an employee finds it and the responsible person receives the notification. For a CRM, include record creation and editing, search, export and users with different permissions. Check a mobile screen and error conditions such as missing fields, duplicate submission and an unavailable integration. Record defects with reproducible steps and agreed resolution dates.

5. Restore a backup

Confirm whether the backup includes the database, uploaded files, configuration and keys needed for recovery. Restore it in an isolated environment. Compare selected records and files, then test sign-in and a business workflow. Agree on an acceptable backup age and recovery time for this exercise. A backup file’s existence alone is insufficient evidence that the service can be recovered.

6. Define support responsibilities

Keep clear support contacts, reporting procedures and the scope of defect fixes, dependency updates and paid changes. Review access after handover, retain permissions needed for support and revoke temporary ones. If secrets were shared, coordinate their rotation and verify that integrations still work.

The owner’s handover pack

• Service ownership, billing and account recovery map.
• Repository and identified release version.
• Deployment, update, environment and rollback instructions.
• Business workflow checks and open issues.
• Backup instructions and evidence of a test restore.
• Support contacts and agreed responsibilities.

Use this checklist when planning delivery as well as when reviewing the finished project. To discuss a website, CRM or web application handover, contact the studio with the current system state and the team that will maintain it after launch.

Free project handover checklist

Download the XLSX checklist or read the instructions. The workbook and its instructions are in Russian. Record evidence, responsible people and open issues for each check. Do not enter passwords or private keys into the spreadsheet.