EdTech / Learning Management System·Multi-phase build + migration
Migrating an academy LMS to MongoDB — Figma-faithful build with pre-launch load testing
How I migrated a course platform's legacy data to MongoDB, rebuilt it to a Figma-faithful design, and ran structured load tests before launch.
- Industry
- EdTech / Learning Management System
- Client
- Rifat Academy
- Timeline
- Multi-phase build + migration
- Service
- Custom LMS Development →
- Project
- Visit project
What changed
Before
After
Before
Legacy course data
After
MongoDB migration
Before
Per-user notification bloat
After
Global notification model
Before
Untested under load
After
k6 + Grafana load tests
The challenge
A growing coaching academy needed to move their entire course catalog and student base onto a modern platform — without losing data, without downtime students would notice, and without compromising on design quality. They had an active student base already depending on the existing system daily, a Figma design that needed to be reproduced faithfully (not "close enough"), and no confidence that the platform could handle concurrent traffic once it launched.
My approach
I rebuilt the platform around a modern, scalable architecture:
- Full data migration to MongoDB — built a bulk migration script to move the course catalog and student data into a new MongoDB-based architecture with integrity checks
- Figma-faithful implementation — translated the design system to production as specified, down to spacing and typography, working closely with the design collaborator to catch discrepancies before launch
- Secure video content delivery — course video access built with authorization checks so content can't be freely shared or accessed outside an enrolled student's session
- Load testing before launch — ran structured load tests (k6 + Grafana) simulating concurrent student traffic under exam-season-style load
- Notification architecture rebuilt for scale — the original per-user notification design was creating document bloat as the student base grew; rebuilt it as a global notification model with a read-tracking array and automatic expiry to reduce storage growth
The outcome
We migrated the course catalog and student data to MongoDB, ran structured k6 load tests before launch, and resolved notification storage bloat by redesigning the notification model.
The original per-user notification design was silently filling up the database as more students joined, creating duplicate documents and pressuring the storage tier. I redesigned it into a single global document per notification with a read_by tracking array and a 10-day auto-expiry — a small architectural change that eliminated the bloat without changing how the frontend consumed notifications.
