How to Migrate Music Royalty Data Without Breaking Historical Statements

The eight-step migration sequence for royalty data: audit, catalog cleanup, contract mapping, sales templates, test imports, a parallel run, exception handling, and go-live — and why opening balances decide whether every future statement is right.

The first quarterly statements from the new system have gone out, and an artist manager replies within the hour: the unrecouped balance is 3,400 pounds higher than last quarter's, and nothing has changed on the deal. Your finance lead opens the old spreadsheet next to the new platform and spends the afternoon discovering that a producer advance from 2021 was imported once as a contract advance and once as an opening balance.

This is how migrations fail. Not with an error message during import, but three months later, in an email from someone who trusted you. The failure modes are predictable, though, and a properly sequenced migration catches nearly all of them before an artist sees a number. This guide walks through that sequence for label operations and finance teams leaving spreadsheets or a legacy platform.

Step 1: Data audit

Before anything is exported, inventory what you actually hold and where it lives. Most labels discover here that the "system of record" is really four things: a legacy platform, a folder of contract PDFs, a catalog spreadsheet that A&R maintains separately, and a finance workbook where the real balances are adjusted by hand every quarter.

List every data domain (contracts, payees, catalog, sales history, statements, payments, advances, reserves) and record where the authoritative copy lives, how far back it goes, and who owns it. If the legacy system holds sales lines from 2014 but the earliest statement you can reproduce is from 2018, note that gap now, because it determines how much history you migrate as line-level data and how much you carry in as balances. Most labels land on a hybrid: line-level sales for the last two or three years, opening balances and archived PDF statements before that.

Step 2: Catalog cleanup

Every sales line in the new system has to match an asset, so catalog quality sets the ceiling on ingestion quality. Export your recordings, works, and products, and run three checks: duplicate ISRCs, missing ISRCs, and ISRC-to-UPC links that do not exist.

Duplicates are the expensive one. A track that exists twice, once as "Northern Line" and once as "Northern Line (Radio Edit)" with the same ISRC, will pay the contract attached to whichever record the matching logic found first. Merge them before export, and record every merge in a mapping file (old ID, new ID, reason) so a historical statement line can be traced back to the record it originally hit.

DSPs send the titles they have, not the titles you have, so any variant a recording was ever delivered under needs storing as an alias on the surviving record. Standardise territory codes to ISO 3166, currency codes to ISO 4217, and release dates to a single format, because all of this is cheaper in a spreadsheet now than in a quarantine queue later.

Step 3: Contract mapping

Contract mapping is where knowledge that lives in one person's head becomes configuration a system can execute. For each agreement, document the payee, the assets covered, the rate structure, the revenue base (gross, net of distribution fee, net of a fixed deduction), recoupable items, cross-collateralisation between releases, reserves and their release schedules, and the effective date of every rate change.

Then map each element to its equivalent in the target system. Where the old system approximated a term (a producer share paid "off the top" that was actually configured as a reduced artist rate), decide whether to reproduce the approximation or model the term correctly going forward, and write the decision down. Both choices are legitimate. Silent choices are not.

The output is a contract mapping sheet, one row per contract, with the source terms, the target configuration, and a sign-off column. Your finance lead signs it. Do not import until that column is full.

Step 4: Sales-template setup

Every revenue source needs an ingestion template before historical sales can be loaded. Take one real file per source per format version: the DSP report from 2022 probably does not have the same columns as the one from 2025, and each variant needs its own mapping.

For each template, confirm the mapping of ISRC, UPC, territory, currency, units, gross and net amounts, and period date. Check how the source represents refunds and negative units, whether amounts are already net of the distributor's fee, and which exchange-rate date the file assumes. Then load one file and reconcile the ingested total against the source's stated total; a template off by 0.3 percent on a test file will be off by thousands across four years of history.

Step 5: Test imports

Run imports into an isolated test environment, not production, in dependency order: payees, catalog, contracts, sales, then balances. Each stage has a validation gate. Row counts in equal row counts out. Every sales line matches an asset or is quarantined with a reason. Every asset carrying revenue has an active contract for the period.

Keep an exceptions log from the first test import onward, recording each fix and whether it was applied to the source data or the mapping. Expect three or four full passes: the first finds template problems, the second catalog problems, the third contract problems.

Step 6: Shadow reconciliation (parallel run)

A parallel run is the only test that proves the migration is correct. Keep the old process running for at least one full statement period, ideally two, and produce that period's statements in both systems from the same source files.

Totals per payee should agree to the penny. Where they do not, compare per contract and per source, then per line. Every difference is a data problem (missing sales lines, a wrong alias), a configuration problem (a rate or deduction mapped incorrectly), or a legitimate calculation difference where the new system is right and the old one was wrong. That third category exists in almost every migration.

