How PropTechX Reduced Page Load Times by 78% Through Modern Stack Migration

Overview

PropTechX, a established real estate technology company based in Bangalore, India, had built their core platform on a PHP monolithic architecture in 2018. By 2024, their platform served over 50,000 monthly active users searching for commercial and residential properties across 12 cities. However, as their user base grew and feature requirements became more complex, their legacy system began showing significant signs of strain. Page load times exceeded 8 seconds during peak hours, the deployment pipeline took over 4 hours to complete, and the development team struggled to implement new features without introducing bugs into existing functionality.

Webskyne was engaged to assess the situation, design a modern architecture, and execute a phased migration strategy that would minimize business disruption while delivering measurable improvements in performance, scalability, and developer productivity.

This case study documents the complete journey from legacy to modern infrastructure, including the technical decisions, implementation challenges, and quantifiable business outcomes achieved over a 9-month engagement.

Challenge

PropTechX faced several interconnected challenges that threatened their market position and growth trajectory. Their existing platform, built on PHP 7.2 with a MySQL database, had evolved organically over six years into what engineers often describe as a "big ball of mud"—a monolithic application where business logic, presentation layer, and data access were tightly coupled throughout the codebase.

The first major challenge was performance degradation during high-traffic periods. During property listing updates and weekend browsing peaks, the application experienced response times exceeding 8-12 seconds, with timeout errors affecting approximately 15% of requests. User complaints about slow searches and unresponsive property detail pages had increased by 340% over the previous year, correlating directly with a 28% decline in user retention rates.

Second, the deployment process had become a significant bottleneck. The monolithic architecture required full-stack redeployment for any code change, no matter how small. A typical deployment involved 4-6 hours of manual testing, during which the platform experienced downtime windows that affected live user sessions. The development team could only ship features in bi-weekly cycles, severely limiting their ability to respond to market demands and competitive pressures.

Third, scaling was problematic. The single-server architecture meant that to handle increased load, they needed to replicate the entire application stack. This approach was cost-inefficient and didn't address the underlying issue of database bottlenecks during complex property searches that involved multiple JOIN operations across millions of listing records.

Finally, the technical debt had accumulated to a critical level. The original development team had departed, and the current team struggled to understand and modify the spaghetti code that lacked documentation, proper version control practices, and consistent coding standards. Onboarding new developers took 3-4 months before they could contribute meaningfully to production code.

Goals

Working closely with PropTechX's leadership team, we established clear, measurable objectives that would define project success:

• Performance Target: Reduce average page load time from 8.5 seconds to under 2 seconds, with p95 response times not exceeding 3 seconds
• Availability: Achieve 99.9% uptime with zero-downtime deployments
• Scalability: Enable horizontal scaling to handle 5x current traffic without architecture changes
• Developer Velocity: Reduce deployment time from 4 hours to under 15 minutes, enabling daily releases
• User Engagement: Improve key metrics including session duration, pages per session, and conversion rates
• Cost Efficiency: Optimize infrastructure costs while improving performance

Approach

Our approach combined strategic planning with pragmatic execution. We adopted the Strangler Fig pattern to gradually migrate functionality from the legacy system to new microservices, allowing continuous business operations throughout the transition.

The first phase involved comprehensive discovery and documentation. Our team spent three weeks conducting code audits, performance profiling, and stakeholder interviews to create a detailed map of the existing system. We identified 14 distinct domain areas within the monolith, prioritized by business criticality and migration complexity. Property search emerged as the highest-priority domain due to its performance impact and frequency of user interaction.

For the technology stack, we selected a modern, battle-tested combination: Next.js for the frontend, Node.js with Express for API services, PostgreSQL for relational data, Redis for caching, and AWS Lambda for event-driven functions. We chose Kubernetes on AWS EKS for container orchestration, providing the horizontal scalability that PropTechX required.

We implemented a strangler facade pattern, where a new API gateway sat in front of both the legacy and new systems. Incoming requests were routed to the new microservices for domains that had been migrated, while legacy domains continued functioning on the old system. This allowed incremental migration without a "big bang" launch that would risk business disruption.

Implementation

The implementation spanned six months and was executed in four distinct phases, each delivering measurable value.

Phase 1: Foundation (Weeks 1-6) — We established the new infrastructure including the AWS EKS cluster, CI/CD pipelines using GitHub Actions, monitoring with Datadog, and the API gateway using Kong. We also implemented the strangler facade that would route traffic between old and new systems. This phase focused entirely on infrastructure without any user-facing changes.

