Lumen maintenance status forces a choice: pin the last release line or migrate to Laravel

Our team maintains an API built on Lumen, the Laravel-derived micro-framework, and we are standardizing repeatable development environments across machines. With Lumen no longer actively developed and the Laravel team recommending Laravel (optionally with Octane) for new work, we need to decide how to keep this project reproducible without taking on unplanned risk.

The constraints we see: Lumen bootstraps through bootstrap/app.php and lacks Laravel's config scaffolding and config caching, so environment repeatability depends on composer.lock, a committed .env.example, and a pinned PHP runtime. Facades, Eloquent, and session handling are disabled or simplified by default and enabled manually in bootstrap/app.php, so behavior can diverge from Laravel even on matching illuminate/* component versions. Floating Composer constraints risk silently pulling mismatched components.

Migration is the alternative, but there is no official automated upgrade path; routes, middleware, and service providers would need manual porting, and we must confirm the exact end-of-life status of our Lumen line against the official repository.

Given a locked, working Lumen application:

• Is freezing on the last supported Lumen release with pinned illuminate/* versions a defensible medium-term strategy, or does component drift make it fragile?
• Which Lumen-specific behaviors (facade defaults, missing config caching) most often break assumptions during a Laravel migration?
• Is there a documented, incremental migration order that keeps the app deployable throughout?