- Sector
- Enterprise · Mobile
- Year
- 2019
- Role
- Backend engineer
- Outcome
- PHP 5.6 → 7.4 · API 2.0 with backward compatibility · Firebase push
What needed fixing.
You can't force a field technician to update an app on their schedule, so the backend had to serve both the new app and every old one at once. On top of that it was running on PHP 5.6 — past end of life, a security and performance liability — and needed push notifications it didn't have.
How I built it.
I migrated the backend from PHP 5.6 to 7.4, then designed API 2.0 for the updated app with full backward compatibility, so older installs kept working while new ones got the new surface. I integrated Firebase and built push notifications on top of it. Unglamorous, high-stakes plumbing — the kind where success means nobody in the field notices anything changed.
The Drupal backend behind iOS and Android apps for field specialists — modernised under the apps' feet without breaking the old versions still in the field.
- 01Modernise an ageing Drupal 7 mobile backend without disrupting live apps
- 02Migrate from end-of-life PHP 5.6 to 7.4
- 03Design API 2.0 with backward compatibility for older app versions
- 04Add push notifications via Firebase
- PHP 5.6 → 7.4 migration on a live production backend
- API 2.0 designed with backward compatibility for fielded app versions
- Firebase integration and app push notifications
- Drupal 7 backend serving both iOS and Android clients
The backend behind the app in the field
Some software lives on a desk; this lived in a glovebox. A global agriscience platform with iOS and Android apps for specialists working out where the signal is patchy and the phone is three versions behind — and behind all of it, a Drupal 7 backend I supported and extended. The brief was never "rewrite it"; it was "keep it running, make it more, and don't break the apps already out there in the world."
A new API that didn't abandon the old phones
The updated app needed a new API — call it 2.0 — but you cannot post a software update to a tractor. Plenty of users would stay on older app versions for months, and every one of them still had to work. So the new API shipped with backward compatibility deliberately built in: two versions answering at once, the old phones none the wiser, the new ones getting the better contract. Boring to the user, which is exactly the point.
API 2.0 and the legacy contract, served side by side. The old phones never noticed.
PHP 5.6 → 7.4 underneath — without breaking the apps already in the field.Telling phones things, on purpose
Then came Firebase and push notifications — the unglamorous plumbing that lets a backend tap a specialist on the shoulder when something in the field needs them. Guzzle for the integrations, JSON over the wire, and a PHP 5.6 → 7.4 migration underneath the whole thing so the platform wasn't standing on an end-of-life runtime. Modernise the foundations, extend the reach, break nothing in service. That was the job.
