Confirm ownership rather than collecting passwords
List the domain registrar, DNS, hosting, source repository, CMS and any paid services. The business should know which account owns each asset and how authorised staff gain access. Prefer invitations and individual accounts to shared credentials. Check recovery contacts and multi-factor authentication while the project team is still available to help.
Ask for an operating guide
Request the deployment steps, routine editing instructions and a description of the environments. The guide should explain how to recognise a failed release and where to find logs. Include backups and the agreed restoration process. A folder of source files alone does not tell a new operator how to run the website safely.
Record licences and ongoing costs
Document subscriptions, renewal dates, extension licences and any restrictions on fonts, photography or other assets. Clarify which accounts are transferred and which remain third-party services. If support is continuing, write down the coverage, contact route and exclusions. Future changes should not depend on assumptions made in an informal launch conversation.
Rehearse a small task
Have an authorised business user edit a page, recover an account or follow a deployment walkthrough as appropriate. Check that the instructions are sufficient without relying on the original developer to fill every gap. Keep outstanding issues visible and agree an owner for each. Handover is complete when the business can operate the agreed scope.
Your practical checklist
- Verify business ownership and recovery contacts
- Collect editing and deployment instructions
- Record licences, renewals and support scope
- Rehearse an agreed operating task
Working through a similar question?
We’re happy to help you find a practical starting point.
Talk to AMGK