August 12, 2026
9 min read
Table of Contents
By Kokil Thapa | Last reviewed: August 2026
Skipping Laravel 11 to jump straight to Laravel 12 is a high-risk move that requires careful planning, especially for production applications handling payments or legal workflows. This Laravel 12 real world migration guide from Laravel 10 addresses the compounding breaking changes across two major framework versions, including the mandatory shift to PHP 8.2+ and the complete removal of Webpack-based Mix. Before touching your codebase, review this overview of Laravel 12 new features to understand what has changed since your last upgrade cycle.
Quick answer: The Laravel 12 real world migration guide from Laravel 10 requires upgrading to PHP 8.2+, replacing Laravel Mix with Vite, refactoring middleware to the new pipeline architecture, updating Spatie/Passport packages, and validating all queue workers against the new serialization standards before deploying.
What are the critical breaking changes in the Laravel 12 real world migration guide from Laravel 10?
The gap between Laravel 10 and 12 is not merely additive; it represents a fundamental shift in how the framework handles asset compilation, dependency injection, and HTTP kernel management. In my experience maintaining legal-tech portals and eCommerce platforms like Nepal Gift Card, the most painful failures occur when developers treat this as a standard minor version bump. You are effectively migrating across two architectural generations simultaneously.
The removal of the traditional app/Http/Kernel.php file is often the first shock. Laravel 12 configures middleware through a streamlined bootstrap process, meaning any custom global middleware you added directly to the Kernel class must be refactored into the new configuration-based approach. For projects using older authentication packages like Passport, verify compatibility immediately; many legacy OAuth implementations rely on internal classes that have been restructured or removed in favor of Sanctum or updated Passport releases.
Another frequent failure point involves Carbon. Laravel 12 expects Carbon v3, which introduces stricter type handling and removes several deprecated methods that were common in Laravel 10 codebases. If your application performs complex date math for booking systems or legal deadlines—as I've implemented on platforms like Court Marriage In Nepal—audit every Carbon::parse() and mutation method. Silent failures here can lead to incorrect appointment dates or expired token validations in production.
How do you upgrade PHP and Composer dependencies for Laravel 12?
You cannot upgrade Laravel without first securing your PHP runtime. Laravel 12 requires PHP 8.2 as an absolute minimum, but in 2026, targeting PHP 8.4 is the pragmatic choice for performance and long-term support. On Ubuntu servers running multiple PHP versions via Ondřej Surý’s PPA, ensure your CLI, FPM, and web server configurations all point to the same binary before running Composer updates.
- Update your
composer.jsonplatform requirement to"php": "^8.2"and set"laravel/framework": "^12.0". - Run
composer update --with-all-dependenciesto resolve transitive dependency conflicts. Watch specifically for Spatie packages, as older versions of Media Library or Permission may block the upgrade. - Audit deprecation notices in your test suite. PHP 8.4 emits warnings for implicitly nullable types and deprecated dynamic properties that were silent in 8.1.
- Verify OPcache configuration. The new JIT improvements in PHP 8.4 require different tuning than 8.1; ensure
opcache.jit_buffer_sizeis allocated if you intend to use it.
For teams managing shared hosting or constrained VPS environments in Nepal, test the memory footprint of PHP 8.4 carefully. While generally more efficient, certain extensions or unoptimized code paths can spike memory during compilation. Always validate against a staging clone of your production database before attempting the live switch. If you are integrating payment gateways like eSewa or Khalti, confirm their SDKs support PHP 8.4; some older vendor libraries still pin to 8.1 and will fail silently during transaction signing.
How do you migrate from Laravel Mix to Vite during the upgrade?
This is typically the most time-consuming step in the Laravel 12 real world migration guide from Laravel 10. Laravel Mix is completely unsupported in Laravel 12, and there is no backward-compatibility shim. You must adopt Vite. For simple Blade applications, this is straightforward; for complex Vue.js or Magento-integrated frontends, expect significant refactoring of build scripts and asset references.
<!-- Laravel 10 (Mix) --> <link rel="stylesheet" href="{{ mix('css/app.css') }}"> <script src="{{ mix('js/app.js') }}" defer></script> <!-- Laravel 12 (Vite) --> @vite(['resources/css/app.css', 'resources/js/app.js'])Beyond the Blade directive change, your development workflow shifts fundamentally. Mix relied on synchronous Webpack builds; Vite uses native ES modules and hot module replacement (HMR) that behaves differently with server-side rendering or multi-page applications. If your project uses jQuery plugins loaded via CDN alongside bundled assets, Vite’s strict module scope may break global variable assumptions. Explicitly expose globals in vite.config.js or refactor to proper imports.
In production, Vite outputs hashed filenames to public/build/, not public/css/ or public/js/. Your deployment script must run npm run build after installing Node dependencies but before symlinking the release. On Deployer 7 pipelines—which I use for sites like Notary Nepal and Translation Nepal—this means adding a dedicated task for asset compilation. Never commit built assets to Git unless your production server lacks Node.js entirely; even then, prefer building in CI and transferring artifacts to keep the repository clean.
How do you refactor middleware and service providers for Laravel 12?
Laravel 12 eliminates the monolithic Http/Kernel.php in favor of a declarative middleware configuration. Global middleware, route groups, and priority ordering are now defined in bootstrap/app.php or dedicated configuration files. This improves testability but breaks any code that programmatically modified the Kernel at runtime.
// bootstrap/app.php (Laravel 12) return Application::configure(basePath: dirname(__DIR__)) ->withMiddleware(function (Middleware $middleware) { $middleware->append(\App\Http\Middleware\ForceJsonResponse::class); $middleware->alias([ 'verified' => \Illuminate\Auth\Middleware\EnsureEmailIsVerified::class, ]); $middleware->priority([ \Illuminate\Session\Middleware\StartSession::class, \App\Http\Middleware\SetLocale::class, ]); }) ->create();Service providers also undergo scrutiny. The register() and boot() separation remains, but Laravel 12 is stricter about accessing services during registration. If your provider binds interfaces conditionally based on environment variables, ensure those checks happen in boot() or use deferred providers. For legal-tech applications relying on document generation services bound in providers, test thoroughly; lazy-loading changes can cause circular dependency errors that only surface under specific request patterns.
Review third-party packages that publish service providers. Older versions of Spatie Permission or Media Library may register middleware in ways incompatible with the new pipeline. Upgrade these packages to their latest 2026-compatible releases before attempting the framework upgrade. If a package hasn’t been updated, fork it temporarily or implement the functionality natively—relying on abandoned packages in a production legal or financial system is unacceptable risk.
What testing and deployment strategy prevents downtime during migration?
Never migrate a production Laravel 10 application to 12 without a parallel staging environment that mirrors your live infrastructure exactly. Database schema changes, queue worker compatibility, and cache serialization formats often differ between versions. Run your full test suite against PHP 8.4 and Laravel 12 locally first, then deploy to staging with a copy of production data (anonymized if necessary).
| Validation Area | Laravel 10 Behavior | Laravel 12 Requirement | Testing Method |
|---|---|---|---|
| Queue Jobs | Serialized with PHP 8.1 format | May fail deserialization on 8.4 | Drain queue before deploy; restart workers |
| Cache Store | Redis keys with old prefix format | Potential key collision or miss | Flush cache post-deploy; warm critical keys |
| Scheduled Tasks | Cron calls artisan schedule:run | Same command, new internal dispatch | Verify cron output; check overlapping locks |
| API Authentication | Passport tokens with legacy claims | Token validation may reject old format | Test refresh tokens; reissue if needed |
| Email Sending | SwiftMailer transport | Symfony Mailer interface | Send test emails to all configured channels |
Queue workers deserve special attention. Serialized job payloads created under Laravel 10 with PHP 8.1 may not deserialize correctly under Laravel 12 with PHP 8.4 due to internal class property changes. Before deploying, drain your queues completely. After deployment, restart all workers with php artisan queue:restart and monitor failed jobs closely for the first 24 hours. For eCommerce sites processing orders or legal portals generating documents, a silent queue failure can mean lost payments or missed court deadlines—unacceptable outcomes that justify extended maintenance windows.
If you manage multiple sister sites on shared infrastructure—as I do for notarykathmandu.com, khimananda.com, and translationnepal.com—upgrade one site first as a canary. Validate the deployment pipeline, asset compilation, and runtime behavior before touching others. This incremental approach catches environment-specific issues (like missing PHP extensions or misconfigured OPcache) without risking your entire portfolio. Document every deviation from the standard upgrade path; future-you will thank present-you when the next major version arrives.
Laravel 12 Real World Migration Guide from Laravel 10: Final Steps
Migrating from Laravel 10 to 12 is a significant engineering effort that demands respect for the underlying platform changes. Prioritize PHP 8.4 adoption, complete the Vite transition methodically, refactor middleware declarations early, and validate every integration point against production-like conditions. Budget realistic timelines—for a medium-complexity application, expect 2–4 weeks of focused work including testing and staging validation. If your team lacks experience with these specific breaking changes, consider bringing in specialized help rather than risking production stability. For teams evaluating whether to upgrade or rebuild, review this comparison of modern Laravel architecture best practices to inform your decision. When you're ready to plan your migration or need hands-on support for complex upgrades, reach out to discuss your Laravel 12 real world migration guide from Laravel 10 project requirements.
Frequently Asked Questions
Laravel 12 requires PHP 8.2 or higher and Composer 2.x. While PHP 8.4 is the latest stable release in 2026, PHP 8.3 remains widely used and fully supported. Ensure your MySQL version is at least 8.0 LTS or MariaDB 10.11, as older database versions lack necessary JSON and performance features required by newer Eloquent optimizations.
For a medium-complexity business application, expect two to four weeks including testing and deployment verification. Simple API backends may finish in one week, while complex monoliths with heavy custom packages can extend to six weeks. In my experience working on production Laravel applications, package compatibility resolution and deprecated feature refactoring consume more time than core framework updates.
Yes, direct upgrades are supported but require careful attention to cumulative breaking changes. You must address deprecations from both Laravel 11 and 12 simultaneously. I recommend reviewing both upgrade guides sequentially before starting code changes. Skipping versions works technically, but increases regression risk during testing phases since intermediate behavioral shifts compound without incremental validation checkpoints between major releases.
Packages relying on removed service container bindings, changed middleware signatures, or deprecated helper functions typically fail first. Authentication packages, PDF generators, and legacy admin panels need scrutiny. Always check Packagist for Laravel 12 compatibility tags before upgrading. On real client projects, I have found that unmaintained packages often require replacement rather than patching, especially those abandoned before Laravel 11 released. Budget extra time for finding modern alternatives.
Enable deprecation logging in Laravel 10 before upgrading to capture warnings in production logs. Address each deprecation systematically using the official upgrade guide as reference. Never suppress deprecation notices permanently. In practice, most deprecations map to straightforward replacements like switching from string-based route definitions to attribute routing or updating facade calls. Treat deprecation cleanup as mandatory pre-upgrade work, not optional technical debt.
Maintain comprehensive feature tests covering critical business workflows before starting migration. Run tests against Laravel 10 baseline first to establish green status. After each upgrade step, run full test suites immediately. On production Laravel applications I maintain, integration tests for payment flows, authentication, and API endpoints catch issues unit tests miss. Add regression tests for every bug discovered during migration to prevent future reintroduction of fixed problems.
Performance gains vary significantly by application architecture. Applications bottlenecked by framework overhead benefit noticeably from improved routing caching and optimized container resolution. Database-heavy apps see smaller improvements unless leveraging new query builder features. Migration costs range from NPR 50,000 to 300,000 (USD 375–2,250) depending on complexity. Justify upgrades through security support timelines and developer productivity gains rather than expecting dramatic speed improvements alone.
Laravel 12 introduces stricter environment variable validation and changed default configurations. Audit your .env files against fresh Laravel 12 installations to identify missing or renamed variables. Test configuration caching thoroughly since invalid configs now throw exceptions instead of failing silently. During Deployer 7 deployments I manage, configuration mismatches cause immediate post-deploy failures. Validate all environment-specific settings in staging before production rollout to avoid downtime from config parsing errors.
Schema builder changes and modified migration ordering can expose latent issues in existing migrations. Newer Eloquent versions enforce stricter type casting and relationship constraints. Review all pending migrations and verify they execute cleanly on fresh databases. On eCommerce systems I have built, timestamp precision changes and JSON column handling required migration adjustments. Always backup production databases before running migrations and test rollback procedures to ensure recovery paths work under Laravel 12.
Laravel 12 continues Sanctum and Passport support but removes legacy authentication scaffolding. Custom guard implementations and user provider modifications need review against current interfaces. Session handling defaults changed, affecting remember-me tokens and session lifetime configurations. For legal-tech portals requiring secure document access, I verify authentication flows end-to-end after every framework upgrade. Test login, registration, password resets, and API token generation comprehensively since authentication regressions create immediate security vulnerabilities and user access disruptions.
Update CI/CD scripts to use PHP 8.2+ containers and Composer 2.x. Asset compilation commands changed, requiring frontend build script updates. Zero-downtime deployments using Deployer 7 need revised shared directory configurations for new storage structures. OpCache invalidation strategies remain critical since stale bytecode causes cryptic runtime errors. On sister sites sharing GitLab CI pipelines, I standardize PHP version bumps across all repositories simultaneously to prevent environment drift and simplify maintenance burden during coordinated framework upgrades.
Factor developer hours for code updates, testing, deployment, and post-launch monitoring. Senior Laravel developers in Nepal charge NPR 1,500–3,000 per hour (USD 11–22). Medium applications typically require 40–80 hours. Include contingency budget for unexpected package incompatibilities. Compare against extended Laravel 10 security patch costs if delaying migration. For budget-sensitive clients, phased approaches addressing critical security updates first while deferring optional refactoring spread expenses across multiple billing cycles without compromising production stability.
Delay if critical dependencies lack Laravel 12 support with no viable alternatives exist. Postpone when major business initiatives coincide with migration windows to avoid resource conflicts. Stable applications with minimal security exposure can safely remain on Laravel 10 through paid extended support. In my experience, forcing premature upgrades during peak business seasons creates unnecessary operational risk. Schedule migrations during low-traffic periods and ensure rollback capabilities exist before committing to production cutover dates.
Laravel 12 includes updated CSRF protection, improved password hashing defaults, and patched vulnerabilities discovered since Laravel 10 release. Modern PHP 8.2+ runtime provides better type safety reducing injection attack surfaces. Security headers configuration simplified through framework defaults. However, security depends more on application implementation than framework version alone. Regular dependency audits via composer audit matter equally. Upgrading reduces known vulnerability exposure but does not replace secure coding practices and ongoing security maintenance responsibilities.
Monitor error logs, response times, and business metrics closely for two weeks post-deployment. Verify scheduled tasks execute correctly since cron path references frequently break during upgrades. Test all third-party integrations including payment gateways and SMS services. Confirm background queues process without failures. On production deployments I manage, I implement health check endpoints and alert thresholds specifically tuned for post-migration anomaly detection. User-reported issues often surface edge cases automated tests miss, so maintain responsive support channels during transition period.
