INaudio: a platform migration in one hour of downtime

The challenge

INaudio is one of the largest audiobook distributors in the world. Founded in 2004, acquired by Spotify in 2021, and returned to independent ownership in 2025. Reclaiming independence meant physically moving the entire platform: every service, every repository, and every byte of content, out of Spotify’s cloud and into INaudio’s own.

Here is what that meant in practice.

• 120+microservices
• 100+repositories
• 2,000+terabytes of static files
• 400Mindividual files
• 25Munique products
• 300distribution partners

None of it could stop. Roughly 700 million monthly listeners were using the platform throughout, and 50,000 to 60,000 audiobooks moved through the pipeline every day of the migration.

Three constraints made it genuinely hard rather than merely large.

We could never access the source environment. Not once. Tarmac had no credentials in Spotify’s cloud at any point, by design. Every fact about the system we were rebuilding had to be obtained without logging into the thing we were rebuilding.

Disruption to listeners had to be near zero. A distribution platform that goes dark takes 300 retail partners and their catalogues with it.

Technical support transferred on day one. There was no grace period in which the new team learned the platform before being accountable for it. The moment the cutover completed, every ticket was ours. That story is how INaudio’s support desk went from two days to twenty minutes.

What we did

A three-zone handover, with a wall in the middle

The migration ran through an intermediary. Spotify selected and exported data into a staging area. There it was cleaned for security and privacy risk, checked, and then duplicated exactly into INaudio’s own cloud. Tarmac worked in the middle zone and the destination zone, never the source.

1. No Tarmac access

   Source cloud

   Spotify selected and exported the data. Tarmac held no credentials here at any point in the engagement.

2. Joint team

   Staging area

   Data landed, was cleaned for security and privacy risk, and was verified. Spotify, INaudio and Tarmac worked here together to confirm that what arrived matched what left.

3. Tarmac and INaudio

   Destination cloud

   Clean data imported into INaudio-owned infrastructure, rebuilt to behave identically, then tested until it did.

That wall is the reason this was a reverse-engineering project rather than a copy job, which is not how it was scoped at the start.

The documentation was wrong, and the staging area proved it

The plan assumed we could rebuild the environments from their infrastructure-as-code definitions and the handover documentation. What arrived in the staging area did not match either. The running environments had drifted a long way from the scripts that were supposed to define them, over years of production changes that never made it back into code.

This is the ordinary condition of long-lived infrastructure, and it is worth being blunt about how it fails. Infrastructure as code stops describing reality the moment someone fixes something in a console at 2am. Every one of those small divergences is invisible until you try to rebuild the system somewhere else, and then all of them surface at once.

So the work became: infer the real configuration from the evidence, rebuild it, and then prove the rebuild was right. Two people were dedicated full time at peak to nothing but testing and validating integrations, processes, and logging. When we believed we had it, we did the thing that makes reverse engineering safe rather than optimistic: we brought Spotify’s own engineers in to audit our environment against theirs and tell us where we were wrong.

Eight months of preparation to make three days possible

1. 8 months Pre-cutover. Staging, cleaning, duplicating and verifying data, and migrating every repository and service.
2. 3 days Round the clock. Final backups, and automating everything that could be automated before the switch.
3. 1 hour Total downtime at the cutover on August 1st.

The three days before the cutover were spent on backups and on automation, and the automation is the part that produced the one hour figure. Every one of the 120+ services had been given its own deployment pipeline during the preceding months. That meant the cutover itself was not a sequence of a hundred careful manual deployments in a tense order. It was one coordinated event in which everything deployed at once, because everything already knew how to deploy itself.

That is the trade the whole project rests on. Eight months of unglamorous preparation buys you a cutover that is boring, and a boring cutover is the only kind that finishes in an hour.

The team scaled with the risk

• Early preparation 1
• Final testing 6
• Post-cutover support 11

Alongside three senior DevOps engineers throughout, for a team of fourteen at peak.

The engagement started DevOps-heavy with a single developer. It reached six through final testing, because 100+ repositories had to be validated inside three months, against the four or five a normal project would involve. It settled at eleven after the cutover, when the work became keeping a live platform healthy for 700 million listeners.

The results

The assessment both teams landed on afterwards was the same:

Everything went even smoother than one would expect from a project this scale.

One hour of downtime, on a platform serving roughly 700 million monthly listeners, moving 120+ microservices and more than two petabytes between two clouds.

No access to the source environment, ever. The separation held from the first day to the last, which is what made the migration acceptable to both sides.

Nothing was lost. 25 million products, 400 million files, and 300 partner distribution relationships arrived intact and verified, audited by the engineers who built the original.

The team was ready to support it. Technical support transferred at the moment of cutover, as agreed, with no handover period.

What came next

The migration bought independence. It did not, by itself, buy a better platform: the first month after the cutover was deliberately spent changing nothing at all, learning how the pieces fit before touching any of them.

What followed was the work the migration made possible. The infrastructure was rewritten in code that was accurate this time, taking more than $500,000 a year out of the cloud bill, and the support desk was rebuilt around an agentic workflow that cut ticket triage from two days to twenty minutes.

Tarmac is INaudio’s technical team, from the engineers who ran this cutover to the VP of Engineering.