From Legacy Monolith to Cloud-Native: A FinTech Mobile App Transformation Case Study

## Overview In late 2024, a well-established financial services provider approached Webskyne with a pressing problem: their core desktop trading platform, built over a decade earlier, was failing to keep pace with the expectations of modern retail investors. Users overwhelmingly preferred mobile access, yet the existing application was a cumbersome Java Swing desktop tool that required VPN access, frequent restarts, and offered no real-time notifications. The organization needed a complete reimagining — not just a responsive website, but a true cross-platform mobile experience backed by a scalable, resilient cloud architecture. ## Challenge The engagement began with a three-day technical audit that revealed a deeply intertwined monolith. The legacy system ran on a single on-premises server, shared a monolithic database across trading, reporting, and user-management modules, and had no CI/CD pipeline. Deployment meant server downtime, and scaling required physical hardware procurement. Mobile users were effectively second-class citizens, accessing the platform through a thin HTML wrapper that struggled under load. Specific pain points included: - **Performance degradation during market volatility:** Server metrics showed response times spiking above 8 seconds during high-traffic events. - **No offline resilience:** Network blips dropped user sessions entirely, forcing frustrating re-authentications. - **Cross-platform inconsistency:** iOS and Android users received different experiences through separate native wrappers, leading to fragmented feature parity. - **Slow release cycles:** New feature deployments averaged six weeks, with manual rollbacks taking hours. ## Goals We established four primary goals to measure success: 1. **Unified cross-platform experience** — Deliver a consistent, native-feeling interface on iOS and Android using a single codebase, capable of operating offline. 2. **Cloud-native infrastructure** — Migrate to a hybrid AWS/Azure architecture with auto-scaling, zero-downtime deployments, and disaster recovery. 3. **Sub-second API response times** — Ensure 95% of API calls complete under 500ms, even during peak market hours. 4. **Developer velocity** — Reduce deployment time from six weeks to under one week while improving rollback safety. ## Approach Rather than recommending a full rewrite from day one, we proposed a strangler-fig migration pattern. The strategy involved incrementally extracting bounded contexts from the monolith — starting with user authentication and market data feeds — while deploying new capabilities alongside the legacy system. This minimized risk and allowed the client to realize business value early. For the frontend, we selected Flutter. Its single-codebase approach aligned perfectly with the goal of feature parity across platforms, and its mature ecosystem offered reliable packages for charting, secure storage, and REST/GraphQL integration. For backend modernization, we designed an event-driven architecture using Node.js (for real-time websocket feeds) and NestJS (for structured, modular business logic), containerized with Docker and orchestrated via Kubernetes on EKS. Azure played a supporting role for monitoring, identity management through Azure AD B2C, and secondary failover. The data layer was reimagined using a CQRS-inspired pattern: read-heavy operations (market data, portfolio views) served from optimized read replicas in DynamoDB, while transactional writes persisted through a managed PostgreSQL instance on AWS RDS. Event streams were captured with Kafka and replayed for audit and analytics pipelines. ## Implementation **Phase One: Foundation (Weeks 1–4)** We began by establishing the new backbone. Infrastructure-as-Code using Terraform defined the AWS/Azure hybrid topology. GitHub Actions replaced the ad-hoc deployment scripts, with automated security scanning and canary deployments. A dedicated Flutter project was scaffolded with modular feature folders, custom theming aligned to the client's brand, and secure local storage using flutter_secure_storage. **Phase Two: Authentication & User Management (Weeks 5–8)** This was the first strangler-fig extraction. The legacy authentication module was wrapped with an API gateway that routed new token requests to the fresh Azure AD B2C pipeline while maintaining compatibility with existing session tokens. The Flutter app implemented biometric authentication (Touch ID/Face ID) alongside traditional MFA, dramatically improving login completion rates. **Phase Three: Real-Time Market Data (Weeks 9–12)** The most visible pain point was market data performance. We built a WebSocket gateway using NestJS and Socket.io, deployed across multiple AWS regions. Data teams confirmed that tick processing latency dropped from 800ms to 45ms, a 94% improvement. The Flutter client used a custom graph client library to render candlestick and line charts with smooth 60fps animations, even on mid-range Android devices. **Phase Four: Trading Execution & Portfolio Management (Weeks 13–18)** Trading logic was extracted module by module. Each bounded context — order placement, portfolio valuation, risk engine — became an independent deployable service. The Flutter frontend consumed GraphQL subscriptions for portfolio updates, eliminating the need for repeated polling. Offline support was critical here: flutter_local_notifications combined with background fetch allowed pending orders to be queued securely and submitted when connectivity restored. **Phase Five: Observability & Launch (Weeks 19–24)** We invested heavily in observability before the public launch. Distributed tracing with Jaeger linked frontend performance metrics to backend service latencies. Custom dashboards in Grafana tracked business KPIs — orders per minute, conversion rates, error budgets — alongside traditional infrastructure metrics. Azure Monitor ingested logs from both EKS and on-premises legacy components during the dual-run period. The launch itself was a phased rollout: 10% of users on day one, 50% by week two, and 100% by week four. Each phase was accompanied by automated feature flags, instant rollback capability, and a dedicated on-call rotation. ## Results The transformation exceeded expectations across every dimension. **User Experience:** The average session duration increased from 3 minutes to 11 minutes, indicating that users were engaging more deeply rather than abandoning the platform out of frustration. App store ratings climbed from 2.4 stars to 4.7 stars across both platforms within the first quarter post-launch. Customer support tickets related to platform technical issues dropped by 68%. **Business Impact:** Active monthly users grew from 22,000 to 98,000 within 12 weeks. Trading volume through the mobile channel increased 215%, and the new real-time alerts feature drove a 40% increase in user-initiated trades during market hours. Client retention improved from 78% to 94% annually. **Operational Excellence:** Infrastructure costs decreased by 42% despite the significant increase in usage, thanks to AWS auto-scaling and the elimination of over-provisioned on-premises hardware. Deployment frequency shifted from monthly releases to twice-weekly production deployments, with a mean time to recovery of under 12 minutes. ## Metrics | Metric | Before | After | Change | |--------|--------|-------|--------| | API Response Time (p95) | 4.2 s | 0.38 s | −91% | | Monthly Active Users | 22,000 | 98,000 | +340% | | Infrastructure Cost | $48,000/mo | $27,800/mo | −42% | | Deployment Frequency | 1/month | 2/week | +800% | | Mobile App Store Rating | 2.4 ★ | 4.7 ★ | +96% | | Uptime SLA | 98.1% | 99.98% | +1.88pp | | Customer Support Tickets | 380/mo | 122/mo | −68% | | Avg. Session Duration | 3 min | 11 min | +267% | ## Lessons **1. Strangler-Fig Beats Big Bang.** Incremental extraction allowed us to validate hypotheses early and manage risk. By the time we reached the most complex trading execution module, we had battle-tested infrastructure, monitoring, and rollback procedures. A monolithic rewrite would almost certainly have encountered unforeseen blockers and missed the holiday trading season deadline. **2. Offline Is Not Optional for Mobile.** Treating offline as an afterthought is a common mistake. In trading, connectivity is never guaranteed. Designing for queue-and-replay from day one, rather than patching it in later, saved months of rework and built user trust. **3. Observability Drives Confidence.** Investing in distributed tracing, business-level dashboards, and automated alerting before launch meant that during traffic spikes, we could diagnose root causes in minutes rather than hours. Observability is not just an operational tool — it is a product feature. **4. Cross-Platform Requires Discipline.** Flutter's single codebase is powerful, but only when paired with clear architectural boundaries. We enforced a strict separation of platform-specific code (biometrics, permissions, notifications) into isolated adapters. This kept the shared layer clean and made regression testing manageable. **5. Hybrid Cloud Is Compromise, Not Gospel.** Our initial instinct was a pure AWS deployment, but the client's existing Azure investments for identity and compliance were non-negotiable. Treating the two clouds as a cohesive fabric — with Azure AD B2C issuing tokens consumed by AWS services, and Azure Monitor aggregating AWS telemetry — turned a constraint into a strength. --- *This case study was authored by Webskyne's editorial team in collaboration with our platform engineering practice. For organizations navigating similar digital transformation journeys, we offer complimentary architecture assessments and migration roadmapping sessions.*