Infrastructure Migration for a High-Volume Music Platform
MyMP3Pool is a subscription platform built around DJ record pool distribution: record labels deliver licensed tracks, DJs pay a monthly subscription to preview and download music in multiple versions — clean, explicit, and radio-safe.
Everything the platform runs on — the full catalog, user accounts, subscriptions, and the processing pipeline — lived on a single physical server with one local drive. For years it held. Then three problems converged: an OS too old to update safely, ingest volume outpacing the disk, and a drive nearing capacity with no backup behind it. Together, they put the business one hardware failure away from an unrecoverable loss.
Three issues converged at once. Artem Chervychnyk, Lead Backend Developer at Mind Studios breaks down each one.
Frozen tech stack
An Ubuntu version too old to support the platform’s dependency updates, Node.js included. Updating Ubuntu risked bringing the platform down entirely. Development had been frozen; nothing new could be shipped safely.
An outdated Node version on an Ubuntu build that can't support an upgrade sounds like a minor inconvenience. In practice, it means the entire stack is frozen. You can't ship improvements, you can't patch security issues properly, you can't move forward. The only way out is a migration.
One drive holding everything
All content and user data lived on a single 40TB physical hard drive with a local US provider. No redundancy, no backup. At the point we raised the migration conversation, 38TB of it was used.
Thirty-eight terabytes on a single drive with no backup is not a question of if it fails. It's a question of when. And when it fails, there is no recovery. We raised it with the client as soon as we understood the full picture. That conversation wasn't comfortable, but it was necessary.
Ingest volume outpacing capacity
The Orchard partnership changed the content volume overnight. When disk space ran out, user registrations failed, uploads were blocked, and the system couldn't operate. Retention rules were invented on the fly to buy time: hide content after two years, but keep storing it. It wasn't a solution.
Inventing retention rules to buy disk space is a sign that the infrastructure has already lost. You're not solving the problem, you're postponing it. And every week you postpone it, the actual migration gets harder because more content has arrived that needs to move.
What we recommended
We didn't wait for a failure to trigger the conversation.
When the stack and storage constraints became clear, we built the case for migration and brought it to Delvin with a formal infrastructure options report. The existing setup was blocking DJ subscription platform development entirely.
Why migration now
The risk of staying on the existing setup outweighed the complexity of moving.
Why AWS
AWS was the recommendation for three reasons: US region availability, genuine redundancy through S3 object storage, and a content delivery layer via CloudFront that the platform didn't have at all.
Why not Hetzner
The evaluation covered several hosting providers. Hetzner was ruled out: European regions only, wrong geography for a US platform.
Migration strategy
The migration plan was designed to be slow and deliberate. Music platform infrastructure migration at this scale (40TB of licensed content, active subscriptions, and a live ingestion pipeline) required planning the rollback options as carefully as the migration itself.
When your platform outgrows its infrastructure, the risk isn't the migration. It's who you trust to do it.
The AWS S3 migration was planned in one direction: slow and careful. With 40TB of licensed content and an active subscription base, the priority at every step was making sure there was always a way back before we moved forward.
New environment and stack upgrades
The new AWS environment stood up first, then we updated everything the old Ubuntu build had been blocking: Node version, frontend and backend dependencies, packages that hadn't moved in years. The infrastructure itself wasn't the hard part. Everything that had been running on it was.
Audio processing worker
Every track needs multiple versions: explicit, clean, radio-safe. The platform's music streaming infrastructure uses HLS for playback, which adds another processing layer on top of version generation. The internal worker handling all of this was built on FFmpeg and hadn't been touched since it was first written. Rebuilding it, updating its dependencies, and verifying correct output across every version type and streaming format was the most technically involved part of the migration.
S3 storage architecture & content ingestion pipeline
The S3 object storage architecture was organized for fast retrieval, cost-efficient access, and clean separation between content types. Then every ingestion path was rebuilt to land content correctly within that structure. Each supplier delivered differently: some via FTP upload, The Orchard directly to S3. The Ruby on Rails backend had to handle all of these paths through the FFmpeg worker, storing the resulting versions in the right place. Every path was tested individually before anything moved to production.
Parallel running period
A deliberate risk management decision: new incoming content was routed directly to S3 while the Ruby on Rails application continued processing on the old hardware. This let us run the full pipeline in parallel (ingest to S3, process through the updated FFmpeg worker, verify HLS output, and confirm file organization) against live content, with real suppliers, before any production users were touched.
Cutover
Another deliberate decision: the old production environment stayed live for one month after cutover as a fallback. With an active subscription base and 40TB of content, the cost of keeping the old server running was low relative to the risk of not having it. It was never needed. The old server was decommissioned.
What came after
The project didn't end at cutover. It rarely does.
We added a CDN layer
S3 storage is cost-efficient at rest. Serving files at scale is a different calculation. Once we understood the egress volume, we added CloudFront as a CDN layer. It wasn't in the original scope, but the cost structure made it the right next step. Delivery costs came down 30% once the CDN was in place.
We blocked automated bulk downloaders
We found automated scripts pulling 100 to 500 tracks per minute, circumventing the platform's download flow and generating heavy server load without matching subscription revenue. Using CloudFront's edge filtering, we identified and blocked that traffic before it reached the Rails application. The client hadn't flagged it as a priority, but once we were inside the infrastructure, it was hard to miss.
The resulting outcome
Both of those came after the migration closed.
That's the nature of long-term MP3 record pool development: the work continues past the handoff because the relationship does.
Results
The migration resolved an infrastructure crisis that had been building for years — a cloud migration without downtime that reopened the platform for active development. What follows are the outcomes, technical and operational, that resulted from getting the infrastructure right.
before
Single 40TB drive, no backup
after
Redundant cloud storage on AWS
before
Development frozen for years
after
Active development resumed
before
Manual ingestion per supplier
after
Automated pipeline for all sources
before
No CDN layer
after
CloudFront added, 30% reduction in delivery costs
Health & Fitness Remote Coaching Software
