Suppose the person who built your website is away when you need to change something. Could someone at the business renew the domain or give another developer access? Could you find a copy of the customer information the site holds?
Those questions belong near the start of a project. A website brings together several accounts and pieces of work, each with its own arrangements. Getting clear about them makes the eventual handover easier to assess.
Start with the domain account
Your domain is the address people type to reach the business. It may also be used for your email, so a change to it can affect more than the website.
ICANN calls the person or organization holding the rights to a registered domain the registrant. Ask which registrar holds the registration and check whose details are attached to it. The business should have an agreed way to access and manage that account.
Check the renewal date and where renewal messages arrive. Decide who checks that the payment method is current. If a provider manages the domain for you, document the arrangement and how you would take over its management.
Use individual access where the service supports it. Keep the account's recovery arrangements available to an appropriate person at the business. Avoid making the only route back into an account depend on a former employee or an outside developer's personal inbox.
Identify what runs behind the address
The domain registration and the website hosting are different services. Hosting is where the website runs. A separate system may hold its database, and another may send its emails.
Ask for a short account list that explains what each service does. Include who manages it and who receives the bill. Record where the information you need to move is stored and how it can be exported.
Some projects use an account dedicated to the business. Others are managed through a provider's service. Discuss the practical consequences of that choice: what you can change yourself, what the provider handles and what a move to another provider would involve.
The useful test is whether you understand how the system is kept running. Having a password written down is only part of that understanding.
Clarify what comes with the source files
Source code is the material a developer works with to change an app or website. It may be kept in a repository, a place that records the files and their revision history.
Ask how your business will receive or access the project files and what instructions another developer would need to run them. Find out whether the handover includes the database structure and the steps used to put a new version online.
Access to files and permission to use them are separate questions. A project may contain custom code alongside libraries, fonts or templates supplied under their own licenses. GitHub's licensing guidance explains why a repository's license matters when others use or change its code.
Ask the developer to identify the terms that apply to the delivered work. Have the agreement state the arrangement for the custom work and any components that carry separate conditions. Resolve questions about those terms before treating a file download as a complete handover.
Try the handover while help is available
Before closing the project, sign in to the accounts you are expected to manage. Make one ordinary content change, or ask the developer to demonstrate the route you will use. Confirm that the account list and instructions describe the finished system.
Then talk through a provider change. What would you receive, what would need moving and who could help with the move? For some hosted products, the portable part may be an export of your information rather than a copy of the underlying software. Establish that distinction before relying on a particular exit plan.
Keep the agreed terms and handover notes somewhere the business can find. Review them when responsibility changes. The goal is to know which decisions you control and who to contact for the work you have chosen to delegate.
