@fazbeni24 The way I’ve migrated legacy projects to Laravel in the past, where the legacy site has just been PHP scripts, is almost the opposite of what you’ve done. I rename public/index.php to public/laravel-index.php, and then drop the legacy project’s files in the public directory. You can then update your web server’s configuration to either serve the file as is if it exists, or past the request to the Laravel front controller if it isn’t handled by a standalone file.
This way, you can slowly convert the legacy scripts to Laravel controllers and views. You pick a page, create the controller and view, and then delete the legacy script. Following this process, the contents of your public directory will gradually reduce in the number of the legacy project’s scripts, and the number of Laravel controllers and views will increase. Once you have re-factored everything, you can rename your public/laravel-index.php file back to public/index.php and you have yourself a modern Laravel project.
In terms of authentication, you could create a custom auth guard and provider that does the same as the current implementation.
Following the above means you don’t need to “detect” if the user is on a legacy or “new” page; they’ll get the legacy page if it exists or the Laravel-served page if that exists. You don’t need to do any detection or redirecting anywhere. You can, of course, set up redirects in your *.htaccess file or nginx configuration file to redirect legacy URLs (such as /view-sanction.php) to the equivalent Laravel-hosted URI once it’s available (i.e. /sanctions/{sanction}).