Custom Software Handover: What Your Business Should Receive

01

1. Separate Ownership, Access And Support

These are three different questions. What rights does the agreement give your business? Which accounts can you actually administer? Who is responsible for keeping the application working after launch? Receiving one does not settle the other two.

Put the agreed rights to project-specific code, designs, data and documentation in writing. Identify pre-existing developer components, open-source packages, commercial licences and services that are not transferred with the project. Do not assume paying for a build automatically settles every intellectual-property question. Contract interpretation and disputed rights need appropriate legal advice; this is an operational checklist, not legal advice.

The practical access arrangement should also be explicit. Where suitable, keep the repository and service accounts under a business-controlled organisation, with named people and an agreed recovery route. Give developers the access they need rather than sharing one owner's personal login. A hosted service may use a different model, so confirm its export, administration and exit arrangements instead of assuming you will receive its entire platform.

Finally, distinguish a defect warranty, routine maintenance, hosting, dependency upgrades and new features. Ask which work is included, how issues are reported, what response arrangements actually apply, and what happens when ongoing support ends. These terms belong in the scoped proposal; this guide does not promise unlimited support or a universal response time.

For build-budget questions, use our custom software development cost guide. This checklist focuses on what a usable handover contains.

02

2. Request A Handover Register With Evidence

Copy this register into your project notes. It is an original planning worksheet, not a certification or a list that fits every application unchanged. Add the accountable person, evidence location and acceptance date beside each item. Record secure references, never secret values.

A row marked “not applicable” should explain why. “The developer has it” is not sufficient evidence that your business or its authorised replacement can use it later. Equally, do not request unrelated client repositories or another organisation's secrets simply because they share the same hosting account.

03

3. Make The Code Reproducible, Not Just Downloadable

A ZIP file may be part of delivery, but the receiving developer also needs to identify the release, dependencies, build process and necessary runtime. A folder of source files can be incomplete even when it looks substantial. Ask for setup instructions, the database structure or migrations, required application services, relevant tests, and a list of licensed dependencies that need continued access.

For a PHP application, Composer's documentation explains how an application's lock file records dependency versions and how installation uses those versions. Include that lock file alongside its package manifest. Similar frontend build information may be needed for the user interface. A repeatable setup is not a guarantee that every dependency is secure or that an old version should be kept indefinitely; maintenance is a separate responsibility.

Have the receiving developer prove the agreed setup in an isolated test environment using synthetic or suitably authorised data. They should be able to run a representative workflow, explain required settings and identify anything that is missing. Do not make the production website the experiment for working out undocumented instructions.

Repository transfer also needs an access review. GitHub documents that collaborators and associated webhooks, secrets and deploy keys can remain after a transfer. Moving the repository is therefore not the same as removing the previous provider's access. Confirm the receiving account, plan constraints and permissions, then separately review retained access and connections. Never make project source public just to simplify a handover.

If your main question is what the dashboard should show, start with our business dashboard requirements checklist. Define the useful business result first, then the handover that supports it.

04

4. Demonstrate The Work That Happens Outside The Screen

Many business systems depend on tasks users do not directly see: sending notifications, importing records, processing queued jobs, running scheduled checks or receiving external events. A portal can display correctly while those operations are failing.

Ask the developer to document each background process, its trigger, where progress is recorded, how failures are detected and who responds. Include the accounts, provider subscriptions and limits it depends on. If the application connects to accounting, payment or email services, identify the business-controlled service account and the agreed boundary of responsibility. Do not treat a successful login or homepage screenshot as an end-to-end acceptance test.

Laravel's deployment documentation includes production configuration and handling long-running services during a release. The handover should explain the procedure appropriate to your actual Laravel version and infrastructure; a generic command copied from current documentation is not a complete release plan.

These are hypothetical tests, not a client result or a claim that an unreviewed application already passes them. Use supported sandboxes and controlled test recipients. Do not charge real cards, email real customers or create live jobs merely to demonstrate a handover.

An illustrative field-service portal might pass these four acceptance scenarios:

• Normal work: An authorised staff member opens the right job, changes an allowed status, and the agreed follow-up appears once.
• Restricted work: A different user cannot read or change a job outside their permissions.
• Unavailable connection: An approved test simulates an external service failure; work remains accounted for and the operator sees a useful next step.
• New release: The receiving developer deploys the agreed version to staging and checks both the visible workflow and its background task.

05

5. Check Data, Recovery And Secure Access Separately

An export is only useful if the business can understand it. Define which records it contains, how related records are linked, whether attachments are separate, and how dates, statuses and deleted items are represented. Test a small agreed sample against the source. Do not assume a spreadsheet export is a complete restorable database backup, or that every file stored by the application is included.

For recovery, record the application code, database, uploaded files and necessary protected configuration. Agree retention, acceptable data loss, expected recovery steps and who performs them. Ask for evidence of a scoped restore into an isolated environment, not an untested claim that a backup exists. Our backup restore-testing guide explains how to turn a recovery requirement into a useful test.

Keep the handover register free of passwords and keys. Use an agreed secure method and attributable accounts; grant only required access. OWASP's secrets-management guidance covers access controls and secret lifecycle management. Document where protected values are held, who can retrieve them, and how access is revoked when responsibility changes.

Plan credential changes with dependency checks. An API credential, deploy key and encryption key serve different purposes. Laravel's encryption documentation explains why changing the application key requires care with previously encrypted data. Do not rotate every value blindly or remove the outgoing provider's access before the replacement route is verified, unless a security incident requires a different authorised response.

06

6. Accept The Handover With A Short, Clear Brief

Before signing off, ask the receiving developer or responsible technical person to demonstrate the agreed items, record the exact release tested and list unresolved limitations. Give every unresolved item an owner and a next action. Acceptance should refer to the scoped business result, not just the number of files delivered.

For an existing system, start with what is known. A repository link, technology name, redacted screen and description of the workflow can help scope an initial review. Missing source or unclear rights may limit what can be done; the next step is to establish the facts and authority, not to bypass another provider's access controls.

Ready to make the next stage maintainable? Plan your custom software handover with Ultra IT. We can assess an authorised existing system or scope a new Laravel-based workflow with clear acceptance and ongoing responsibilities. Review work, development, migration, hosting and support are confirmed in the proposal, not automatically included in a website hosting plan.

Use these eight questions to start the conversation:

• What business workflow must remain usable after handover?
• Which code, documentation and usage rights were agreed, and what is excluded?
• Who controls the repository, infrastructure, domain and required third-party accounts?
• Can an authorised developer reproduce the agreed version safely outside production?
• Which data and files can we export, and which recovery steps have been tested?
• Who operates background tasks and responds when a connection fails?
• Which permissions and protected credentials need a controlled review at transition?
• What support, maintenance, training and future changes are included or quoted separately?