Most PHP apps that need modernizing aren’t broken. They work, people rely on them every day — and that’s exactly what makes a rewrite so risky. For months the business gets nothing new while a second system tries to catch up with the first.
Our own 2022 learning portal is a good example: institute, faculty and student dashboards, SQL inside the templates, PHP sessions for sign-in. Here’s how we approach re-platforming it without a big-bang cutover.
Inventory before architecture
Start with a list of every page: what it reads and writes, and who uses it. It’s unglamorous work and the most useful document in the project, because it turns “the old system” into a set of modules you can move one at a time.
- Pages and routes: every URL, grouped by module.
- Data: the tables each page reads and writes.
- People: which role uses it, and how often.
- Risk: what breaks, and for whom, if it goes wrong.
Put an API in front of the data
Before moving a single screen, put a typed API in front of the existing database. New screens use it from day one, and old pages can be pointed at it gradually. Both apps read the same records, so there’s never a second copy of the truth to reconcile.
Route by module, not by release
A small routing layer sits in front of both apps and decides, path by path, which one serves the request. Moving a module means adding one line, and moving it back is just as quick.
// Send migrated modules to the new app; everything else stays on PHP.
const MIGRATED = ["/login", "/students", "/timetable"];
export function upstreamFor(pathname: string) {
return MIGRATED.some((path) => pathname.startsWith(path)) ? NEW_APP : LEGACY_PHP;
}Share sign-in early
Nothing erodes trust faster than being asked to log in twice. Swapping PHP sessions for a token both apps can verify is the first move, before any screen people would notice.
Measure the boring things
- Error rate per module, old versus new.
- Load time for the screens people use most.
- Support questions after each move.
- Time from a change request to it going live.
A rewrite asks for trust up front. Moving module by module earns it one screen at a time.
When the last PHP page stops receiving traffic, there’s no dramatic switch-off. The old app simply goes quiet — which is exactly how a modernization should end.
