A software handover checklist helps Kenyan businesses take operational responsibility for a new system with clear access, documentation, and support arrangements. Launching a website or application is a visible milestone, but the business still needs to understand who controls essential accounts, how routine work is supported, and what happens when something goes wrong.
This guide explains what to request before accepting a custom platform, portal, or business application. It covers ownership, operating information, testing evidence, training, and maintenance. The aim is a usable handover that employees and future support teams can follow, rather than a folder of documents nobody has checked or a promise that the developer will always be available.
Define handover before the final week
Agree handover deliverables during project planning, not after the last feature is built. The contract or scope should identify what the business receives and which responsibilities remain with the supplier. Some arrangements include ongoing managed services, while others transfer more operational control to the client. Both require clear boundaries.
List the people who need to participate. A business sponsor, operational manager, technical representative, and support contact may each own different parts of the handover. Assign a person to confirm every important deliverable. Without ownership, documents may be sent but never reviewed, and missing access may be discovered only during an urgent incident.
Confirm what was actually delivered
Start with an agreed feature and workflow list. Compare the delivered system with the approved scope and recorded changes. Identify anything postponed, replaced, or delivered through a different method. A final demonstration should show the actual deployed application rather than a separate environment whose behaviour or configuration may differ.
Record known limitations honestly. Some are acceptable operating constraints, while others may be unresolved defects. Distinguish them clearly and give each outstanding item an owner and next step. The business can make an informed acceptance decision only when it understands what is complete and what still needs attention.
Review acceptance evidence
Ask for the results of the agreed tests and business acceptance scenarios. Focus on the workflows that matter most: signing in, submitting requests, approving changes, processing payments, finding records, or producing reports. Evidence should show that the expected results were achieved, including relevant permissions and important failure cases.
Do not treat a general statement that the system was tested as a substitute for agreed acceptance criteria. Business representatives should recognise the examples and confirm that they reflect actual work. Keep the approved results available so future changes can be checked against a reliable description of the original behaviour.
Identify accounts and their owners
Prepare an inventory of essential accounts and services. Depending on the project, this may include hosting, domain registration, email delivery, messaging, payment integration, analytics, source repositories, and backup services. Record the business owner, billing contact, renewal responsibility, and authorised administrators for each relevant account.
Access should be established through appropriate invitations and role assignments rather than sharing one person’s credentials across the team. Confirm that recovery arrangements remain available if an employee leaves. The goal is continuity of authorised control, not unnecessary access for everyone involved in the project.
Clarify source code and licensing arrangements
Confirm what rights and materials the agreement provides, including access to custom source code where applicable. Identify third party components, commercial licences, and services that remain subject to separate terms. A business should understand what it can maintain, transfer, or extend without assuming every part of a system is owned outright.
Ask for a clear list of relevant dependencies and restrictions. If the project relies on a paid service, explain what happens if its subscription ends. Where the commercial arrangement is unclear, resolve it with the appropriate advisers before relying on an assumption. Technical access alone does not answer every ownership or licensing question.
Make deployment information usable
Deployment documentation should explain the environments, required services, configuration responsibilities, and process for releasing changes. It should identify which steps are automated and which need authorised human action. A future support team needs enough context to operate the application without guessing how the original developer assembled it.
Keep secrets out of ordinary documentation. Describe how authorised staff obtain and manage credentials through the agreed secure process. Include the location of operational records and the person responsible for keeping them current. Documentation loses value quickly when service names or procedures change without anyone updating the handover materials.
Check backup and restoration arrangements
Ask what is backed up, how often, where copies are stored, and who monitors the process. Consider application data, uploaded files, and other materials needed for recovery. A backup of one database may not recreate a working service if essential documents or configuration information are stored elsewhere.
Request evidence of a suitable restoration test rather than relying only on a message that backups are running. Agree acceptable recovery expectations and identify any limits. The business should understand how much recent work might need reconstruction and how long critical operations could be affected under the proposed arrangement.
Document payment and integration behaviour
For every important connection, identify the external service, purpose, account owner, failure symptoms, and support route. Explain how the application handles delayed responses, retries, and duplicates. Employees need to know when to wait, when to investigate, and when to escalate without accidentally repeating an action that has already succeeded.
For M-Pesa integrations, Safaricom’s Daraja developer portal is the official reference for its API platform. The project handover should describe your implemented workflow and configuration responsibilities. General provider documentation does not replace the application specific explanation of how payments are matched, verified, and investigated by your business.
Review access and security responsibilities
Confirm the available user roles, account approval process, administrator responsibilities, and route for removing access. Check that temporary project access is handled according to the agreed support arrangement. Decide who reviews permissions after launch and how significant changes are approved, especially where the application holds sensitive business records.
Use the OWASP Top 10 as background when discussing web application risks. Ask what security work was actually included and what evidence is available. Avoid treating a logo, checklist reference, or general assurance as equivalent to a documented assessment of your deployed application and its configuration.
Include accessibility and ordinary usability
Handover should preserve knowledge of the people who use the system and the devices they rely on. Record important accessibility decisions and any known limitations. Check critical forms, navigation, and messages using the agreed user scenarios so the business does not accept a platform that only works comfortably for the project team.
W3C’s introduction to web accessibility provides useful background for these discussions. Ask how accessibility will be considered during future changes. A working launch experience can regress when new fields, buttons, or document workflows are added without the same attention given to the original design.
Prepare role specific user guides
Write instructions around tasks rather than every button on every screen. A customer service employee may need to find an account and update a request. Finance may need to investigate a payment difference. Administrators may need to invite users and apply approved permissions. Each guide should match the work its reader actually performs.
Use examples and terminology from the deployed system, with private information removed. Include common mistakes, expected results, and escalation routes. Keep the guide short enough to consult during work. A lengthy manual is not useful if employees cannot quickly find the steps for a routine task that has become blocked.
Train the people who will support colleagues
Identify internal staff who can answer ordinary questions and distinguish an operating issue from a software defect. Give them practice with realistic scenarios, including errors and recovery steps they are authorised to perform. This reduces the need to send every small question directly to the development team.
Document the limits of internal support. Staff should know when a correction requires specialist review or when they must preserve evidence before making changes. Encourage clear reports with references, observed behaviour, and expected results, while avoiding unnecessary sharing of customer information or credentials in screenshots and messages.
Agree incident and support procedures
Define how issues are reported, who receives them, and what information is required. Distinguish a complete service outage from a minor display problem or a request for a new feature. These categories help the support team prioritise work and help the business understand the response it should expect.
Clarify working hours, escalation contacts, and responsibility when a third party service is involved. A promise of support is incomplete without explaining its scope. Record what the business should do while waiting, especially where a critical process needs a temporary alternative to keep operations organised.
Separate defects, maintenance, and new requirements
A defect is not the same as a new feature request. Maintenance may cover updates, monitoring, and agreed support, while changes to business rules or additional modules may require separate work. Define these distinctions in terms that both the client and supplier understand before a disagreement arises.
Review the duration and scope of any post-launch defect support. Confirm how requests are estimated, approved, scheduled, and tested. Keeping a change record helps the business track what was requested and why, while preventing informal conversations from becoming conflicting expectations about features that were never included in the agreement.
Understand ongoing costs and renewals
Create a schedule of recurring costs, including hosting, domain renewal, messaging, payment related services, commercial licences, and agreed maintenance. Identify which charges are fixed and which vary with use. Assign responsibility for reviewing invoices and responding before a service expires or reaches a limit.
Ask what happens when usage grows. More users, storage, messages, or transactions may change operating requirements and costs. The handover does not need to predict every future expense, but it should explain the main dependencies and the signals that indicate a capacity or subscription review is needed.
Rehearse continuity without the original developer
Have an authorised colleague use the documentation to complete a routine operating task while the project team observes. This can reveal missing steps, unclear account ownership, or instructions that assume knowledge never written down. The rehearsal should stay within approved permissions and avoid unnecessary changes to live business records.
Resolve material gaps before treating handover as complete. A useful test is whether the business knows whom to contact, where to find the necessary information, and how to continue safely when the original developer is unavailable. Continuity depends on clear arrangements, not on expecting one individual to remember everything indefinitely.
Plan handover as part of a Zama project
Zama’s software development services provide a starting point for discussing custom platforms and operational systems. Include handover deliverables in the scope from the beginning. Review Zama’s maintenance services and agree the application specific coverage required for your integrations, users, and operating hours.
For retail businesses using Vega POS, distinguish subscriber onboarding and support from a custom development handover. Different commercial models provide different access and responsibilities. Contact Zama with the system type and your continuity needs so the discussion addresses the arrangement you actually require.
Frequently asked questions
Is handover complete when we receive passwords?
No. Access is only part of handover, and it should use an appropriate secure process. The business also needs ownership clarity, operating instructions, support routes, acceptance evidence, and an understanding of recurring responsibilities.
Do we need an internal technical employee?
That depends on the system and support model. Even with managed support, appoint a business owner who understands the responsibilities and escalation process. Specialist technical work can remain with an appropriately scoped provider.
Schedule a follow-up review after employees have used the system in ordinary operations. Confirm that documentation remains accurate, support contacts work, and recurring tasks have named owners rather than relying on informal assumptions.
Take responsibility with confidence
A useful software handover leaves your business able to operate, support, and plan the next stage of its system. For a project or handover discussion, call 0725345345 or chat with Zama on WhatsApp. Start with the responsibilities that must remain clear after launch.