How to Hand Over a Laravel Application to a New Development Team

On UK Business Forums, the language is consistent: "the developer no longer works there," "I have no way of editing it," "would you be able to have a quick look?" One poster described arriving at an agency to find the developer had left mid-project, with 24 hours of unbilled work invoiced and the project incomplete. Another asked, simply: "If a company has a site developed by someone, do they own the site, programming code, database, or does the agency who did the work own it?"

That last question — who owns what — is the one most business owners cannot answer until it is too late. And it is only one of several questions that a proper handover resolves before anyone touches the code.

This guide covers what a complete handover actually contains, how long the transition realistically takes, what the law says about code ownership, and what to do when the developer has already gone and left nothing behind.

Related reading in this series: what happens when your developer leaves · security consequences of nobody applying updates · warning signs of liability · the cost of rescue · how to audit an inherited codebase

Why handovers fail

The problem is not the code. It is the context.

A study of 133 popular GitHub projects found that 65% had a "truck factor" of two or fewer — meaning one or two departures would put the entire project at risk (Avelino et al., ICPC, 2016). For a bespoke business application built by a solo developer or small agency, the truck factor is almost always one. That is not a criticism. It is the natural result of how custom software gets built: incrementally, by someone who knows the business, rarely with the time or budget to document every decision.

