Best way to upgrade a large Laravel 5.x E-store (20 dependencies) to Laravel 12?

Whatever you do, backup first.

I would keep running old project while using option 2 to build newer. Then just replace when tested and ready.

5 to 12 is a big jump.

That is the downside to not upgrading often and early. No matter which you choose, it will take time. However a rewrite might not be a bad idea anyways, since quite a bit has changed between 5 and 12.

Thanks, that makes sense A rewrite does sound like a cleaner option since so much has changed between 5 and 12.

If I decide to go the rewrite route, what’s the best approach? Should I:

Start a fresh Laravel 12 project and migrate features one by one?

Or is there a way to reuse parts of the old codebase (like models, business logic, or service classes) without dragging along old issues?

Would love to hear how others handled a rewrite in a large app — especially for something like an E-store with many dependencies.

I create new models, and then move the relations/scopes over one by one.

@muhammadlaraibsaeed You should stop talking about this and start upgrading your Laravel application version by version, like multiple people have told you to now.

yeah You're Right I should Have it

Well

if you’re concerned about the “development time”

Why even bother being a developer?

Further it doesn't take too long to either upgrade or do a new app if you know what you are doing.

A while back I went from a 9 to 12 in a couple of hours. Now really is that 2 hours enough to fret over?

Maybe stop using all those packages and it speeds upgrading up. Just use a minimum of necessary packages.

Edit:

I use a merge tool to speed things up. On Windows it's WInMerge, on Linux I have also used merge tools. If you learn a merge tool well upgrading goes so much faster. And yes there is a learning curve to get good at using the merge tools. But a worth while learning curve.

I've tried upgrading from version 9 to 11, and the upgrade process didn't take too long. The problem was ensuring there were no bugs or broken functionality.

Given your concern about the "time" for an upgrade or rewrite, you need to consider whether you want to address a lot of bugs when upgrade or create a new application that implements existing features in the old one.

I think stating "doesn't take too long" is a bit naive here personally. Sure, if you have a nicely structured, "simple" application, going from 9 to 12 is going to be realitively straight forward, however, coming from a 5.x branch of Laravel all the way through to 12.. there were some quite large changes earlier on in this process, and an ecommerce application is very often not a simple app either, especially if you're looking at the cart area that may need to handle multiple discounts/upgrades and the likes.. and also referring to Martin's comment too, time increases exponentially if/when 3rd-party packages are abandoned etc.

Of course, we're developers, everything takes time, so I totally agree with your query of "why even bother" if concerned with development time (this should either be the PO's issue or a need to quote a client accordingly, depending on the project situation).

There's also no mention of tests and there's a high possibility coming from a 5.x codebase that there may not be many (or many worth the paper they're written on), which again adds a massive headache and likely time, as ideally, tests would be written before the upgrade is done, even if basic assertions on critical paths so the current expectations (be them right or wrong, as far as decent tests are concerned) remain the same.

Without knowing more detail of what the OP is facing, I don't think being able to infer any kind of timeframe is possible.. least of all 2 hours.. which certainly isn't worth fretting over in the case of your 9-12 upgrade.. just as it wasn't a fret for my recent 10-12 upgrade that took around 20 mins (I was lucky and encountered very few BC issues in the app I upgraded).

I agree, but my point was whether it's 2 hours or 2 months, so what?

Just do it. It could be worked on a little each day til done.

My opinion was to start a new app and work stuff over to the new app. It was just my opinion. If the OP decides to go through the upgrades or use shift, well that's what they will do.

But if it's something they are going to do anyway, then the time it takes is irrelevant.

I have done both, upgrade and started new apps, and the time to complete is very close to the same in most cases.

Edit:

Another similar post:

https://laracasts.com/discuss/channels/laravel/how-to-upgrade-laravel-version-from-6-to-10

So it's preference whether to start a new app or upgrade.

But as I mentioned learning a merge tool well speeds upgrading a lot.

On those grounds, I would agree.. whatever the course, the sooner you start, the sooner you'll complete. I wonder however, how much experience the OP has with this too.. might be OK for us and many others here that maybe have a decade+ (or the likes) of real world experience of being in the weeds/working on large and/or legacy codebases... but if they don't have that experience/exposure, then it might be more daunting/overwhelming, hence the repetitive questions rather than knuckling down.

Either way.. you've gotta start somewhere! 🙂

EDIT: Yup.. for me, I'd normally prefer to refactor if possible as it is possible to add new bugs to a new app as easy as not fix old ones.. however, that's not always an easy case and starting over is definitely sometimes teh way forward.. and also gives you a chance to set some good foundations with the likes of TDD, PHPStan, Infection, etc.

Merge tools are most definitely helpful! Have used Araxis for years and it's definitely helped speed things up massively over that time.