Incrementally migrate existing project to Laravel

Hi everyone,

Laravel and Laracasts are amazing, a breath of fresh air. Thank you!

My team has an existing project that we want to incrementally migrate to Laravel. We need to keep the old codebase running while we add new features and port old features over to the Laravel application. Please allow me to ask for advice.

Routing:

Regarding routing, the current project is served through custom code running in select pages within a WordPress site at the parent domain example.com. I envision the new Laravel application would have its own authentication infrastructure through Breeze or Jetstream and be served through a subdomain like app.example.com.

Eventually, all functionality, including the interactive web site, the API, and scheduled jobs, would be migrated to the Laravel application in the subdomain. The WordPress site in the parent domain would become a simple welcome or brochure site for our visitors. Does this approach make sense?

Database:

Regarding the database, the existing project has around 50 tables contained within one database schema. The project has a rudimentary yet functional method for applying database migrations.

The Laravel application would require additional database tables, of course, while providing more expressive access to the existing data through Eloquent. What are the benefits and drawbacks of having the new Laravel application share the same database schema as the existing project?

Version control:

Regarding version control, the existing project is managed using Git. The project has a rudimentary method for deploying code from select subfolders of the Git working copy to specific locations on the live servers.

Would it make sense for the Laravel application to be contained in its own Git repository (like a fresh start), or kept in a subfolder of the repository for the existing project (so logic changes in old and new projects due to database schema changes are committed together)? Would there be any benefit for the Laravel application to have its own repository and one of the repositories becomes a submodule of the other so logic changes due to schema changes are kept coordinated?

Gratefully, Tim

vincent15000

4 years ago

Level 63

Hello, I'm not sure to be enough expert in Laravel to give you the best answer, but here my opinion.

I don't really understand why you need to have a subdomain ? Is it only for the transition ?

I think that the database can be the same, for example having the wordpress tables with a prefix. I don't see why it could be a problem.

For the versioning, I would start a new repository to begin with a fresh Laravel code that could progressively integrate different functionalities. And then if you need to do so, you could import this Laravel repository as a branch (is it really possible ?) in another repository.

I don't know if my answer will help you ... I only wanted to share with you my little opinion.

commodoretim

4 years ago

Level 3

Hey @vincent15000, thank you for taking the time to respond.

The idea of using the subdomain came to me when thinking about popular services such as https://www.smartsheet.com/ or https://myhours.com/. The parent domain is for the relatively static welcome pages for visitors and potential customers. The subdomain is for the live application for those who have subscribed.

The table prefix is a curious idea. I wonder if the Laravel models could access the existing tables, which don’t have a prefix, if the connection is configured to use one. Sounds like an experiment.

Git has an amazing tool that allows filtering the commits in a repository to make a given subdirectory the new root. Not yet sure if one repository can be grafted into another.

https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History

I’ll continue thinking on the migration puzzle while working on other aspects of the project that have clear answers e.g. setting up the model relationship for the existing tables and learning Breeze and Jetstream.

Please or to participate in this conversation.