Before changing your development supplier
· Veylund B.V.
A code export is not a completed handover. Before changing supplier, check whether the receiving team can run, change and support the product.
Decide what needs to change
Write down the problem behind the move: missed commitments, unclear costs, access gaps or knowledge held by too few people. Compare a transfer with changing the scope or working arrangement. A new supplier will not resolve an unclear brief on its own.
Build one handover list
- Access: identify who controls repositories, hosting, domains, deployment tools and third-party accounts. Verify the access the receiving team will need.
- Rights and obligations: establish what can be transferred, which licences apply and which contractual questions need qualified legal review.
- Operation: collect the steps for deployment, monitoring, support, backups and recovery. Record known problems and unfinished work.
- Product knowledge: explain important decisions, customer commitments and dependencies that are not obvious from the code.
- Owners: assign a receiving person and an acceptance check to each item. “Documentation sent” is not the same as “understood and tested”.
Test the handover before closing it
Ask the receiving team to demonstrate an agreed change and deployment in a safe environment, work through a support scenario and explain the recovery procedure. Record gaps while the outgoing supplier is still available.
Agree a cutover sequence, support overlap and a fallback plan. Transfer privileged access through approved channels; do not put passwords in the checklist. Remove outgoing access only when the transfer and remaining support obligations allow it.
Leave with a decision, not just a folder
The useful output is a clear decision to proceed, delay or change the plan, with named owners for remaining risks. Technical security reviews and contract advice need their own scope; a coordination checklist does not replace them.