Planning a legacy call-recording migration without losing retrieval context

Define the migration unit and the decisions that belong to its owners

Start with the retrieval requirement: which authorised person must find which interaction, through which application, and what must they be able to play or export? An archive relocation, a new retrieval interface and ingestion into a live recording platform are different projects. Storage access does not automatically register historical media in a target application's catalogue.

• Name the source and target owners, selected product/build/API versions, export/import rights, vendor support constraints and required decoder or licence dependencies.
• Inventory recording assets separately from interactions: one interaction can have multiple segments, channels, versions, redacted derivatives or related screen/chat material.
• Record source metadata/catalogue dependencies, storage locators and versions, encryption/key access, existing retrieval links and the systems that consume them.
• Obtain owner-approved data classification, purpose, permitted users, retention decisions, holds, deletion requirements and any location/processing restrictions. Unknown is not permission to copy or retain indefinitely.
• Define the inventory boundary and treatment of recordings that arrive, change, become restricted or become eligible for deletion during the work.
• Agree who accepts exceptions, retrieval evidence, cutover, rollback and source retirement. Keep these as separate decisions rather than one generic 'migration complete' flag.

This guide supplies no retention period or jurisdiction-specific legal rule. Responsible legal, privacy, security and records owners must decide which material may move and how long each copy may remain. A migration window does not suspend those obligations, and an unexplained gap must not be labelled a permitted exclusion.

Verify formats and playback dependencies, not just file extensions

A .wav extension does not establish the codec, channel meaning or player compatibility. Microsoft's RIFF overview describes chunked data and padding; the format chunk can contain different descriptors. WAVEFORMATEX separately describes format type, channel count, sample frequency, alignment and extensions, with some formats requiring WAVEFORMATEXTENSIBLE. Do not assume a fixed 44-byte header or infer the encoding from the filename. These references explain format structure, not compatibility with a particular recorder or browser. [1][2]

A concrete documentation example: Amazon Connect's current recording guide says contact IDs and recording filenames are not guaranteed always to match, and that moving a recording to another S3 bucket makes it inaccessible through that application's existing access path. It also defines different channel meanings for automated and agent interactions. Preserve source-defined associations and verify retrieval; do not generalise a channel convention or infer a universal legacy-import API from this example. [3]

If conversion is required, keep it separate from byte-preserving transfer. Record the authorised transformation, tool/version, source and derivative identities, channel mapping and quality checks. A transcoded or rewrapped derivative may legitimately have a different checksum; that does not excuse unexplained changes. Decide preservation of originals with the responsible owner rather than keeping or deleting them by default.

Use a manifest that separates identity, integrity and acceptance

The following original planning schema is fictional, incomplete by design and not a vendor import contract. Its unknown fields and approval blockers are intentional. No file exists at either locator, and the time offset is an explicitly supplied teaching value, not an inferred location. Expand the schema with the actual source/target owners before implementation.

{
  "schemaVersion": "illustrative-1",
  "tenant": "SYN-MIG-TENANT-A",
  "sourceSystem": "SYN-RECORDER-1",
  "interactionId": "SYN-INTERACTION-41",
  "recordingId": "SYN-MIG-41",
  "sourceVersion": "SYN-V1",
  "segment": 0,
  "sourceLocator": "fixture/source/41",
  "targetLocator": "fixture/target/41",
  "time": {
    "original": "2026-01-15T10:00:00+01:00",
    "normalisedUtc": "2026-01-15T09:00:00Z",
    "precision": "seconds"
  },
  "media": {
    "container": "not-tested",
    "codec": "not-tested",
    "channels": null,
    "sampleRateHz": null,
    "durationMs": null
  },
  "integrity": {
    "algorithm": "SHA-256",
    "scope": "complete authorised source/target bytes",
    "sourceHex": null,
    "targetHex": null,
    "state": "not-run"
  },
  "access": {
    "sourcePolicyRef": "SYN-SCOPE-A",
    "targetPolicyRef": "owner-input-required",
    "retrievalTest": "not-run"
  },
  "retention": {
    "decisionRef": "owner-input-required",
    "holdState": "unknown",
    "retainUntil": null
  },
  "state": "planning-only",
  "blockers": ["access-and-retention-not-approved"]
}

• Qualify source identifiers by tenant, source system and version, with segment/asset identity where required. A phone number, filename or content hash is not a unique interaction identity.
• Preserve original metadata and transformation provenance alongside the normalised search representation. Document timestamp precision, offsets and unresolved ambiguity rather than manufacturing a Z suffix.
• Define mapping cardinality explicitly. A call can have several recording assets; an intentional shared physical object must not merge logical ownership or access permissions.
• Keep transfer, checksum, metadata, permission, retrieval and owner acceptance states distinct. A matching digest cannot fill in a missing approval.
• Restrict the manifest and logs: operational locators, identifiers and hashes can be sensitive. Do not publish real manifests, bearer links, conversation content or key material.

