Before migrating an internet radio station, measure these seven things

Moving an internet radio station involves more than copying audio files. The station has programming rules, presenters, public links, directory listings, embeds, credentials and listener expectations.

The safest migration begins by measuring the current station before changing it.

1. Media inventory

Record:

number of audio files;
total storage;
formats and bitrates;
missing or inconsistent artist and title metadata;
artwork availability;
explicit or clean classifications;
tags used in programming;
duplicate files;
tracks that cannot legally be moved.

Do not assume that a successful upload means the media is ready for automation. The new platform may need to analyse duration, loudness, cue points or format compatibility before a track becomes schedulable.

Keep the original library unchanged until the imported set has been counted and sampled.

2. Programming model

Document how the station decides what plays:

weekly programmes;
one-off events;
playlists attached to time slots;
rotations;
separation rules;
request handling;
timed announcements;
fallback programming;
timezone and daylight-saving behaviour.

A screenshot of the current schedule is useful evidence, but it is not a machine-readable migration plan. Export structured data where the existing provider allows it and write down rules that live only in an operator’s memory.

Measure an ordinary week and any special-event patterns separately.

3. Live contribution

List every presenter or studio that connects live:

encoder software or hardware;
codec and bitrate;
source hostname and port;
mount or station identifier;
authentication method;
expected handover time;
fallback behaviour after disconnect;
people responsible for each show.

Test at least one real presenter from the network they normally use. A source connection verified from the station owner’s office does not prove that a remote host’s setup is ready.

Plan credential distribution carefully. Do not send secrets through the public migration document.

4. Listener entry points

Listeners may reach the station through:

the station website;
an embedded player;
a direct stream URL;
a directory;
a mobile application;
a smart speaker;
social profiles;
links saved in third-party players.

Create a list of every known public URL and who controls it. Some can be redirected. Some require an update in another platform. Some cannot be changed after publication.

Use analytics and referral data to prioritise the paths that carry real listeners.

5. Metadata and artwork

Confirm how current-track information reaches:

the web player;
embeds;
directory listings;
third-party clients;
history and reporting.

Test special characters, long titles, missing artwork and live shows without track metadata. A stream can sound correct while the listener experience displays stale or malformed information.

6. Team access and operating responsibility

Map people to jobs before creating accounts:

owner;
administrator;
station manager;
programmer;
presenter;
read-only observer.

Apply the narrowest role that supports the work. Avoid sharing one owner login among several people. Record who can publish schedules, rotate live credentials, manage billing and approve permanent deletion.

The migration also needs a named cutover lead and a named rollback decision-maker.

7. Baseline and acceptance criteria

Write down what “working” means before switching traffic.

Example acceptance criteria:

the complete media count reconciles;
selected files play and report correct metadata;
the next seven days contain no unexplained schedule gaps;
AutoDJ remains continuous for a defined rehearsal period;
external live source connects and returns cleanly to automation;
priority listener URLs return playable audio;
MP3 and AAC paths pass on representative devices;
public pages and embeds display the expected station identity;
operators can see and understand the current source;
rollback can be performed within the agreed window.

The criteria should be observable. “Looks good” is difficult to use during a pressured cutover.

Run both services in parallel

Do not cancel the existing provider before the new station is prepared and tested.

A controlled sequence is:

Inventory the old service.
Import and reconcile media.
rebuild programming.
rehearse AutoDJ and live shows privately;
verify players, metadata and public endpoints;
lower DNS time-to-live where relevant;
select a low-risk cutover window;
update listener entry points;
monitor both station and audience signals;
retain the old service through the agreed rollback period.

Parallel operation costs more for a short period. It is usually cheaper than attempting recovery after the old service and credentials have already been removed.

Keep a cutover ledger

During the change, record:

timestamp;
action;
person responsible;
observed result;
link or identifier checked;
decision to continue or roll back.

This prevents repeated checks and gives the team a shared view of progress. It also turns the migration into a reusable procedure for future stations.

Know what should not move

A migration is a chance to leave behind:

unused accounts;
expired credentials;
duplicate media;
abandoned embeds;
obsolete directory links;
schedule rules nobody can explain;
claims or artwork the station no longer has permission to use.

Preserving every historical mistake is not fidelity.

The readiness decision

A station is ready to migrate when the new platform has proven the programme, contribution and listener paths—not merely when the files exist.

Keep the old provider active, define rollback in advance and change public traffic only after the acceptance criteria pass.