If PHP Support Ended Tomorrow, What Would You Do Next?

PHP is not going anywhere. PHP 8.5 is active, Laravel 13 shipped last week, and the ecosystem is arguably in better shape than it has been at any point in the past decade. So let us be clear about what this question actually is: a thought experiment.

But it is a useful one. If the language you have built your practice on were to reach end of life overnight - no more security patches, no more framework support, no viable upgrade path - what would you actually do? How would you rebuild? What would you reach for first?

This is our honest answer.

What We Would Lose

Before looking at where we would go, it is worth being clear-eyed about what we would be leaving behind. Because the answer shapes how hard the migration actually is.

The honest truth is that we would not primarily miss PHP. We would miss Laravel.

Laravel has spent fifteen years building one of the most complete and opinionated web framework ecosystems in existence. Eloquent ORM, queue jobs, Artisan CLI, Livewire, Filament, Sanctum, the Spatie package ecosystem, first-party tools for broadcasting, caching, storage, search, and now AI. It is not just a framework - it is a complete way of building web applications and APIs that requires relatively few architectural decisions from the team using it.

When you move away from PHP, you do not just move away from a language. You move away from every package, every convention, every shortcut, and every piece of institutional knowledge your team has accumulated using it. That is the real migration cost.

Where We Would Go

The Realistic First Choice: Node.js with TypeScript

If we had to ship production applications immediately, we would most likely move to Node.js with TypeScript. Not because it is the best language for everything we do, but because the overlap with our existing work is greatest.

We build on Next.js and React. Our frontend developers already write TypeScript daily. Moving the API layer to Node.js would mean a shared language across the full stack, unified tooling, and the ability to share validation schemas, types, and utility functions between frontend and backend without translation layers.

The ecosystem has matured significantly. NestJS provides the kind of opinionated structure that Laravel developers expect - decorators, dependency injection, modules, guards, interceptors. Prisma is a capable ORM that handles migrations and type-safe queries. Zod or Valibot handle validation. The pieces are all there; they just require more assembly than Laravel.

What we would miss most in this move: the queue system. Laravel's queue infrastructure - Redis, database, SQS, horizon, horizon metrics - is one of the most complete and production-ready in any framework. BullMQ is the Node.js equivalent, and it is good, but the Laravel queue experience has years of polish that takes time to replicate.

The Strong Second Choice: Python with FastAPI

For API-first projects specifically - particularly anything with AI integration, data processing, or machine learning components - Python with FastAPI would be a serious contender.

FastAPI's developer experience is genuinely excellent. OpenAPI documentation is generated automatically from Python type hints with almost no additional effort. Async support is first-class. The performance is strong for an interpreted language. And the Python ecosystem for AI and data work is simply unmatched - if you are building APIs that sit in front of language models, vector databases, or data pipelines, Python is where you want to be.

Laravel 13 introduced a first-party AI SDK that puts Laravel in this space for the first time. But Python has a decade of head start in the ML ecosystem, and no framework in any other language comes close to matching it for that specific category of work.

The honest downside: Python web development requires significantly more architectural discipline than Laravel. Django is opinionated but shows its age. FastAPI gives you excellent primitives but relatively little structure. The temptation to write unmaintainable code is higher when the framework is not steering you away from it.

What About Go?

Go would be on the list if performance and operational simplicity were the primary drivers. A single compiled binary, no runtime dependency, low memory footprint, excellent concurrency primitives. For high-throughput API work, Go's performance profile is difficult to match in a dynamically typed language.

But Go's verbosity is real. Error handling alone requires a different mental model. For a team that has spent years in Laravel's expressive, convention-heavy world, the adjustment to Go's explicit, low-level approach is significant. We would consider it for specific high-performance services, not as a wholesale replacement for everything we build.

The Migration Reality

Here is the thing the thought experiment usually skips over: the existing codebase does not disappear when a language ends support.

In practice, a PHP end-of-life scenario would mean years of parallel operation. Existing applications would continue running - they would just become progressively more expensive to maintain and more risky to leave unpatched. The migration would be project by project, driven by risk appetite and business priority rather than a clean cutover.

New projects would start on whatever we had chosen as the replacement stack. Legacy projects would be assessed: can they be rewritten economically, or do they run in an isolated, firewalled environment until they reach natural end of life? Some applications that cost £50,000 to build are not worth £80,000 to rewrite - they just need to be managed carefully until they can be retired.

This is true of any platform migration, not just a hypothetical PHP sunset. The real cost of technology dependency is not the migration itself - it is the years of managed decline for systems that cannot justify rewriting.

The Lesson Without the Hypothetical

PHP is not ending tomorrow. But the question forces a useful audit: how dependent are we on a single platform, and how quickly could we adapt if the landscape changed?

The teams most resilient to platform shifts are not the ones who avoided specialisation - it is the ones who kept their architectural principles consistent regardless of the stack. API design is API design. Queue-based async processing is queue-based async processing. Good validation and error handling are good validation and error handling. The patterns transfer even when the syntax does not.

The language is a tool. The thinking is the skill.

If PHP ended tomorrow, what would you reach for - and how long do you think it would actually take your team to be productive in it?