Switching Laravel agencies: how a new team takes over your project

Switching Laravel agencies isn't a fresh start — it's a handover. A new team reads into the existing code, checks its condition, versions and dependencies in an audit, takes over access and deployment, and works on your application from there. On a well-maintained project that ramp-up takes a few days; on a neglected one, one to two weeks. Your application doesn't have to be paused for it, and it definitely doesn't have to be rebuilt.

Even so, it's the decision most business owners put off the longest. Because they're afraid "the new guys" will trash-talk everything and try to sell them a rewrite. That fear is justified — which is why we're writing down here how a serious takeover actually goes.

How to tell the switch is overdue

In the projects that land with us, it's almost always the same patterns. If you recognize yourself in two or more of them, switching isn't nervous energy — it's a business necessity:

• Nobody answers anymore. The freelancer gets back to you after three days, the agency pushes every meeting. For a production system that carries your day-to-day business, that's an outage risk.
• Small things take weeks. One extra field in a form is a half-day job. If that turns into a ticket that sits for a month, either the prioritization or the codebase is off.
• You get invoices, never estimates. The honest way: rough estimate up front, bill after. If you're being surprised systematically, transparency is missing.
• Exactly one person understands the system. That's the most dangerous state of all — more on that below.
• The Laravel version is years old. If your project still runs on Laravel 8 or 9 with PHP 7.4, you're no longer getting security updates. Every month makes the upgrade more expensive.
• Nobody dares to deploy anymore. If a release is a ritual with a knot in your stomach, tests and automated deployment are missing.
• You can't get at your own credentials. Server, repository, domain, database — if all of that sits with your service provider and you have no admin access, your product is effectively only half yours.

That last point is the one that makes us prick up our ears most often. Everything else can be repaired. Missing access is a question of power, not technology.

What a serious takeover audit checks

Before anyone touches a line of code, an audit belongs at the beginning. It answers exactly one question: what condition is this project really in — and what does it cost to keep it going? These are the points we work through:

1. Laravel and PHP version. Which version is running, is it still getting security updates, how big is the jump to a current version? Laravel ships a major version every year; bug fixes and security patches have a limited window. A project two versions behind is normal, five versions behind is a project of its own.

2. Dependencies. A look at composer.json and package.json says more about a project's condition than any presentation. How many packages are abandoned — untouched for years? Are there known security vulnerabilities? Have packages been patched from inside the vendor directory, a pattern that blows up every update?

3. Code quality and structure. Not "pretty or ugly", but: does the code follow Laravel conventions? Is business logic stuffed into 2,000-line controllers? Are there N+1 query problems that slow the application down under load? Are migrations complete, so the database can be built up straight from the repository?

4. Tests. Is there a test suite, does it pass, and does it cover what earns money — checkout, billing, permission checks? Missing tests aren't a deal-breaker, but they decide how quickly we'll dare to change anything afterwards.

5. Environments and deployment. Is there a test or staging system alongside production? How does code get onto the server — through a pipeline, or by hand over FTP? Do backups exist, and has a restore ever been tested?

6. Documentation and access. Is there a setup guide that gets the project running locally? Is every credential complete: Git repository, server/SSH, database, domain and DNS, mail delivery, payment provider, external APIs?

How a takeover works with us

We've done this often enough by now that it follows a fixed sequence. Not process theater — just the order that makes risks visible early:

1. First call (free, about 30 minutes). You tell us what the system does, where it's stuck and what you're planning next. We tell you honestly whether we're the right fit. Sometimes the answer is: "stay with your provider and insist on X."
2. Read access to the repository. Even half a day of reading code tells us more than any description. If you like, we'll sign an NDA first — that's routine for us.
3. Audit with a written result. We work through the six points above and hand you a plain-language document: condition, concrete risks sorted by urgency, and what fixing each one costs. The document is yours — even if you go on to work with someone else.
4. Infrastructure takeover. Repository, server, deployment, monitoring, backups. We build the project locally on our machines and set up a staging system if there isn't one. Only once a release runs through reproducibly have we really taken over.
5. Ship one small change to production. Deliberately something unspectacular: a field, a bit of copy, a bug fix. That's the real acid test — afterwards both sides know the chain from ticket to production works.
6. Stabilize, then build on. Security-relevant updates and the worst risks first. Then the roadmap you actually switched for.

How we work in general — test-driven, in short cycles, with traceable effort — is described in our process. None of that changes for a takeover.

The three risks that really hurt

Knowledge monopoly

