Migrating an old project to latest

@yeasir_arafat I'm not sure I'm following. Why would you maintain 2 code bases?

You have revision control, right?

Make a new branch, update your composer.json to pull in the newer version of the laravel framework, and follow the upgrade guide.

I highly suggest to upgrade your code base one version at a time. Hopefully you used a TDD approach, where you can then test your application at each version.

You may also want to look into Laravel Shift: https://laravelshift.com/

Once you have your development code base upgraded, then you can push it to production, and then start your new features.

@yeasir_arafat Like @talinon, I don’t understand why you have two codebases if it’s the same project.

Just go through the upgrade guides between 5.2 and 7.x.

@martinbean @talinon : I am going to maintain two codebases becasue the current codebase is a live project, developed overa couple of years. And there are new features needing to be introduced constantly. So it is not possible to stop new development. At the same time i do not want to keep developing on old version of laravel. So my plan is to introduce new features that have almost no dependency on the old codebase models/logics etc. I can develop those features in a new version of laravel, but the users should not have to visit a new url or subdomain. Rather I want the request s to land on the current project and if the url relates to the new feature on the new codebase, it should be served from there.

I got suggestion of using PHP Guzzle http client package. That is one option. I was looking for more interesting ideas.

@yeasir_arafat Don’t create a second application. That’s a horrible approach. It’s going to double your maintenance burden, and give you less time to upgrade the “old” application.

If you create a new Laravel 7.x application now, what happens when Laravel 8.0 is released in the next few weeks? Congratulations: you now have two out-of-date Laravel applications that need upgrading.

Build the features in the existing codebase, and upgrade as and when you get time. Maybe do a minor version upgrade (i.e. 5.2. to 5.3 and so on) a week, and you’ll eventually catch up to the current Laravel version.

hi everyone, i'm newbie, how to post new thread?, i dont know how to answer of the question , please guide me

Like said, just go to the process of upgrading the current project. Yes it is a pain, but it is just the best approach.

Take a look at: https://tighten.co/blog/converting-a-legacy-app-to-laravel/ if you really want to run a second codebase.

My approach would be something like:

• Keep the production environment as it is.
• Recreate the production environment on a second server, so you have basicly an copy of the production server.
• Start upgrading version by version (5.2 > 5.3 > 5.4) and deploy to the copied environment, so you can test without bottering your production environment (basicly DTAP).

that is a valid point @martinbean . However, migrating to a newer version each week is not possible as the codebase is massive. Maybe one version every 2 months is feasible, maybe. That is one option. Thanks

@yeasir_arafat By upgrading, I mean following the upgrade guide on the Laravel website, i.e. https://laravel.com/docs/5.2/upgrade. That shouldn’t take a couple of months to do.

If it does, then that’s all the more reason not to create a second application, as if you don’t have the time to do it with one application, you’re definitely not going to have the time if you’re then splitting your time maintaining two applications.