Insights · Migration
Contact centre migrations are planned around the calls you are going to take. The calls you have already taken get three lines in the project plan and then become the reason the old platform is still running eighteen months later, still licensed, still patched, still costing money, because nobody can decommission the only thing that can read the archive. Here's how to deal with the recordings properly.
Everything else in a platform migration is forward-looking. Numbers port, flows get rebuilt, agents get retrained, and on cutover day the new platform starts accumulating its own history. Recordings are the one asset that only points backwards — and the one you are legally least free to abandon.
Three properties make them awkward.
Retention outlives the platform. Australian financial services, health and government obligations commonly run to seven years or more, and complaint or dispute matters can extend well past that. Nobody buys a contact centre platform on a seven-year commitment, so at some point every archive outlives the system that created it. That is normal; being unprepared for it is the problem.
The audio and the meaning are stored separately. The media files are one thing. What makes a recording findable — who the agent was, which queue it came through, when it happened, what it was about — lives in a database, in the platform's own schema. Copying the audio directory to a file share is not a migration; it's an unindexed pile of files with machine-generated names.
Formats are proprietary. Recording platforms have historically stored audio in vendor-specific containers or codecs, sometimes encrypted, sometimes with the screen recording bound to the audio. All of that has to be converted to something open, or you have simply moved the dependency to new storage.
There's a commercial dimension too: the leverage in a renewal negotiation changes entirely once your archive is independent of the platform. Doing the migration early is worth more than doing it cheaply.
This is the checklist to agree before anyone extracts a single file, because re-deriving metadata after the fact is usually impossible.
Also confirm what has already been deleted or redacted under existing policy, and preserve the fact of the deletion. An archive that silently loses its own tombstones cannot answer a "what did you have and when" question.
There are three realistic destinations, and the right one depends on what the recordings are for.
Object storage with an index. Amazon S3 or Azure Blob, holding open-format audio, with the metadata in a searchable index alongside. This is the most common answer and usually the best one for a historical archive: storage is cheap, lifecycle rules can enforce retention automatically, encryption is under your own keys, and there is no per-seat licence attached to a set of files nobody records against any more.
Alongside the new platform's own store. If you are moving to Amazon Connect, its recordings are written into an S3 bucket in your own AWS account, so putting the historical archive in the same account — separate prefix, its own lifecycle policy — keeps one storage story and one access model. Be clear-eyed about what this does and does not give you: the new platform's contact records won't retrospectively acquire calls it never handled, so historical audio is accessed through the archive's own search rather than through the platform's contact history.
Import into the new platform where it genuinely supports it. Some platforms accept externally-created recordings. Where that path exists it gives a single pane of glass, and it comes with the same lock-in you are currently escaping. Ask what happens to imported media when you leave.
If the destination contact centre platform is still open, decide it before the archive design rather than after — the trade-offs are in Amazon Connect vs NICE CXone vs Genesys. ProUCX migrates Verint recordings to Amazon Connect, Genesys, NICE CXone, Amazon S3 and Azure Blob, converting proprietary formats to open standards on the way — the detail is on the Verint call recording migration page.
A migrated archive still has to behave like a compliance system, which means four things have to survive the move.
Retention has to keep enforcing itself. Map each source retention class onto a storage lifecycle policy so recordings expire on schedule without anyone running a script. Retention that depends on a person remembering is not retention.
Legal hold has to override it. Anything under hold must be exempt from lifecycle deletion, and the hold itself must be auditable — who applied it, when, and under what matter reference. Object-lock style controls are the usual mechanism.
Access has to be controlled and logged. Recordings contain personal information and often payment details. Role-based access, and an audit log of who listened to what and when, is not optional — in a dispute, the access log is frequently as important as the recording.
Someone has to own it. Once the source platform is gone, the archive needs a named owner in the business, a documented process for subject-access and discovery requests, and a tested restore. Test the retrieval path at least once a year, in front of someone who will have to do it under pressure.
An archive nobody can search is an archive nobody can defend. Three practical measures.
Index the metadata, not the filenames. Search by agent, number, date range, queue and interaction ID. Anyone who has tried to find one call in six years of directory listings understands why.
Use open formats. Standard audio containers that any tool can play in ten years' time, and a plain, documented schema for the metadata — CSV or JSON beside the media, not a proprietary database.
Give people a viewer. The realistic users are a QA lead, a complaints officer and a legal team, none of whom will use a storage console. A web viewer with search, playback, role-based access and audit logging turns the archive back into something usable — which is exactly why a migration project should include one rather than treating it as a nice-to-have.
Optionally, transcribe on the way through. Once audio is in open format and in your own cloud account, running speech-to-text over the archive makes it text-searchable and dramatically cheaper to investigate. It's a decision to make deliberately, though: a transcript is a new record, discoverable in its own right, and it needs its own retention treatment.
The most common mistake is running steps 4 and 7 close together because a contract date is looming. The archive is the one part of a migration where being three months late is far cheaper than being wrong.
The recordings, not the routing, are what keeps an old platform alive. Preserve the metadata as carefully as the audio, convert to open formats, move to storage you control with retention and legal hold enforced by policy, keep it searchable through a viewer real people will use, and reconcile before you decommission anything.
See how the migration works, or tell us about your estate and target platform and we'll scope it.