Choose an identifier for a defined entity within an explicit namespace. Preserve source keys and maintain a reversible mapping to any replacement. Test uniqueness, reuse and relationship coverage before changing systems; a display name or apparently unique number is not sufficient evidence of enduring identity.
Specify identity before choosing a key
Decide whether the record represents a person, an organisation, an account or a contract. One organisation can legitimately hold several accounts, while one account can have many contacts. A migration that changes this grain can alter customer counts even when no customer has joined or left. Write the entity definition beside the proposed identifier, including the cases in which a new identifier should be issued.
Treat scope as part of the key. Account 407 in a billing platform need not be account 407 in a support platform. Store the source namespace alongside the local value rather than relying on a numeric prefix someone may later strip. Preserve leading zeros and case where the issuing system considers them meaningful. Names, email addresses and telephone numbers can help review identity but can change or be shared.
Create a mapping with a history
A useful mapping records the original namespace, original key, destination key, effective date and resolution reason. Include an explicit status for an unresolved candidate. If two old accounts legitimately become one organisation, retain both mappings and their separate transaction histories. If one account splits into several legal entities, specify which historical events belong where instead of allowing the current structure to rewrite the past.
Check both directions. Each old invoice should reach the intended destination account, and each destination account should have an explainable origin. Count unmatched references and destination collisions separately. A one-to-many mapping requires a dated allocation rule, not an arbitrary choice of the first match. Protect the mapping as operational data because losing it can make a technically successful import analytically unusable.
Test continuity using business events
Compare a sample of relationship chains before and after migration: customer to contract, contract to invoice, and invoice to payment. Totals alone cannot reveal payments attached to the wrong customer when equal amounts offset. Include renamed organisations, closed accounts and merged entities among the test cases. Retain the source extracts used for the check so a later dispute can be reconstructed.
Publish the identifier policy with the handover, including who can merge records and whether retired keys may ever be reused. The further reading offers data-quality background; the specification here is a proposed operational method. Passing these checks supports a particular migration decision. It does not prove every record is accurate or justify matching people solely through approximate personal details.
Check that a destination system does not silently truncate long identifiers or convert them to floating-point numbers. Include a key with leading zeros and a key longer than a typical spreadsheet preserves exactly among the handover examples.
Fictional handover: a renamed account keeps its invoices
A fictional scenario to explain the method, not a customer result or a market benchmark.
A fictional equipment supplier moves billing account LEGACY:0042 to a new platform. The account changes its name from Harbour Parts to Harbour Components. Three invoices worth 200, 350 and 450 units still carry 0042. Another source contains SUPPORT:0042 for an unrelated buyer, so removing namespaces would merge two customers accidentally.
The migration creates organisation ORG-781 and maps LEGACY:0042 to it, keeping the original three invoice references. Their total remains 1,000 units. SUPPORT:0042 maps to ORG-992 and contributes no invoices to ORG-781. Reviewers verify both the total and the invoice identifiers, then test a fourth invoice dated after the name change.
One disputed legacy contact remains unresolved rather than being absorbed through a similar name. The fictional result demonstrates continuity through a documented mapping; it is not evidence of a real migration or a universal matching threshold.
TAKE THIS INTO YOUR NEXT CONVERSATION
A practical next-step checklist.
- Define the entity represented by each key.
- Keep source namespace and original value together.
- Record merges, splits and unresolved mappings.
- Reconcile relationship chains as well as totals.
Common questions.
Can an email address serve as the permanent customer key?
It can change or be shared. Use it as an attribute unless your identity policy explicitly addresses those cases.
Should retired identifiers be deleted?
Retain their mapping and status when history depends on them; prevent reuse from attaching new events to an old entity.
Further reading & source context.
These primary references provide background. They are not evidence for the fictional example above and do not endorse Accuralytix.
Found an error or a missing qualification? Send an editorial correction.
Check my data readiness.
Use a practical tool to turn this idea into a clearer starting point.
Check my data readiness