The most common and most expensive problem. A single developer built the system over years, everything in their head, nothing written down. If they drop out, nobody's left who knows why the invoicing logic works the way it does.

You can defuse this with a handover on good terms: one or two joint sessions with the previous developer, paid and treated with respect. That's the cheapest hour you'll buy in the whole project. If that's no longer possible, we reconstruct the logic from the code — takes longer, but it works. In parallel we write down what we learn. Not as an 80-page manual, but as a living README that's enough for the next person to be up and running in a day.

Outdated versions

Old Laravel and PHP versions aren't a cosmetic flaw, they're a security question. Without patches, every vulnerability that becomes public stays open. The mistake we see most often here: the upgrade gets planned as a big bang — touch everything at once, then hope.

We go the other way: one major version at a time, each one tested and deployed separately. If no tests exist, we write some first for the areas that earn money. It feels slower and ends up faster, because after every step there's a state that provably runs. On very old systems the question can come up whether an upgrade or a real migration makes more sense — how we weigh that is in our post on replacing legacy software.

Missing tests

Without a test suite, every change is flying blind. The good news: you don't need 100% coverage to become capable of acting. The critical paths are enough — login and permissions, orders or bookings, billing, outbound interfaces. In our experience, a handful of well-chosen feature tests covers the bulk of the real risk and can be written in a few days.

What the switch costs — honestly calculated

Here's where it gets concrete, because you need to be able to plan for it:

• The first call costs nothing. 30 minutes in which we tell you whether and how we can help.
• We bill audit and ramp-up by time at €79/h. For an average Laravel project, experience puts us at one to three days. If the code is well maintained, it's less; if it's a grown system with no tests and no documentation, more. We tell you up front what range we're expecting, and we get in touch before we exceed it — not after.
• A larger upgrade or a stabilization phase gets calculated as its own capped package. You know where you stand before we start.
• Ongoing support starts at €119/month. That covers updates, monitoring, backup checks and a fixed point of contact. Why that isn't an optional extra is something we wrote up in why software maintenance matters.
• New builds on Laravel start at €3,900 with us — but that's exactly what a takeover usually doesn't require. You'll find all packages and options transparently on our pricing page.

The most important part: an audit isn't a pre-sales meeting. If your existing system is solidly built, we say so — even when a rewrite would be more lucrative for us.

Common questions about switching agencies

Can you switch mid-project?

Yes. It's less pleasant than switching at a feature boundary, but it works. What matters is that the current state is committed to the repository and deployable. We leave half-finished features alone at first, get the system into a stable state, and then decide deliberately: finish or discard. What we don't do is blindly finish a half-built branch without understanding what it's supposed to do.

Does the application have to go offline for this?

No. A takeover happens entirely alongside live operation at first: read, set up, check. The only moment of contact is a possible infrastructure move, and that can be placed in a maintenance window of minutes.

What if the old provider won't cooperate?

It happens, and it's solvable. Repository and server access are the only genuinely hard points — everything else can be reconstructed. If the code only exists on the production server, we fetch it from there. Domain and DNS can be clawed back through the registrar, as long as you're listed as the owner. So: check today who's listed as the owner of your domain.

Do you need the original developer?

Nice to have, not required. Laravel is a convention-heavy framework — anyone who knows it finds their way around someone else's code too, because directory structure, routing, models and migrations work the same everywhere. That's exactly what makes Laravel so pleasant for existing projects: you're not dependent on a single human being. Why we bet on it in general is in why we build with Laravel.

Wouldn't a rebuild be better instead?

Rarely. A rewrite costs a multiple, takes months and produces exactly zero new value at first — while the old system has to keep running. We only recommend it when the business logic itself is obsolete, or the technical base is so far gone that every change costs more than starting over. In nine out of ten cases the right answer is: take over, stabilize, keep building.

Bottom line: a switch isn't a restart

Switching Laravel agencies isn't drama, it's craft. Three things decide it: the credentials fully in your hands, an honest audit before the first quote, and a new team that stabilizes first and builds later instead of immediately selling a rewrite. When that's in place, you'll barely notice the switch during live operation — except that someone answers again.

As a Laravel agency we regularly take over existing projects, including ones well past their prime. And if it turns out your system is really more than a Laravel app — say, a grown piece of custom software with interfaces in every direction — we'll look at that just as closely.

Do you have a Laravel application nobody's properly looking after right now? Send us a short overview of what it's about and we'll take a look together in a free first call. You'll get an honest assessment of your project's condition — including when that assessment says you don't need to switch at all. Just get in touch, no obligation and no sales pressure.