Reconcile scoped identities and comparable bytes, not totals alone

Create a versioned inventory or other owner-approved consistent boundary before comparing source and target. Record expected inclusions, authorised exclusions, late arrivals and changed versions. Reconcile both directions: source assets without an accepted target, and target assets without an authorised source mapping. Equal object counts or total bytes can conceal substitution, duplication and missing records.

Choose an integrity contract that names the algorithm, byte representation, digest encoding and full-object versus composite scope. For byte-preserving copies, compare independently obtained source and target bytes or correctly comparable verified checksums. A copied checksum metadata field alone does not prove that target bytes were checked, and a digest is not proof of authentic provenance or permitted access.

For S3 specifically, an ETag is not a universal whole-file MD5 checksum: multipart and certain encryption paths differ. S3 distinguishes full-object and composite checksums; its documented multipart SHA-256 checksum is composite, not an ordinary SHA-256 over the concatenated file. Do not directly compare unlike digest scopes or assume an application-calculated whole-file SHA-256 is the same field. Check the actual transfer method and service contract. [4]

This small executable example is original teaching code. It hashes invented UTF-8 strings held in memory; it opens no files, calls no service and contains no audio. Its one-source-item/one-target-item assumption belongs only to this fixture. It detects duplicate mappings rather than silently selecting the first match; it is not a production migration engine or schema validator.

import { createHash } from 'node:crypto';

const identity = r => JSON.stringify([r.tenant, r.sourceSystem, r.recordingId, r.sourceVersion, r.segment]);
const digest = payload => createHash('sha256').update(Buffer.from(payload, 'utf8')).digest('hex');
const groups = rows => {
  const result = new Map();
  for (const row of rows) {
    const key = identity(row);
    result.set(key, [...(result.get(key) || []), row]);
  }
  return result;
};
function reconcile(source, target) {
  const from = groups(source), to = groups(target);
  const rows = [...from].map(([key, originals]) => {
    if (originals.length !== 1) return { identity: key, status: 'ambiguous-source' };
    const copies = to.get(key) || [];
    if (copies.length !== 1) return { identity: key, status: copies.length ? 'ambiguous-target' : 'missing-target' };
    const a = originals[0], b = copies[0];
    const sourceSha256 = digest(a.payload), targetSha256 = digest(b.payload);
    const equalSize = Buffer.byteLength(a.payload, 'utf8') === Buffer.byteLength(b.payload, 'utf8');
    return { identity: key, status: equalSize && sourceSha256 === targetSha256 ? 'bytes-match' : 'checksum-mismatch', sourceSha256, targetSha256 };
  });
  const size = rows => rows.reduce((sum, r) => sum + Buffer.byteLength(r.payload, 'utf8'), 0);
  return {
    sourceRows: source.length, sourceUnique: from.size,
    targetRows: target.length, targetUnique: to.size,
    sourceBytes: size(source), targetBytes: size(target),
    rows,
    unexpectedTargetKeys: [...to.keys()].filter(key => !from.has(key))
  };
}
const source = [
  ['SYN-MIG-TENANT-A', 'SYN-MIG-41', 'fixture bytes alpha'],
  ['SYN-MIG-TENANT-A', 'SYN-MIG-42', 'fixture bytes bravo'],
  ['SYN-MIG-TENANT-B', 'SYN-MIG-41', 'fixture bytes gamma'],
  ['SYN-MIG-TENANT-A', 'SYN-MIG-43', 'fixture bytes delta']
].map(([tenant, recordingId, payload]) => ({ tenant, sourceSystem: 'SYN-RECORDER-1', recordingId, sourceVersion: 'SYN-V1', segment: 0, payload }));
const target = [
  { ...source[0], targetRef: 'SYN-TARGET-1' },
  { ...source[1], payload: 'Fixture bytes bravo', targetRef: 'SYN-TARGET-2' },
  { ...source[3], targetRef: 'SYN-TARGET-3A' },
  { ...source[3], targetRef: 'SYN-TARGET-3B' }
];
console.log(JSON.stringify(reconcile(source, target), null, 2));

Even the bytes-match item is not accepted for cutover: this example has no validated media, approved retention, verified metadata or authorised retrieval evidence. The manifest entry and byte exercise illustrate different planning concerns; neither is a real recording nor an end-to-end tested asset.

Keep exceptions explicit and batches repeatable

