Ask for five things: access to the code repository from the first day, every account opened in your company's name, written instructions for deploying the system, a list of the third-party services it depends on with their logins, and database backups you have restored at least once. With those in hand, another developer can pick the system up without the original one.
Owning the code on paper is not the same as being able to use it. The test of a handover is practical: could a competent stranger get the system running from what you hold, with no phone call to the person who built it.
Repository access from day one
A handover that happens at the end of a project happens at the worst moment, when the relationship may be strained or the developer busy elsewhere. Ask instead for the repository to be created under an organisation account that your company owns, with the developer invited into it. You then hold the full history of every change as it is made, and there is nothing left to hand over later.
Accounts in your name
Custom software leans on outside services. If those accounts belong to the developer, so does your ability to keep running. For a conference or trade show system, the list may include:
- Hosting and the database.
- The domain name and its DNS settings.
- The service that sends registration confirmations and exhibitor emails.
- The payment processor account that takes delegate and stand fees.
- App store accounts, if there is an event app.
- Text messaging, badge printing, mapping or floor plan services.
- Analytics and error reporting.
Each should be registered to a company email address, billed to a company card, and have its administrator login kept in a password manager that more than one person on your side can open.
Documentation a stranger could follow
You do not need a manual for every screen. You need a short document that explains how to set the system up on a new server, which settings and secret keys it expects, which jobs run on a schedule, and how to release a change. The honest way to test it is to ask a second technical person to follow it without help. Do that in a quiet month, not in the weeks before a show when registration, the exhibitor portal and lead capture are all under load.
Backups you have actually restored
Ask where database backups are stored, how frequently they are taken and how long they are kept. Then ask for one to be restored into a test copy of the system while you watch, and look up a delegate and an exhibitor you know. Uploaded files such as floor plans, logos and contracts need backing up as well, and are easy to forget because they sit outside the database.
Escrow and the contract wording
Source code escrow is an arrangement where an independent third party holds a copy of the code and releases it to you under conditions agreed in advance, for example if the supplier stops trading. It is worth knowing about for larger deals in which you license software from a supplier and do not own it. Where you own the code and hold the repository yourself, there is little for escrow to add.
The contract should say who owns the code, when ownership passes, and how it treats components the developer brought with them and open source libraries. Ask a lawyer to review the actual wording. We cannot tell you what a clause means in your jurisdiction.
Our guide to renting versus owning business software goes further into data ownership and who maintains a system after it is built. If you are deciding whether ownership is worth the effort, our calculator for software bills shows what your rented tools cost over three years. With Hiro, the customer owns the code and the data and can take both whenever they like. Our page for conference and trade show organisers sets out what can be rebuilt.