There is a useful distinction between explicit knowledge (what is written down) and tacit knowledge (what lives only in the developer's head). A handover is supposed to convert the second into the first. When that conversion does not happen, the next developer spends weeks rebuilding context that the previous developer held effortlessly.

The data on this rebuilding cost is consistent:

• 61% of professional developers spend more than 30 minutes every day just searching for answers or solutions. 7.6% lose over two hours daily (Stack Overflow Developer Survey, 2024 — 28,911 respondents).
• 30% of developers say knowledge silos impact their productivity ten or more times per week (Stack Overflow, 2024).
• Teams with high-quality documentation are 2.4 times more likely to see better software delivery and operational performance — but only about 25% of teams have documentation good enough to achieve this (DORA / Google Cloud, 2021 — approximately 1,200 respondents).

What a complete handover actually contains

Most developers think a handover means handing over the Git repository URL. Most business owners think it means handing over the login details. Both are wrong.

A complete handover has five layers. Missing any one of them creates problems that compound over time.

Layer 1: Access and credentials

This is the layer that causes the most immediate damage when missing. It covers:

• Domain registration — who controls the DNS
• Hosting account — server credentials, SSH keys, deployment pipeline
• Git repository — source code and full commit history
• Third-party services — Stripe, Mailgun, AWS, any API the application depends on
• Database — connection credentials and backup locations
• SSL certificate — who issued it, when it renews, who controls renewal

The UK's National Cyber Security Centre publishes explicit guidance through their "Joiners, Movers, and Leavers" policy framework: access must be revoked when no longer needed, and if third parties had access, non-disclosure agreements should be in place and access must be revocable (NCSC, 10 Steps to Cyber Security).

How common are access problems? Only 40% of UK businesses use two-factor authentication, and only 68% restrict admin rights. Loss of access to files or networks rose from 4% to 7% year-on-year — a statistically significant increase (UK Government Cyber Security Breaches Survey, 2025 — 2,180 businesses surveyed by Ipsos).

Nominet resolved 608 UK domain disputes in 2024, with 45% resulting in a domain transfer. Estimated saving in court costs: £8.15 million (Nominet, 2025). Many originate from exactly this scenario — a developer registered the domain in their own name, the relationship ended, and the business discovered it did not control its own web address.

Approximately 29 million new secrets (API keys, database passwords, tokens) were leaked to public GitHub repositories in 2025 — a 34% year-on-year increase. Of secrets leaked in 2022, 70% were still active and unrevoked two years later (GitGuardian State of Secrets Sprawl, 2026). During a handover, exposed credentials in the Git history are not just a security problem — they are a liability the new team inherits.

The action: document every credential, every account, every access point in a single secure location before the departing developer's last day. If they have already left, reconstructing this list is the first priority — before any code review, before any feature work.

Layer 2: The codebase and its history

The source code, hosted in a Git repository the business owns. Not a fork, not a copy — the original repository with the full commit history. That history is the closest thing to a decision log most projects have. It shows when changes were made, what they contained, and sometimes why.

The repository should also contain:

• composer.json and composer.lock — every PHP dependency and its pinned version
• package.json and lockfile — frontend dependencies
• .env.example — environment configuration template
• Database migration files — the full history of structural changes
• Seed data for development environments

Layer 3: Documentation

This is where most handovers fall short. The documentation a new team actually needs, in priority order:

A README with setup instructions. Not "install Laravel" — the specific steps to get this application running locally: environment variables, required services, database setup, non-obvious configuration. 56% of PHP developers work in teams of two to seven (JetBrains State of PHP, 2025 — 1,720 respondents). In that context, the README is often the only onboarding document.

Architecture documentation at the right level. Simon Brown's C4 model (created 2006–2011, now the industry standard) defines four levels: Context, Container, Component, and Code. For a handover, Levels 1 and 2 are essential. Level 3 helps for complex modules. Level 4 should only exist if your tooling generates it automatically — it goes stale the moment someone edits the code.

Architecture Decision Records (ADRs). Michael Nygard proposed the format in 2011: a short document with four sections — Title, Context, Decision, Status — stored in the repository as numbered Markdown files. ThoughtWorks placed ADRs in "Adopt" on the Technology Radar. Martin Fowler's guidance: keep each record to a single page. ADRs answer the question the next developer asks most often: "why was it built this way?"

Deployment documentation. How the application gets from a developer's machine to production. If the process needs SSH access and commands in a specific order, that process must be written down. If there is a CI/CD pipeline, the pipeline config is the documentation — but someone still needs to explain how to trigger it and what to do when it fails.

Business logic documentation. Pricing calculations, approval workflows, user role hierarchies, integration logic with third-party systems. These are the areas where the code alone is not enough because the "why" is not visible in the "what."

Layer 4: Legal ownership

Under the Copyright, Designs and Patents Act 1988, section 11, the rules are precise and frequently misunderstood:

• Employee developed the code in the course of employment → you own the copyright automatically (unless a contract says otherwise).
• Contractor or freelancer developed the code → they own the copyright (unless a contract explicitly assigns it to you). This is not an edge case. The leading UK authority is Robin Ray v Classic FM plc (1998), where the court held that a contractor retains copyright unless the contract assigns it. Even where a licence can be implied, only a non-exclusive licence will be implied — not a full assignment.

The IPO's own guidance is blunt: "When you ask or commission another person or organisation to create a copyright work for you, the first legal owner of copyright is the person or organisation that created the work and not you the commissioner, unless you otherwise agree it in writing."

The practical consequence: if your developer was a contractor and your contract does not have a written IP assignment clause, you may not own your code. You may hold an implied licence to use it for the purpose it was commissioned — but that licence may not cover modifying the code, engaging a new developer to work on it, or sublicensing it.

Establish this before the handover begins, not after. It is cheaper to resolve IP ownership while both parties are still on speaking terms.

More on escrow arrangements, exit clauses, and G-Cloud contract templates: Legal Foundations Tech Founders Overlook.

Layer 5: The state of the application

Not what the code says. What the application actually does in production:

• Current PHP and Laravel versions — and whether they are still supported
• Outstanding bugs and known workarounds
• Scheduled tasks (cron jobs) and background processes
• Third-party integrations and their current status
• Performance baselines — typical response times, error rates, server resource usage
• Technical debt the departing developer is aware of but has not documented

This layer is the most frequently omitted and the most expensive to reconstruct. The audit guide covers how to establish this information when nobody is available to ask.

How long the transition actually takes

Longer than anyone budgets for.

IT workers take an average of seven months to reach full productivity in a new role (Oxford Economics). That figure covers all IT roles, not just developers inheriting unfamiliar codebases. For taking over undocumented custom software, the realistic range is six to twelve months before genuine independent productivity.

A peer-reviewed Microsoft study found that a typical onboarding task is scoped to one to four weeks. Documentation problems and code issues were the most persistent barriers newcomers faced (Ju et al., ICSE, 2021 — 32 developer interviews, 15 manager interviews, 226 survey respondents).

DX (formerly GetDX), which tracks developer onboarding metrics, reported in Q4 2025 that time to a new developer's tenth pull request — their proxy for productive contribution — was 91 days without AI tools and 49 days with daily AI use. By April 2026, the cross-dataset average was 33 days. But those figures come from large multinationals with established onboarding programmes. A UK SME with a sole-developer codebase and no documentation should expect worse.

Note: DX/GetDX sells onboarding analytics — these figures are vendor data, not independent research. The direction is consistent with independent findings, but the precision should be treated with caution.

69% of developers reported losing eight hours or more per week to inefficiencies, with insufficient documentation cited as a primary friction point (Atlassian/DX State of Developer Experience Report, 2024 — 2,100 developers, four countries — vendor-commissioned).

The practical translation: if a Laravel application was built by a solo developer with no documentation, the replacement developer — freelance, agency, or in-house — will spend the first one to three months understanding what exists before producing meaningful new work. That is not incompetence. It is the measurable cost of tacit knowledge that was never made explicit.

The most effective way to compress that timeline: invest in documentation before the transition — or commission a structured assessment immediately after. The Platform Discovery Sprint is a three-week, fixed-fee engagement at £4,500 that produces a written technical assessment, architecture diagram, phased roadmap, and a Code Health Scorecard. It compresses months of unstructured learning into a structured deliverable the next team can use from day one. The Sprint fee is credited against any subsequent build.

The planned handover: developer still in notice period

There is a window. Use it. Every day of structured handover activity during notice saves weeks of reconstruction afterwards.

Week 1 — Secure access

Verify that the business holds direct ownership of:

• Domain name (check via Nominet WHOIS for .uk domains)
• Hosting account
• Git repository
• Every third-party service account the application depends on If any of these are registered under the developer's personal email, transfer them now. Not next week.

Create a credential register: a single document listing every account, login, API key, and SSH key, with access levels and the person who holds each. Store it in a password manager the business controls — not a shared spreadsheet.

Week 2 — Extract documentation

Sit with the departing developer and have them walk through the application at the architecture level — not the code level. Record the conversation if they consent.

Questions to ask:

• How is the application deployed?
• What scheduled tasks run, and when?
• What are the critical third-party integrations?
• What breaks most often, and why?
• What would you fix first if you had time?
• Where is the technical debt?

Get them to write — or dictate — three documents at minimum: a README covering local setup, a list of environment variables with explanations, and the deployment procedure. If they produce nothing else, these three are the minimum viable handover.

If the codebase has no automated tests, ask the developer to identify the three most critical user paths (login, payment, data submission) and write down the steps to test them manually. Not a test suite — a smoke-test checklist that prevents the next developer from shipping a change that breaks what the business depends on most.

Week 3 — Verify and overlap

Have the incoming developer or agency attempt to set up the application locally using only the documentation from Week 2. Every question they ask reveals a gap. Fill the gaps while the departing developer is still available.

Run composer audit and npm audit to surface known vulnerabilities. Check PHP and Laravel versions against current support status. If the application is on end-of-life software, that finding shapes the incoming team's priorities. More on what version upgrades involve: Laravel Version Upgrades.

Week 4 — Final handoff

• Confirm every item in the credential register is accessible by someone other than the departing developer
• Confirm the incoming team can deploy to production independently
• Archive the departing developer's access
• Document the handover as complete — or document what remains incomplete and who owns each outstanding item

The unplanned handover: developer already gone

This is the more common scenario. The developer left weeks or months ago. Nobody noticed until something broke, a client complained, or a compliance deadline arrived.

The priorities invert. In a planned handover, start with documentation and work toward access. In an unplanned handover, start with access and work toward understanding.

Day 1–3 — Secure what you can reach

Check whether you can access the domain registrar, the hosting dashboard, and the Git repository. If you cannot, contact the registrar or hosting provider directly — as the business owner, you have rights to accounts registered in your business's name. For UK domains, Nominet's dispute resolution process handles uncooperative registrants.

If the developer held credentials in their own accounts and is unreachable, most major providers (Stripe, AWS, DigitalOcean) have account-recovery processes for businesses that can prove ownership.

Week 1–2 — Establish the facts

Before commissioning any work — before hiring a replacement, engaging a freelancer, or signing with an agency — understand what is actually running in production. Not what you think you have.

The non-technical checks — domain ownership, server access, Git access, backup verification, last deployment date, documentation existence — take less than an hour and cost nothing. Full audit process: How to Audit a Laravel Codebase You've Inherited.

For a professional assessment — automated scanning with PHPStan, SonarQube, and composer audit, plus manual expert review — the Platform Discovery Sprint delivers a Code Health Scorecard with a fix, refactor, or rebuild recommendation per component. The output: a clear picture of what the application needs and what it would cost to stabilise.

Week 3+ — Establish ongoing support

An inherited application without a maintenance arrangement is not standing still. It is ageing. PHP and Laravel both follow fixed support lifecycles — the security article documents the specific CVEs, exploitation timelines, and ICO enforcement actions.

The difference between ad-hoc freelancer support and a structured retainer comes down to economics. On an ad-hoc model, roughly 43p of every pound goes to productive work. On a retainer with a team that already knows the codebase, that figure is closer to 74p. The difference is re-onboarding cost — paid once on a retainer, paid again with every new freelancer. More detail: What a Laravel Support Retainer Actually Covers.

Tools that make handovers easier

The audit guide covered the diagnostic toolkit (PHPStan, Larastan, SonarQube, Enlightn, PHPMD, Rector). A different set of tools helps with the handover itself — generating documentation from the existing codebase rather than writing it from scratch.

Scribe generates API documentation directly from Laravel routes — request parameters, response examples, authentication requirements. Over 12.7 million Packagist installs. For any application with an API layer, running Scribe is one of the highest-value, lowest-effort documentation steps available.

Deptrac enforces and visualises architectural boundaries. It generates dependency graphs showing which parts of the code depend on which — the map an incoming team needs to understand what is safe to change and what is load-bearing. Nearly 3 million Packagist installs, with optional Mermaid.js output for visual diagrams.

Laravel Shift Workbench provides over 60 automated tasks for maintaining and modernising Laravel applications. During a handover, the linting and standardisation tasks bring inherited code into line with current Laravel conventions, reducing cognitive load on the incoming team.

phpDocumentor generates class-level documentation including UML diagrams from PHP source code. This corresponds to Level 4 of the C4 model — code-level documentation that should only exist if generated automatically.

Teams with above-average documentation saw 750% improvement from continuous integration, versus 34% for teams with below-average documentation. The multiplier from trunk-based development was 1,525% versus 36% (DORA, 2022). Documentation does not replace good engineering. It makes every other investment work harder.

What it costs to get the handover wrong

The median UK salary for a permanent Laravel developer is £55,000 (90th percentile: £72,500). Contractor day rates sit at a median of £413 (IT Jobs Watch, 2026). A 30-day contractor engagement to cover a handover gap implies approximately £12,400 before agency margins or IR35 loading — and a significant portion of those 30 days will go to understanding the codebase, not delivering features.

The average cost of the most disruptive cyber breach is £3,550 for businesses and £8,690 for charities. Micro and small businesses averaged £2,240, large businesses £17,970 (UK Government Cyber Security Breaches Survey, 2024–2025). A failed handover where credentials are not revoked and patches are not applied creates exactly the conditions that lead to these costs.

The ICO fined a password management provider £1.2 million in December 2025 after attackers exploited inadequate access controls, affecting up to 1.6 million UK users (ICO, 2025). The root cause was access management failure — the same category of failure that occurs when a developer departs without a structured handover and nobody revokes credentials.

The indirect cost is harder to quantify but often larger: features that do not get built, clients that do not get served, opportunities that pass while the business is consumed by a transition that should have taken weeks but takes months.

Retainer support for inherited applications

Most retainer clients come in mid-transition. The developer left, the application kept running, months passed, and eventually something broke.

The first step on any new retainer is a structured onboarding review using hours from the first month. The codebase gets reviewed, risks identified, and findings documented. That documentation becomes the foundation for ongoing maintenance — and it grows with every month of service. Progressive documentation is not a premium add-on. It is how responsible maintenance works.

The Laravel Support Retainer has four tiers:

Professional — £450+VAT/month · 6 hours · Next-business-day response · Hours do not roll over · Overage: £85/hr

Business — £750+VAT/month · 10 hours · Same-day response for urgent issues · Up to 2 hours roll over · Overage: £80/hr

Enterprise — £1,250+VAT/month · 20 hours · 4-hour response for critical issues (site down or security breach) · Full rollover with cap · Overage: £75/hr

Premium — From £2,000+VAT/month · 30+ hours · Dedicated senior developer · Full rollover with cap · Overage: £70/hr

All tiers: three-month initial term, then rolling monthly with 30 days' notice.

Scope boundary: tasks under 1–2 hours are handled within the retainer. Tasks at 2–4 hours are flagged before work begins. Anything over 4 hours is quoted separately. New features — anything adding functionality that does not currently exist — are always quoted separately. That boundary is contractual, not implied.

What is in scope: corrective maintenance (bug fixes), adaptive maintenance (browser changes, API changes, PHP and Laravel version upgrades), preventive maintenance (progressive refactoring, documentation, technical debt reduction).

For applications whose state is unknown — where basic questions about PHP version, Laravel version, or dependency health cannot be answered — the right starting point is the Platform Discovery Sprint, not a retainer. The Sprint establishes the facts. The retainer maintains them.

The handover checklist

Print this. Share it with your departing developer. Use it to verify completeness.

✅ Access and credentials

• Domain registrar login (business-owned)
• Hosting / server dashboard login
• SSH keys or deployment credentials
• Git repository access (business-owned account)
• Database credentials (production, staging, local)
• All third-party API keys and service logins
• SSL certificate details and renewal info
• DNS management access

✅ Codebase

• Full Git repository with complete commit history
• composer.json, composer.lock, package.json, lockfile
• .env.example with annotated variable descriptions
• All database migration files
• Seed data for development environments

✅ Documentation

• README with local setup instructions
• Architecture overview (C4 Levels 1–2 minimum)
• Architecture Decision Records for non-obvious design choices
• Deployment procedure (step-by-step)
• Business logic documentation for critical workflows
• Scheduled tasks and background processes documented
• Known bugs and workarounds listed

✅ Legal

• Written IP assignment clause in the contract
• Confirmation that the business owns all code, assets, and documentation
• Third-party licences and open-source obligations documented

✅ Application state

• Current PHP and Laravel versions confirmed against support status
• composer audit and npm audit results reviewed
• Performance baseline documented (load times, error rates, server resources)
• Backup schedule and last verified restore date
• Outstanding technical debt listed and prioritised

What to do this week

If your developer is leaving: start the credential register today. Every item verified while they are still available saves hours of reconstruction later.

If they have already gone: the non-technical checklist — domain ownership, server access, Git access, backup verification, last deployment date, documentation existence — takes less than an hour and costs nothing. Every answer of "I don't know" is a data point.

If three or more answers are "I don't know": a professional assessment will save more than it costs. The Platform Discovery Sprint — £4,500, three weeks, credited against any subsequent build — turns uncertainty into a documented, actionable plan.

If the application is maintainable: the Laravel Support Retainer puts it on a structured path from £450+VAT per month — with onboarding review, progressive documentation, and security patching that prevent the next handover from looking like this one.

The goal is the same either way: an application with no single point of failure, documented well enough that the next person — whoever they are — can pick it up and keep it running.

That is what a proper handover delivers. Everything else is a departure.