Hand over a hosting project without sharing passwords

A project handover fails when the important knowledge exists only in the outgoing maintainer's chat history. The new person may have files but still not know how to deploy, renew or recover the service.

Organize the handover around actions the next maintainer must perform, then give access through the correct account tools.

Identify ownership and access

Record which customer account owns the service, who handles billing and who controls the domain registration and DNS provider. Those may be different people.

Invite collaborators using individual panel permissions where supported. Do not put the main account password or recovery codes into a handover document.

Explain the working deployment

Document the application version, runtime, required variables and the location of configuration. List the steps used to start, update and verify the application.

Use names for secrets rather than their values. The actual secret transfer or rotation should take place through an appropriate private mechanism.

Include recovery, not only installation

State what the backup covers and where an independent copy is kept. Explain how a database is restored and which outbound jobs should be disabled in a test recovery.

Have the incoming maintainer rehearse a representative task. A document that has never been followed by another person may still depend on unstated assumptions.

Close old access

Once the handover is accepted, review former staff accounts, keys, bot tokens and integrations. Remove access that is no longer required and rotate shared secrets where appropriate.

Keep the service ID, billing period and support contact in the project record so operational work remains connected to the right purchase. The active-session guide and backup verification checklist are useful starting points for the final review.