iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
A safe migration starts by identifying what the existing site is built with. An application already using Laravel can usually be upgraded through the framework’s version-specific guides; a site built with another PHP framework, a CMS, or custom PHP must be replatformed, with its behavior and data mapped to a new Laravel application. Those are different projects, and neither has a universal migration recipe.
First decide what kind of migration you have
Before choosing commands or setting a target version, establish whether you are changing Laravel versions or moving to Laravel from another platform. Laravel’s current upgrade guide documents the path from Laravel 12 to 13; it does not prescribe a route for an unspecified older application or another framework. Start with the version you actually run, then follow the intervening official upgrade guides rather than applying a single-version recipe to the whole jump.
| Project path | What changes | What to plan for |
|---|---|---|
| Upgrade an existing Laravel application | Laravel and its dependencies move to supported versions, with application code reviewed for breaking or changed behavior. | Starting Laravel and PHP versions, dependency constraints, customizations, tests, and the official upgrade notes for each version transition. |
| Replatform from another framework, CMS, or custom PHP | The site’s functionality is implemented in a Laravel application; this is not a direct Laravel version upgrade. | Behavior and data mapping, URL continuity, integrations, authentication, hosting, and which existing features must be retained or redesigned. |
For an existing Laravel codebase, the Laravel 13 upgrade guide is specifically for moving from Laravel 12 to 13. If your project starts earlier, identify its release first and use the applicable intervening guides. For a replatforming project, the old application’s architecture and requirements determine the work; the Laravel upgrade guide cannot supply that project-specific design.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Build a baseline before changing the application
Inventory the production system while it still works. The goal is to capture what must continue working, not just what appears on the home page. Record the framework, PHP version, Composer dependencies, required PHP extensions, database and schema, routes, scheduled tasks, queues, external services, authentication and session behavior, hosting setup, and who owns each operational component.
#1 Best Overall
Turn that inventory into a short list of critical user journeys and system behaviors. Include representative reads and writes, sign-in and sign-out, important forms, payments or other external integrations, background work, and URLs that users or other systems rely on. Record expected outcomes and relevant existing redirects. This gives the team a reference for comparing the new application with the actual site rather than relying on memory.
- Back up the database and other state that the site needs before making production changes, and verify that the recovery process is usable for your environment.
- Identify data owners and relationships before designing a new schema or transformation. Preserve identifiers or mappings where other systems, URLs, or records depend on them.
- Note operational constraints such as maintenance windows, acceptable downtime, hosting permissions, and how workers or scheduled tasks are started.
- Find existing tests, logs, and monitoring that can help establish normal behavior and surface regressions.
Choose the target by checking runtime and package compatibility
Set the intended Laravel and PHP versions only after checking the starting environment, hosting constraints, and the framework’s current requirements. As of October 7, 2026, Laravel’s published deployment guide says the web server needs PHP 8.3 or newer; confirm the live deployment documentation and hosting-specific requirements when planning the actual release.
For a Laravel 12-to-13 upgrade, the Laravel guide lists these dependency constraints. They are guide values for that transition, not a complete package list for every application; check the complete guide and the project’s Composer files before changing constraints.
Recommended Free Tools
| Package | Laravel 12-to-13 guide constraint |
|---|---|
laravel/framework |
^13.0 |
laravel/boost |
^2.0 |
laravel/tinker |
^3.0 |
phpunit/phpunit |
^12.0 |
pestphp/pest |
^4.0 |
Applications often have additional packages and custom code, so satisfying framework constraints alone does not prove compatibility. Check each important dependency’s support for the intended PHP and Laravel versions, and investigate abandoned or unmaintained packages before they become a cutover blocker.
Rank #3
Move in stages that can be reviewed
Keep the work in version control and make changes in increments small enough to understand and test. For an existing Laravel application, upgrade one supported step at a time, following that transition’s guide and running the project’s checks before proceeding. For a replatform, deliver a small but representative slice—such as a key route, its data access, and its authentication or integration behavior—before building out the rest of the site.
- Establish a working baseline. Run the current application’s available tests and record critical journey results, route behavior, and data expectations.
- Create a recoverable development environment. Keep production data protected, use a suitable copy or fixture set, and confirm that backups can be restored before a production cutover.
- Make one reviewable change at a time. For a framework upgrade, follow the relevant release guide; for a replatform, implement mapped behavior and data conversion in explicit stages.
- Run checks after each stage. Test the affected areas and inspect dependency or generated-code changes instead of assuming that a successful package installation means the application is correct.
- Record migration decisions. Document schema mappings, route changes, compatibility workarounds, and operational changes so reviewers and release operators can verify the final result.
Automation can help with an existing Laravel upgrade, but it is not a substitute for review. Laravel’s upgrade guide points to Laravel Shift; Shift says its upgrades proceed incrementally and that customized code or third-party dependency changes may still require manual attention. See the Shift FAQ for its stated limitations. Evaluate assisted changes in the same way as hand-written changes: inspect the diff and verify behavior.
Review Laravel 13 behavior changes when that is your target
The Laravel 13 upgrade guide calls out changes that may matter to an application’s middleware, sessions, caching, or routes. Treat these as checks against your own code and configuration, not as a list of changes that every site necessarily needs to make.
PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware match- CSRF middleware: Laravel 13 renames the middleware to
PreventRequestForgeryand adds request-origin verification usingSec-Fetch-Site. Search for direct references to the prior middleware name and test forms, API clients, and cross-origin request behavior that the application supports. - Session serialization: The new application skeleton uses JSON serialization by default. Changing to that configuration can invalidate active sessions; if session continuity is required, assess whether retaining PHP serialization is appropriate and test the consequences before deployment.
- Cache and session prefixes: Some default key prefixes change. Check for code, operational procedures, or shared stores that depend on existing keys.
- Domain route matching: Route matching precedence changes for domain routes. Test host-based routing and any overlapping route definitions against the intended domains.
The official Laravel 13 upgrade guide documents additional changes and dependency details. Laravel says, “We attempt to document every possible breaking change,” while also warning that some less common changes can affect particular applications. Read the full guide for the target transition instead of treating this watchlist as exhaustive.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Validate the site against its baseline before cutover
Compare the new or upgraded application with the critical journeys and expected behavior recorded before work began. Prefer automated tests for repeatable checks, but manually exercise behaviors that are difficult to cover or especially costly to break.
- Routes and URLs: Check high-value pages, route parameters, domain routing, canonical URLs where relevant, and redirects from old paths. Confirm that external consumers and bookmarks still reach the intended destination.
- Data: Verify representative reads and writes, relationships, totals, and any converted records. Reconcile counts or other invariants appropriate to the application rather than relying only on a successful migration command.
- Identity and sessions: Test authentication, permissions, sign-out, session persistence, and any account flows the site depends on.
- Integrations: Exercise the real application paths for external services, including failure handling and configuration, using safe test modes where the service supports them.
- Background work: Confirm that scheduled tasks and queued jobs are registered, processed, and observable under the new deployment setup.
- Front end: Check representative pages and forms in the browsers and devices your audience uses, including validation and error states.
Plan cutover and rollback for the actual database, infrastructure, and data-conversion strategy. A code rollback may not reverse a schema change or undo writes made after launch, so define how those cases are handled before release. The right sequence may require a maintenance window, staged traffic, or another approach; the available evidence does not establish one zero-downtime or rollback method for every legacy site.
Deploy with production configuration and operational checks
Laravel’s deployment guide provides the production details to verify against the actual host. Serve the application from its configured web-directory root; the guide warns against serving it from a subdirectory of that directory because sensitive files could be exposed. Ensure the server process can write to bootstrap/cache and storage.
The guide recommends running php artisan optimize during deployment and documents configuration caching. Once config:cache has run, Laravel does not load .env; calls to env() outside configuration files return null. Set production APP_DEBUG=false so detailed debug output is not exposed to site visitors.
The default Laravel health route is /up: it returns HTTP 200 if the application boots without exceptions and HTTP 500 otherwise. Use it as one operational signal, not as proof that every route, integration, or background task works. After deploying new code, reload or restart long-running services such as queue workers, Reverb, or Octane when those services are part of the application. Follow the Laravel deployment guide and the host’s process-management instructions for the environment you run.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
