Modernising a decade-old PHP platform without stopping the business

Squava is a working product with paying customers: time tracking, invoicing and project management for professional services firms. It had been running for a decade, and a decade of organic growth had left its mark.

The application still did its job, but changing it had become slow and risky. Business logic had spread across the codebase without clear boundaries, so a small feature could touch code nobody wanted to touch. Performance had degraded steadily as customer data accumulated — some API calls had become slow enough for users to feel. And a single shared codebase served many tenants, which made every change a question of who else it might affect.

The obvious suggestion in this situation is a rewrite. A rewrite would also have meant years without new features, a high chance of losing behaviour the business depended on, and a cutover that risked the revenue the product was already generating.

Before proposing any architecture, the actual bottlenecks needed to be found rather than guessed at. The slowest endpoints were profiled and traced back to their real causes.

The results were informative: most of the worst performance was not the framework's fault. It came from query patterns and schema decisions that had been reasonable at a smaller data volume and no longer were — queries scanning far more than they needed, joins that had grown with the product, and indexes that no longer matched how the data was actually being read.

That mattered, because it meant the performance problem and the maintainability problem could be treated separately. Speed did not have to wait for a rewrite.

The platform was migrated to Slim incrementally, module by module, while it remained in production. Each module moved across behind stable interfaces, so the rest of the application kept working and backward compatibility was preserved throughout. There was no big-bang cutover.

The multi-tenant PostgreSQL layer was redesigned and migrated to properly isolate tenant data and support the query patterns the product actually uses. Complex SQL was optimised directly, with schema and indexing changes made to match real access patterns rather than assumed ones.

SOLID principles were applied to the new backend boundaries so the parts being rebuilt would be genuinely maintainable rather than a fresh layer of the same problem. Coding standards and peer review were established so quality held as more of the codebase moved across.

Many API endpoints improved by up to 80%, with the slowest paths seeing the largest gains. The improvement came from query and architecture work rather than from throwing infrastructure at the problem.

Just as importantly, the migrated parts of the system became genuinely easier to change. New features stopped being archaeology.

The business kept selling and supporting the product the entire time. Modernisation happened around live customers rather than instead of them.