Reducing legacy platform load time from 4s to 600ms

The business problem

A logistics enterprise ran morning dispatch through a web application built years earlier on shared hosting. The interface worked — dispatchers knew every screen — but login and the first dashboard load routinely took four seconds. With 120 vehicles entering the queue between 6:00 and 6:30 AM, those seconds compounded into delayed departures, missed SLA windows, and frustrated operations staff.

Leadership considered a full rewrite with a new UI. We proposed a narrower scope: rebuild the backend and data layer, keep the screens identical, and measure load time on the critical morning path. The engagement ran twelve weeks.

What we found in discovery

Profiling the production database revealed three dominant issues:

• N+1 queries on the dispatch board. Each vehicle row triggered separate lookups for driver, route, and status history. The morning view executed hundreds of queries per page load.
• Missing indexes on filter columns. Date-range filters on dispatch records performed full table scans because composite indexes had never been added after schema changes.
• Synchronous aggregation. Summary counts at the top of the dashboard were computed on every request instead of being cached or pre-aggregated.

The application server was also under-provisioned relative to peak concurrency, but fixing query patterns delivered the largest gain before any infrastructure spend.

Our approach

We used a strangler-fig pattern: new API endpoints backed by optimized queries ran alongside the legacy layer. The existing front end called the same URLs; we swapped implementations behind a routing layer once each endpoint passed parity tests.

Specific technical changes included:

• Consolidating vehicle, driver, and status data into two JOIN-heavy queries with explicit column lists instead of ORM lazy-loading.
• Adding composite indexes on (dispatch_date, depot_id) and (vehicle_id, status) after analyzing slow-query logs.
• Introducing a five-minute Redis cache for dashboard aggregates, invalidated on dispatch mutations.
• Moving session validation to a lightweight middleware path so authenticated users skipped redundant database round-trips.

We deployed behind feature flags and ran shadow traffic comparisons for two weeks before cutting over morning dispatch entirely.

Results

Post-migration, P95 load time on the morning dashboard dropped from 4.1 seconds to 600 milliseconds. Error rates during the peak window fell because timeouts stopped cascading. Dispatchers reported no training burden because the UI was unchanged.

The client retained full ownership of the codebase and infrastructure. We delivered runbooks for cache invalidation, index maintenance, and query monitoring so their internal team could operate the system independently.

Lessons for similar engagements

Not every legacy performance problem requires a greenfield rewrite. When users depend on a familiar interface and the pain is concentrated in backend latency, incremental modernization often delivers faster ROI with lower change-management risk.

If your organization faces a similar bottleneck, our backend development and legacy migration teams can assess whether a targeted rebuild fits your constraints. Read the full case study summary or request a consultation.