Opening balances deserve the most scrutiny here, because they are the one input that touches every future period. An opening balance is the unrecouped position, reserve held, or credit carried forward for each contract at the cut-over date. If a balance is imported 1,200 pounds too high, that payee recoups 1,200 pounds later than they should, and every statement from cut-over until the deal recoups is wrong, silently, until someone audits. If it is too low, you overpay, and clawing it back is a conversation nobody enjoys.

Build each balance per contract, not per payee, from the last finalised statement in the old process. Reconcile the sum of contract balances to the payee's ledger total and attach the source statement as evidence. Then have someone who did not prepare the balances check at least 20, weighted toward the largest unrecouped positions and any cross-collateralised contract.

Step 7: Exception handling

By this point the exceptions log has three kinds of entries, and each needs an owner and a rule.

Quarantined sales lines are usually resolved by adding an alias or correcting a catalog record, then re-running the import. A small residue will be revenue for assets you no longer control or lines with no identifier at all. Decide whether these go to a suspense account, are written off, or are held, and record the total.

Configuration mismatches go back to the contract mapping sheet, get corrected, and the affected contracts are signed off again.

Legitimate calculation differences are the sensitive ones. If the new system applies an escalator correctly where the old spreadsheet never did, an artist we will call Mara Vell may be owed money for prior periods. You can reproduce the old calculation for history and apply the correct one from cut-over, or issue a retroactive adjustment with a clear paper trail. Either way, the plan must state the choice, and any adjustment must be visible on a statement rather than absorbed into an opening balance.

Step 8: Go-live

Go-live is a cut-over date and a freeze. From that date, nothing is loaded or edited in the old system, and the final opening balances are locked and signed off. Import any sales that arrived between the parallel run and the freeze, reconcile totals once more, and archive the old system's final statements as PDFs with the mapping files.

Then produce the first live period with the old process still available, read-only, and keep the exceptions log open. The first live run will surface a handful of items nobody caught, and the difference between a calm go-live and a chaotic one is whether there is a process for them.

Migration checklist

Audit

• Inventory every data domain, its authoritative source, date range, and owner
• Record row counts and identify gaps in sales or statement history
• Choose a history strategy: full reprocessing, summarised totals, or balances plus PDF archive

Cleanup and mapping

• Resolve duplicate and missing ISRCs, UPCs, and ISWCs, with a merge mapping file
• Store title and credit variants as aliases; standardise territory, currency, and date formats
• Complete the contract mapping sheet with finance sign-off on every row
• Build and reconcile an ingestion template for every source and every format version

Test and reconcile

• Import to a test environment in dependency order with validation gates
• Maintain an exceptions log with fix, owner, and status
• Run at least one full parallel period and reconcile at payee, contract, and line level
• Build opening balances per contract, reconcile to payee totals, attach evidence, and check a weighted sample independently

Go-live

• Freeze the old system on the cut-over date
• Load and reconcile final sales, lock balances, and archive old statements
• Keep the old process read-only for one cycle and the exceptions log open

Common failure modes

Inconsistent metadata

The most common source of parallel-run differences is metadata that meant one thing in the old system and another in the new. A territory field that mixed "UK", "GB", and "United Kingdom" will match in a hand-maintained spreadsheet lookup and fail in a system that expects ISO codes. A version suffix the old process ignored becomes a separate asset in the new one. The fix is always the same: standardise at source, and treat every quarantined line as a defect to correct on the record, not override on the line.

Incomplete contracts

Legacy processes tolerate missing contract data because a person fills the gap from memory. A rate with no effective date, a deduction with no revenue base, an advance with no recoupment scope. The new system cannot fill those gaps; it will refuse the contract or apply a default that is wrong. The mapping sheet exists to force those questions early, when the answer is a conversation, rather than late, when the answer is an adjustment.

Data drift between systems

Migrations take weeks, and the business does not stop. Sales files keep arriving, contracts get amended, and a payee changes bank details. If those changes land only in the old system after the extract was taken, the new system goes live with stale data and the first statements are wrong for reasons unrelated to the migration logic. Set a formal change-control window: after the extract date, every change to the old system is logged and replayed into the new one, and after the freeze date, no changes are made to the old system at all. The final reconciliation should explicitly cover the drift log.

Opening balances treated as a formality

Teams that have spent weeks on catalog and contracts sometimes carry balances across in an afternoon, from a summary tab, at payee level. Cross-collateralisation then behaves differently from the old process, and the first statement is wrong in a way that is hard to unpick because there is no line-level history behind it.

Scope the migration before you sign for it

Qlero is built for labels, distributors, and royalty administrators moving off spreadsheets and legacy platforms, and its onboarding is designed around the sequence above — a parallel period and signed-off opening balances before anything goes live.

Book a demo at qlero.io/book and bring your contract list, a sample of sales files, and your last finalised statement run. We will map out what needs to move, where the risks sit in your data, and what a realistic timeline looks like for a catalog your size.