Re-Releasing Old Music on Streaming: When It Helps, When It Hurts

Should I reuse my old ISRC or get a new one when I re-release a track?

This is the whole decision, so start here before you touch anything else. Reuse the original ISRC when the audio file is identical: no edit, no re-record, no remix, no personnel change, and you're only changing the packaging or distribution around it. Adding an old single to an album, moving to a new distributor, re-pitching the same master to a library. Same recording, same code.

You need a new ISRC when the recording itself changed. If the audio was edited, re-recorded, or remixed, if it was remastered into a materially different recording, if you pulled a featured artist out of the credited version, or if the title substantively changed, that's a different recording under the ISRC standard and it gets its own code. An ISRC is a 12-character identifier permanently tied to one specific sound recording for its entire commercial life. The rule is really just: is this the same recording or a different one?

How ISRC reuse keeps your streams and playlist spots

When the same ISRC shows up across deliveries, Spotify's track-linking system can merge the stream counts and hold the playlist positions, as long as the title, duration, artist name, and audio file match too. For the common case of consolidating a single into an album, you put the single's original ISRC into the album upload and Spotify links the two versions and shows combined stream counts.

I want to be straight about the certainty here. Track-linking is the expected outcome when all that metadata matches, and it's how distributors describe the switch-without-losing-streams flow. But Spotify doesn't publish a guaranteed SLA for it. So treat matching metadata as the thing that makes linking likely. The more your delivery matches the original on every field, the better your odds.

What a new ISRC costs you

The reset-button pitch leaves this part out. A new ISRC is a new track to every platform. The old one's history does not come with it.

Any user-curated playlist that held the old version won't update to the new URI on its own. Listeners who had the old one saved end up with a broken or missing track. Editorial playlists that featured the original don't carry over either. From the recommendation side, both Spotify and Apple Music treat the new ISRC as a fresh release with no signals to lean on, so it competes from zero.

When re-releasing old music helps

There are real cases where putting the track back out is the right move. Managing your back catalog as an asset means knowing which of these situations you're in before you deliver.

Distributor switch. If you're leaving a distributor that will take your catalog down, re-delivering through the new distributor with the same ISRC preserves your stream history through track-linking, with the matching caveats above. Carry the code forward and you keep the lineage.

Metadata correction at the source. If a recording has a critical error like a wrong artist name or a missing ISRC that your current distributor's edit request can't fix, a re-delivery may be the only way to clean it. If the fix forces a new ISRC, it costs you the accumulated streams. Check the edit path first.

Compilation or catalog packaging. Adding old singles to a new album doesn't require re-releasing those tracks at all. You use the same ISRCs in the album upload and the existing history stays intact.

Remaster. A remastered version is a new recording, so it gets a new ISRC by the standard. Release it alongside the original master rather than replacing it, so existing listeners and the algorithm keep working off the version that already has history.

Before you re-deliver anything, confirm what ISRC each track already carries and that it's consistent across stores with the free metadata checker. →

When re-releasing old music hurts

The version that hurts is re-delivering with a new ISRC and expecting a fresh start to be free. You're trading every accumulated signal (the plays, the saves, the playlist adds) for a track the algorithms have never seen. For a song with real history, that's a bad trade.

The release date is its own trap. If you backdate it to the original release, the track won't show up as new on followers' Release Radar, so you don't even get the new-release bump you re-released for. Setting the date to today misrepresents when the recording actually came out, which can conflict with the date on your PRO and metadata records. There's no clean way to fake freshness on a recording that already exists.

The quick decision framework

Run it in this order. One: is the audio file identical to what's already live? If yes, reuse the original ISRC, carry it into the new delivery, and match the title, duration, and artist name so track-linking can hold your history. If no, you're getting a new ISRC whether you like it or not, so plan for a cold start.

Two: what are you trying to fix? A distributor move or a single-to-album consolidation is a same-ISRC job and keeps your streams. A genuine remaster or re-record is a new recording, so release it next to the original rather than replacing it. Three: never delete-and-re-upload a live track to change metadata, because that mints a new URI and breaks your placements. Submit an edit request on the live release instead, and only re-deliver when there's no edit path left.