Phase 2: Property Search Microservice (Weeks 7-14) — The property search domain was the crown jewel of this migration. We rebuilt the search engine using Elasticsearch, dramatically improving query performance for complex filters like location radius, price range, property type, and amenities. We implemented Redis caching for frequently searched queries, reducing database load by 65%. The new search service was deployed behind the facade and initially received only 10% of traffic, gradually increasing as confidence grew.

Phase 3: Core Services Migration (Weeks 15-22) — We migrated user authentication, property listings management, and favorites/bookmarks to the new architecture. Each domain was carefully moved, with thorough load testing before traffic shifting. We implemented feature flags to enable instant rollbacks if issues emerged. The new Next.js frontend was introduced progressively, starting with the property detail pages.

Phase 4: Legacy Sunset and Optimization (Weeks 23-26) — With 90% of traffic now on the new architecture, we focused on decommissioning the legacy servers and optimizing the new system. Database connections were pooled and optimized, unnecessary API calls were eliminated through better frontend data fetching strategies, and we implemented automated scaling policies based on real traffic patterns.

Throughout the implementation, we maintained detailed documentation and conducted knowledge transfer sessions with PropTechX's internal team, ensuring they could maintain and extend the new system independently.

Results

The results exceeded our initial projections across virtually every measurable dimension. The migration transformed PropTechX's technical foundation and business performance in ways that became immediately apparent to both internal teams and end users.

Most dramatically, page load times improved by 78%, from an average of 8.5 seconds to 1.87 seconds. The p95 response time, which had previously peaked at 12 seconds during traffic spikes, now consistently stayed under 2.5 seconds. These improvements were achieved through multiple optimization layers: Elasticsearch for search, Redis caching, efficient database query patterns, and Next.js server-side rendering that reduced Time to First Byte significantly.

User engagement metrics showed impressive improvements within the first month after full migration. Session duration increased by 42%, from an average of 4.2 minutes to 5.96 minutes. Pages per session grew from 3.8 to 6.2, indicating that users were browsing more properties before converting or leaving. Most importantly, the bounce rate decreased by 34%, meaning more users were finding value in the platform and staying longer.

The conversion rate for property inquiries—the primary business metric—increased by 67%, translating to significant revenue growth. Faster page loads and smoother user experiences directly correlated with users completing more property searches and submitting more inquiry forms.

Metrics

The quantitative results validated our approach and exceeded initial projections:

• Page Load Time: 8.5s → 1.87s (78% improvement)
• P95 Response Time: 12s → 2.3s (81% improvement)
• Uptime: 99.2% → 99.95%
• Deployment Time: 4 hours → 12 minutes (95% reduction)
• Release Frequency: Bi-weekly → Daily
• Session Duration: 4.2 min → 5.96 min (42% increase)
• Pages per Session: 3.8 → 6.2 (63% increase)
• Bounce Rate: 58% → 38% (34% reduction)
• Conversion Rate: 2.1% → 3.5% (67% increase)
• Infrastructure Costs: Reduced by 28% despite 3x traffic growth
• Database Query Performance: 450ms avg → 45ms avg (90% improvement)

Lessons

This engagement produced several valuable insights that inform our approach to similar migrations:

Start with the highest-impact domain. By prioritizing property search—the most frequently used and performance-sensitive feature—we delivered immediate user-visible improvements that built confidence for subsequent phases. Trying to migrate administrative functions first would have provided less visible value despite similar effort.

The strangler pattern minimizes risk. The incremental migration approach allowed us to validate each new service in production with real traffic before fully committing. When issues arose—as they inevitably did—they affected only a fraction of users and could be rolled back instantly using feature flags.

Invest in observability from day one. Comprehensive monitoring, logging, and tracing enabled us to quickly identify and resolve issues during the migration. Without proper observability, debugging distributed systems in production would have been significantly more challenging.

Knowledge transfer is critical. Building a better system means nothing if the client can't maintain it. We prioritized documentation, code reviews, and paired programming sessions to ensure PropTechX's team could operate the new architecture independently.

Performance optimization is iterative. The initial migration achieved our 2-second target, but subsequent optimization sprints further reduced load times to under 1.9 seconds. Continuous improvement, enabled by the new architecture's flexibility, delivered compounding benefits.

This case study demonstrates that with careful planning, incremental execution, and the right technology choices, even heavily legacy-constrained platforms can be transformed into modern, scalable systems without business disruption. The key lies in treating migration not as a technical project but as a business transformation that happens incrementally, delivering value at every step.