Use stable item identities, attempt records and bounded retry decisions in the implementation plan. Keep failed, skipped, pending, held, copied and accepted counts distinct; do not reset a batch to 'complete' because the transfer tool exited successfully. An unexpected target is an investigation item, not an automatic deletion instruction.

An API example of why classification matters: S3 GetObject can return different missing-object errors depending on the caller's listing permission, and some archived storage classes require restoration before retrieval. A 403 is not proof that a recording never existed. Exact versions, applicable object/key permissions, range behaviour and storage class must be verified for the selected path. This guide performs no restore or API request. [5]

Test retrieval through the intended application and approved roles

Start with synthetic format-specific test files in a separately authorised environment; the text strings above are not substitutes. Any later operational sampling requires explicit permission, minimisation and handling controls. Agree risk-based coverage for relevant formats, dates, sources, segments, policy states and edge cases; a successful sample does not certify the entire archive.

Test both catalogue access and media delivery. A privileged object download bypasses much of the user's workflow; a search result alone proves no playback. S3 GetObject's documented ranged-read and archive-state behaviour is one service-specific input, not a guarantee that an application player or target archive supports the complete workflow. [5]

Define cutover evidence and a rollback that still works

1. Before transfer: agree the scoped inventory, inclusion/exclusion rules, source consistency/version boundary, access and retention decisions, acceptance owners and rollback constraints.
2. During pilot: verify approved format/API paths, mapping, byte checks, retrieval and negative permissions. Record unresolved exceptions rather than hiding them in a success percentage.
3. Before cutover: reconcile the final approved boundary and changes since the initial inventory, including late recordings, corrected metadata, new restrictions and deletion/hold decisions.
4. At the decision point: require the agreed evidence and named owner acceptance for the intended cohort. Do not substitute a generic checksum percentage, arbitrary sample size or tool exit code.
5. At switch-over: change only the approved retrieval/routing path, record the effective mapping/version and verify critical permitted and prohibited journeys. Avoid unplanned dual writes or conflicting authorities.
6. If a rollback trigger occurs: follow the approved authority and retrieval-routing plan, reconcile changes made after the switch and preserve current restrictions. Rollback must not resurrect expired access, deleted data or obsolete retention decisions.
7. After cutover: keep a bounded, owner-approved observation/recovery arrangement with clear responsibilities. Source retirement remains a separate approval.

Agree rollback triggers before the switch—for example, wrong-record retrieval, permission leakage, unreadable required formats or unbounded reconciliation discrepancies. A rollback is not credible if the source application, catalogue, licences, credentials or keys have already been removed. If source and target continue changing, document how those changes are reconciled; a routing toggle alone is not a data rollback.

Decommission only after a separate, authorised decision

Source retirement is not a cleanup step to run automatically after a successful copy. Identify which components still serve permitted retrieval, evidence, recovery, retention or hold requirements. The responsible owners must approve retirement and any deletion separately, including temporary exports, staging areas, replicas, backups, metadata catalogues and dependent indexes.

Provider-specific example: S3 Object Lock retention and legal holds apply to object versions, and a hold is independent of a retention period. Creating a new version does not mean the old protected version disappeared or that the new one inherited the same decision. A storage feature is not a legal determination, and this guide neither configures it nor recommends bypassing protection. Verify the actual owner-approved policy and transfer behaviour rather than assuming copy operations preserve every control. [6]

• Obtain documented owner acceptance of retrieval, reconciliation, exception dispositions and the planned end of the recovery arrangement.
• Recheck current retention, holds, deletion requests and other restrictions across source, target and temporary copies before any retirement action.
• Verify that catalogues, keys, licensed decoders and other dependencies needed for retained copies remain available through an approved path.
• Record the exact approved components and object/version scope; never treat an unqualified bucket, path or date range as sufficient deletion authority.
• Report blocked, partially completed and completed retirement actions accurately, retaining only the approved minimal evidence.
• Assign ongoing retrieval/access ownership and refresh the plan after material format, API, player or policy changes; recheck this guidance at least every 180 days.

Keep engineering support separate from partner product ownership

Partner platforms and their intellectual property remain with their respective owners. icommunix supports partner development as a subcontractor; the planning considerations in this guide do not imply ownership, licensing or guaranteed capabilities of a partner product. Any proprietary export format, connector, tool or platform-specific migration method needs its owner's permission and verified contract.

Partner-platform discovery is separate from discussing bespoke engineering requirements. This guide uses original synthetic examples, not partner screenshots, customer archives or a transferred case study.

• Explore partner-owned platforms and the ownership distinction →

Resources

• CX solution areas and engineering scope →
• Cloud engineering capabilities →
• Discuss interaction-data migration requirements →