Laravel Shift or an upgrade team: when each makes sense

We offer a paid Laravel upgrade service, so we aren’t neutral. We’ve tried to be fair anyway, because sending a small application to a paid project when a low-cost tool would do is bad advice. The facts about Shift below come from its own site, read on 30 October 2026.

You connect a repository and pick a version step. Shift opens a pull request with its changes split into small commits, and adds comments where something needs a closer look, often with a prompt you can hand to an AI tool. Nothing reaches your main branch until you merge. It’s a mature, widely known product: Laravel’s upgrade guides mention it by name.

Prices are from Shift’s list of Shifts. Its site also lists an AI review add-on, yearly Shifty Plans, and Human Shifts, where you buy hours of time from its creator. Its Can I Upgrade Laravel? tool is worth trying whichever route you choose.

• Your application follows Laravel conventions, without much custom framework code.
• Your tests cover the flows that matter, so a behaviour change would fail a build.
• Someone on your team can read the pull request and act on the comments.
• Your packages already have releases for the target version, or are easy to update.
• You’re going one or two versions, not several.

In this case, a project with an outside team would mostly be paying someone else to review the same changes. Use the tool, follow our upgrade checklist, and keep the difference.

• Thin tests. A pull request can be correct and still change what your application does. Our Laravel 11 to 12 guide shows how Carbon 3 can alter date calculations with no error. Without tests, somebody has to check those flows by hand against the old system.
• Blocking packages. When a package has no release for your target version, someone has to update it, fork it or replace it. See the package compatibility matrix for how often a major version change is required first.
• More than code. Automated code changes won’t move your server to a new PHP version, change a database engine, or plan a cutover with a way back.
• No one to review it. A pull request needs a reader. If the people who built the application have gone, you may be taking over a codebase you don’t know, and that comes first.
• Very old applications. When you’re several versions behind, the real decision may be whether to step through at all.
• You want one accountable price. Some businesses just want a named party to take this from assessment to live, and that’s a reasonable thing to pay for.

Our figures are from our pricing page, invoiced in USD, GBP, EUR or INR. The cost guide explains what moves them, and why a larger or older system can go beyond the top tier.

1. Try the Can I Upgrade Laravel? tool, or run composer why-not laravel/framework ^13.0.
2. Pay for one Shift on the next step. At these prices, it costs little to see what comes back.
3. Read the pull request. Count the comments you can’t act on yourself.
4. Run your tests, and write down which important flows they don’t cover.

If those lists are short, you’re done. If they’re long, you now know what to ask for, and you can send them to us or to anyone else for a quote. Teams who want extra hands rather than a project can also hire Laravel developers by the month.