01
Upgrade the Existing Stack
Update Magento and its dependencies to newer versions.
A decade of customizations made this practically impossible. The code had drifted too far from standard Magento to upgrade cleanly.
Migrating 400K Users Without Downtime
Replaced a decade-old Magento-based e-learning platform with a modern cloud-native architecture, migrating 400,000+ students with zero downtime and 99.99% accuracy.
// client
US E-Learning Company
// industry
EdTech
// my role
Solution Architect
// duration
2.5 years
// year
2022-2025
// 01 · the challenge
A Decade of Technical Debt
A US-based e-learning company had been running on a Magento-based platform for over ten years. What started as a quick solution had become a liability—slow, expensive, and increasingly difficult to maintain. The platform was struggling under its own weight, and the business was feeling the pain.
- !Performance issues — The site was too slow, frustrating students and hurting conversions
- !Low conversion rates — Students were dropping off before completing enrollment
- !Security vulnerabilities — End—of—life software had too many known exploits
- !Skyrocketing costs — Hosting and cloud expenses were eating into margins
// 02 · the approach
Evaluating the Options
We didn't jump straight to a solution. The team evaluated three distinct approaches, each with its own trade-offs.
rejected
02
Optimize the Previous Vendor's Solution
The last vendor had built a partial replacement. We could optimize and extend it.
The hosting costs were astronomical, and the architecture was fundamentally flawed. Polishing it would have been expensive and temporary.
03
Build Cloud-Native in Parallel
Create a new serverless application from scratch while keeping the old system running.
This protected the existing revenue stream while giving us freedom to design for current and future needs.
// 03 · why this approach
Why this approach?
// rationale
Why Build Cloud-Native in Parallel?
We chose to build a new cloud-native application in parallel to the existing stack. The MVP would handle new traffic first, proving itself before we touched existing users.
This approach was slower but safer. The existing platform was still generating revenue—we couldn't afford to break it. Building in parallel meant we could take requirements directly from Product Managers who dealt with users and the legacy system daily.
We chose serverless architecture specifically to address the cost problem. "No use, no cost" — If the system is not in use, it should not incurs cost.
// 04 · implementation
From MVP to Full Migration
Phase 1: MVP Launch
7 months (Nov 2022 - June 2023)
Launched the MVP site on June 30th, 2023. This release included an enterprise-level data store, architected and built within 2 months.
- →MVP live in 7 months
- →Enterprise data store built in 2 months
- →25% increase in overall system scalability and reliability
Phase 2: Full Launch
3 months (July - September 2023)
Launched the complete application with existing and new features. Moved the new site to the primary domain and the old one to a legacy domain.
- →Full feature parity achieved
- →New site became primary domain
- →Legacy site continued supporting existing users during migration
Phase 3: Conversion Features
Ongoing releases (2023-2024)
Multiple releases to add features focused on improving conversion and expanding capabilities.
- →Digital wallets integration
- →Course Bundle Purchase
- →Partner pages
- →Acrobatiq course support
Phase 4: User Migration
2024-2025
Built the migration pipeline and started migrating users in phases. Asynchronous pipeline with queues, step-by-step monitoring, and careful coordination with downstream systems.
- →Phased migration approach
- →Queue-based async processing
- →Step-by-step monitoring
- →99.99% migration accuracy
// 05 · the near-miss
// near-miss
The Salesforce Incident
The first migration wave went perfectly. Data moved cleanly, monitoring showed green across the board, and the team was celebrating. Then the evening call happened. Their internal Salesforce pipeline had broken. The CRM team hadn't tested for all the edge cases our migration surfaced. Enrollments were coming through, but downstream processes were failing silently.
// resolution
We paused all further migration waves immediately. This wasn't a technical failure on our end, but it was still our responsibility to coordinate. We delayed the rest of the migration to make sure their Salesforce team got proper time to fix and test the solution. We helped them with different use cases based on the existing data. Final result: 99.99% accuracy. Every active, inactive, and expired user accounted for.
// 06 · surprises
What We Didn't Expect
// 01
No Shared Product Definition
Even after working on the same product for years, the team was missing a single definition of the product. Each person had their own version. We first trained them with product mindset training which helped them have a common definition and language.
// 02
Siloed Teams
Cross-team communication between different client teams was missing. Every team was working in silos, which made our work more challenging as we needed to make sure our application works with their existing systems.
// 07 · results
The Numbers
400K+
Users Migrated
Active, inactive, and expired accounts
99.99%
Migration Accuracy
Every user accounted for
150%
Conversion Increase
Faster, cleaner enrollment flow
50%
Cost Reduction
Serverless architecture
25%
Scalability Increase
Enterprise data store
0
Downtime
Parallel operation throughout
- ✓Modern stack enabled faster feature development
- ✓Security vulnerabilities eliminated
- ✓Unified product vision across teams
- ✓New features: Digital wallets, Course Bundles, Partner pages, Acrobatiq support
// 08 · retrospective
Looking Back
01
Application Dependency Mapping — I would conduct a comprehensive dependency mapping exercise on day one to clearly define all impacted stakeholders and downstream systems (like the CRM/Salesforce pipeline) before writing a single line of code.
02
Mandatory End-to-End Integration Testing — Rather than trusting that parallel teams had fully tested their own systems for the migration, I would mandate cross-team, end-to-end integration testing protocols well before the first migration wave.
// key lesson
Technology is rarely the hardest part of a digital transformation. We successfully replaced a massive, decade-old application with a sleek, cost-effective, cloud-native architecture. But our biggest risks came from siloed teams and a fragmented product vision. You can build the most elegant serverless system in the world. But if the stakeholders aren't speaking the same language or understanding the "why" behind the product, the project will struggle. The immense value of a shared product mindset and clear communication — that's what I still think about from this project.
// 09 · tech stack
Tech stack
AWS LambdaAPI GatewayDynamoDBCognitoSQSSNSS3Step FunctionsEventBridgeCloudWatchAWS CDKNode.jsTypeScriptReactMySQLStripe
Have a system that needs a second pair of eyes?
Evenings (IST) and weekends, I share what I've learned with engineers building production systems. Architecture reviews, an honest second opinion, or just a sounding board — happy to help where I can.