Convert Node.js to PHP: When It Makes Sense (and When Not)

Here's a pattern I see a lot. A small business paid someone to build an app in Node.js or Next.js. It worked. Then that developer moved on, the hosting bill turned into a mystery, and the only people around who can maintain it know PHP.

So the question lands on my desk: should we convert Node.js to PHP? Sometimes the answer is yes, and it's one of the best things the business can do for that app. Sometimes it's a waste of money. I've done these conversions as a PHP and Next.js developer in Nashville, so here's the honest version of when a Node-to-PHP migration pays off, when it doesn't, and what breaks along the way.

Got an app like this and want a straight answer? Get a free quote, or read on first.

It's almost never about the language being better. It's about the people and the hosting around the app.

Who's going to maintain it. If the team, the agency, or the freelancer the business already trusts works in PHP, a Node app is a single point of failure. Every small change turns into a search for a JavaScript developer.

Where it runs. A lot of small businesses already pay for cPanel or shared hosting that runs PHP out of the box. A Next.js app with server rendering needs a Node process running somewhere else, which usually means a second bill and a second login.

Dependency churn. A Node app that hasn't been touched in two years usually has a pile of outdated packages and a major framework upgrade or two waiting. A plain PHP or Laravel app has dependencies too, but there are usually far fewer of them.

What the app actually is. Most of the apps I see are forms, a login, an admin screen that looks like the other five, a few reports, and an integration or two. That's PHP's home turf.

I lean toward converting when most of these are true:

• The app is mostly CRUD: forms, tables, user accounts, file uploads, reports.
• The people who'll maintain it work in PHP.
• The business already has PHP hosting, and the Node hosting is an extra cost.
• The app has real business logic, but no heavy real-time features.
• Traffic is steady and moderate, not millions of requests an hour.
• The codebase needs significant work anyway, like a framework upgrade, security fixes, or missing features.

That last one matters most. If you're going to spend real money on the app regardless, spending it on a version your team can actually own is a good trade.

I'll talk someone out of a conversion when:

• It's real-time at its core. Live chat, collaborative editing, lots of open WebSocket connections. Node handles that well. PHP can do it, but you'd be fighting the grain.
• The team is JavaScript people. If the people maintaining it are happy in TypeScript, converting just moves the single point of failure to a different place.
• It works and nobody's touching it. A stable app with a sane hosting bill doesn't need a rewrite because it's in the "wrong" language.
• The front end is the product. If it's a rich, interactive React app, rewriting all of it in PHP templates throws away the good part.

Often, yes, and it's the first thing I check. Next.js can build a static export with output: 'export', which turns each route into plain HTML, CSS and JavaScript files that any web server can serve, including cPanel.

The catch is the list of things a static export can't do. Per the Next.js docs, that includes cookies, rewrites, redirects, headers, Server Actions, incremental static regeneration, the default image optimization, and route handlers that read the request. So the question becomes: how much of the app depends on those?

If the answer is "just the API routes and the login," a hybrid can be the cheapest path. Keep the React front end, export it as static files, and rebuild the API, auth and database layer in PHP. Users don't see a difference, and the part that needs a server now runs on hosting the business already has.

The routes and screens are the easy part. These are the things that bite:

Authentication and sessions. Node apps often keep a JWT in local storage. PHP apps usually use server-side sessions with a cookie. Either works, but switching means logging everyone out once and rebuilding CSRF protection on every form. Make sure existing password hashes verify in PHP before cutover, or plan a reset.

JSON shapes. An empty PHP array encodes as [], not {}. If the front end expects an object, that one detail can break a screen in a way that's annoying to track down. I write tests against the old API's actual responses so the new one matches them exactly.

Background work. Anything that ran with setTimeout, a queue library, or a long-running process needs a new home: cron, a queue worker, or a scheduled command.

Dates and time zones. JavaScript Date and PHP DateTime disagree about defaults in ways that only show up around midnight and daylight saving time.

Uploads and limits. PHP has its own limits, like upload_max_filesize and post_max_size, and the defaults on shared hosting are often small.

URLs. If the old app had public pages, keep the URLs the same or set up 301 redirects. Otherwise you throw away whatever search traffic it had.

1. Inventory every route, job and integration. Including the cron job nobody mentions.
2. Capture the current behavior. Record real requests and responses, and turn them into tests the PHP version has to pass.
3. Move one piece at a time. Put a proxy in front, move one section to PHP, and send that path to the new code. The old app keeps running for everything else.
4. Let agents do the first pass. I have AI agents translate a module, then I read every diff, run the page and check it against the tests. (More on how I use them in Cursor, Grok, and the other agents.) Judgment stays with me.
5. Cut over, then keep the old app read-only for a week.
6. Hand over the docs. The whole point is that someone else can own it now.

And once it's on PHP, keep that PHP current. Old PHP versions get real security holes too.

It costs real money up front. A conversion is a project, not a weekend, and the savings come later.

You'll find bugs that were always there. Writing tests against the old app turns up behavior nobody meant to build. You'll have to decide whether to keep it.

Rewrites tempt scope creep. "While we're in there" is how a two-month project becomes six. Ship the conversion first, then add features.

None of that is a reason not to do it. It's a reason to scope it carefully and test it like you mean it.

Converting Node.js to PHP makes sense when it puts an app in the hands of people who can actually maintain it, on hosting the business already pays for. It doesn't make sense just because PHP is what I like to write. Sometimes the best call is a static export plus a small PHP API, and sometimes it's leaving a working app alone.

Can a Next.js app run on cPanel?

A static export can. Build with output: 'export' and upload the out folder like any static site. Server-side features like Server Actions, cookies and rewrites need a Node server or a different back end.

Is PHP cheaper to host than Node.js?

Often, for small businesses, because many already pay for hosting that runs PHP. A Node app with server rendering usually needs its own always-on process somewhere.

How long does it take to convert a Node.js app to PHP?

It depends on the number of routes, integrations and background jobs. A small CRUD app is usually weeks, not months. A big app with real-time features may not be worth converting at all.

Should I use Laravel or plain PHP for the conversion?

For most business apps, Laravel gives you auth, queues, migrations and scheduling out of the box. Plain PHP makes sense for small apps or when the hosting is very limited.

• Next.js Docs, "Static Exports"
• PHP Manual, "json_encode"
• PHP Manual, "Description of core php.ini directives" (file uploads)