DEV Community

Sohana Akbar
Sohana Akbar

Posted on

From 5 PHP Nightmares to 1 Node Pipeline: Why Boring Standardization Is My Greatest Achievement

#ai

TL;DR: I migrated 5 legacy PHP frontends to our standard Node pipeline. Onboarding dropped from 1 week to 1 day. Here's why "boring" is actually the most exciting thing you can do for your team.

The Confession
I used to hate standardization.

I was that developer who thought every project needed its own unique flavor. Different build tools? Sure. Different folder structures? Why not? Different deployment scripts? Keeps things interesting, right?

Wrong.

Last quarter, I inherited 5 legacy PHP frontends. They were all built by different teams, in different years, with different levels of caffeine-induced insanity. They served the same business purpose, but they might as well have been written in 5 different languages.

Here's what I found:

App PHP Version Build Tool Deployment Method Developer Tears
App A 5.6 None (FTP) Manual drag-drop High
App B 7.0 Gulp SSH + custom bash Very High
App C 7.4 Composer Jenkins (broken) Extreme
App D 8.0 Webpack (kind of) Kubernetes (sort of) Moderate
App E 5.6 (again) Literal nightmares Prayers Infinite
Onboarding a new developer meant spending a week just explaining the quirks of each app. A week. Before they wrote a single line of production code.

The Decision
I pitched a radical idea: Kill them all.

Well, not kill—migrate. Consolidate all 5 frontends into our standard Node.js pipeline. One build process. One deployment strategy. One way to do things.

The pushback was immediate:

"But PHP is fine!"

"Why fix what isn't broken?"

"This will take months!"

"We'll lose our 'character'!"

I had one response: "Your character is costing us money."

The Migration
Here's what the migration actually looked like:

Step 1: The Audit
I mapped every feature, every route, every API call across all 5 apps. Surprisingly, they all did the same 3 things:

Fetch data from an API

Render a UI

Handle form submissions

The differences were purely in how they did it.

Step 2: The Standard
I defined our "standard" Node pipeline:

Framework: Express + React (already in use elsewhere)

Build: Vite (fast, modern)

Linting: ESLint + Prettier (non-negotiable)

Testing: Jest + React Testing Library

Deployment: GitHub Actions → AWS ECS

Step 3: The Rewrite
I didn't rewrite everything from scratch. I extracted:

Shared UI components into a monorepo package

API client logic into a single service

Environment configuration into a unified .env system

Each app got re-implemented as a "theme" or "route" within the same codebase.

Step 4: The Cutover
We deployed one app at a time. If it broke, we rolled back. (It broke twice. We rolled back twice. No big deal.)

The Results
Onboarding: 1 Week → 1 Day
This is the metric I'm most proud of.

Before:

Day 1: Install PHP 5.6 (good luck on M1 Macs)

Day 2: Configure 5 different .ini files

Day 3: Learn App A's custom routing

Day 4: Learn App B's custom templating

Day 5: Actually write code (maybe)

After:

Morning: git clone, npm install, cp .env.example .env

Afternoon: "Here's the codebase. You know React. You know Node. Go."

New devs are pushing features on Day 1. Not just "Hello World"—actual features.

Developer Satisfaction: 📈
I surveyed the team before and after:

Metric Before After
"I understand the codebase" 2/10 8/10
"I can debug issues quickly" 3/10 7/10
"I enjoy working here" 4/10 9/10
Deployments: Stressful → Boring
Before: Deployments required 3 different people, 2 Slack channels, and a prayer circle.

After: git push main → automated build → automated test → automated deploy. 15 minutes. No human intervention.

The Hard Truth
Standardization is boring.

There's no glory in writing another YAML file. No one gives you a trophy for enforcing the same ESLint rules across 5 apps. No one tweets about "the elegant CI pipeline."

But here's the thing:

Boring is fast.
Boring is predictable.
Boring is scalable.
Boring makes money.

When we hired our last junior developer, they were productive on Day 1. That's not a flex—that's the system working. The system doesn't care about being exciting. The system cares about getting work done.

What I Learned

  1. Standardization Is a Force Multiplier
    One week to onboard vs. one day means 4 extra days of productivity per new hire. If we hire 10 people this year, that's 40 days of salary saved. That's not "boring"—that's a business case.

  2. Legacy Code Isn't "Character"—It's Debt
    I used to romanticize legacy code. "It has history!" "It's battle-tested!" No. It has bugs. It has config drift. It has hidden dependencies that no one remembers.

Kill it. Consolidate it. Move on.

  1. Developers Want Clarity, Not Chaos Every developer I've ever worked with wants to write code that matters. They don't want to spend 3 hours figuring out why App C won't connect to the database.

By standardizing, I gave my team back hours of their lives. That's not boring—that's humane.

The Meme Version (For X/Threads)
5 legacy PHP apps ➡️ 1 Node pipeline.

Onboarding:
Before: 1 week of "Why does this server require PHP 5.6?"
After: 1 day of "Here is your .env file."

Standardization is boring.

But watching new devs ship features on Day 1? That's beautiful.

Final Thoughts
If you're sitting on a pile of legacy apps that all do the same thing but look completely different—stop romanticizing the chaos.

Consolidate.
Standardize.
Bore yourself to death.

Your future self (and your future new hires) will thank you.

What's your experience with standardizing legacy code? Drop a comment below. Let's be boring together. 👇

Top comments (1)

Collapse
 
topstar_ai profile image
Luis Cruz

I really appreciated the section on "The Audit" where you mapped every feature, every route, and every API call across all 5 apps, only to find that they all did the same 3 things: fetch data, render a UI, and handle form submissions. This exercise in standardization is often overlooked, but it's crucial in identifying the commonalities that can be extracted into a unified pipeline. By defining a standard Node pipeline with Express, React, Vite, and GitHub Actions, you've not only simplified onboarding but also reduced the cognitive load on your team. I'm curious, what were some of the key challenges you faced during the rewrite and cutover phases, and how did you handle any discrepancies between the legacy PHP code and the new Node pipeline?