The sales receipt is the visible part of a checkout. Behind it sit products, prices, tax rules, tender types, staff permissions and a history of changes. Move the till without understanding those relationships and the difficult questions follow you into the new system.
In my retail POS data work, I separate information by how it behaves. A product master changes differently from a live payment authorisation. A reason code is not a sales transaction. An archived return still needs an owner even though it no longer appears on today's screen.
This article develops that classification approach. It does not describe a completed client migration or offer a compliance checklist. The examples are illustrative. The detailed decisions belong with the people who own the store, back office, central systems and integration work. The public value is in making those decisions visible before the first store switches over.
Begin with the questions a store must answer
A migration plan can start with tables and interfaces because those are easy to list. I would start with the questions the store needs to answer through them. Can the colleague identify the product, apply the right price, complete the permitted transaction and explain what happened afterwards?
Those questions connect data to an operational purpose. They also reveal why a copied record is not automatically a usable record. The new system may receive a field without receiving the meaning, timing or rule that makes the field useful.
Consider an illustrative return. The original transaction may belong to an earlier system, while the current colleague uses a new checkout. The team must decide what evidence is required, where that evidence can be found and who owns the exception when it is incomplete. Moving today's sales tables does not settle that journey.
I would select a few representative tasks and trace their information needs across systems. A sale, a return, an interrupted transaction and a price query can expose different dependencies. The map should explain the decision each record supports, rather than merely prove that a field has a destination.
Use classification to organise the conversation
My data matrix distinguishes foundation, master, transaction, reference, metadata, historical, operational, analytical and other forms of information. These are lenses for discussing responsibilities. They should not become rigid boxes that conceal how the data is actually used.
A record can be structured and real-time. It can contain personal information and also support analytics. The categories help identify different questions, but they do not remove the need to inspect the particular record and workflow.
For example, classifying a product record as master data suggests a conversation about maintenance and distribution. Classifying a payment event as transaction data suggests a conversation about correctness, timing and reconciliation. Both may depend on the same identifiers, but they do not have the same lifecycle.
I would use the matrix as a workshop aid. Ask the owners to challenge it with examples from the proposed scope. Where does the classification help? Where does it need a more specific definition? The goal is shared understanding, not compliance with a taxonomy that looks tidy in a document.
Foundation data makes small assumptions visible
The source matrix includes countries, currencies, languages, calendars, time zones and units of measure as foundation information. These can look static enough to ignore. Yet the interpretation of another record may depend on them.
An illustrative quantity is not meaningful until the relevant unit is understood. A scheduled event is not fully specified until its time context is clear. A display format is not the same as the underlying value. A migration should not rely on people remembering these distinctions informally.
I would ask where each foundation definition is maintained and how the new system uses it. Which definitions are shared? Which differ by location or use? What happens when a value is missing or no longer supported? The answers help prevent a technically valid import from producing a misleading interpretation.
This is not a claim that every migration has a unit or time-zone failure. It is a way to find an inexpensive assumption before it becomes an expensive correction. The small definitions deserve review because they support much larger transactions.
Master data needs more than an import date
The matrix places products, identifiers, stores, terminals, people, prices and taxes among master-data examples. I would not treat that list as proof that all those records share one owner or change through one process.
The useful questions are who can change the record, which source is authoritative and where the changed value must appear. A one-time import can establish an opening state. It does not establish how the state will remain correct after the migration.
In an illustrative product update, the central record changes while the new store system still holds an earlier value. The team needs to understand whether the difference is an expected timing state, a distribution failure or an unresolved ownership conflict. Calling both copies master data does not decide which one should govern the next action.
I would map the maintenance journey for the records that matter to the selected tasks. Where is a change proposed? Who approves it? How is it distributed? What confirms the destination received it? Migration readiness includes those continuing responsibilities, not just the initial load.
Transaction data must preserve meaning
Transactions record what happened. The source matrix includes sales, voids, returns, payments, discounts and other events. A migration needs to preserve the meaning of those events, not simply their visible totals.
An illustrative void and a return may both reduce an amount in a report while representing different actions. If the new system flattens those distinctions, a later reviewer may struggle to explain the activity. The team needs to agree which event relationships and statuses remain important.
I would examine complete examples. What happened before the final receipt? Which parts were completed, interrupted or reversed? Which record is the basis for reconciliation? A final number can hide a sequence that matters to support, reporting or an operational exception.
The details of payment handling and sensitive information need their own qualified owners. This article does not prescribe a payment-data transfer method or claim that a generic classification makes a migration compliant. It identifies the boundary: transaction correctness and data protection cannot be inferred from a successful import message.
Reference data carries decisions in small codes
Reason codes, tender types, customer types, store types, roles and business rules appear in the matrix as reference information. Small codes can seem easy to map. Their meaning may nevertheless influence what action the system permits and how a later person interprets it.
I would avoid matching codes by label alone. Two systems can use similar words while applying different conditions. Conversely, different labels can represent the same agreed concept. The mapping should capture the intended meaning and have an owner who can approve it.
For an illustrative exception reason, ask what choosing it allows, which record it creates and who reviews its use. If those behaviours differ between systems, copying the label will not preserve the workflow. The team must decide whether to change the workflow or change the mapping.
This work can feel less visible than a new checkout screen. It is still product work. A colleague's ability to take the right action depends on those definitions, and a manager's ability to understand the action later depends on them too.
Metadata deserves an owner
The matrix includes schemas, APIs, field mappings, workflows, report templates and audit logs under metadata. I would use that lens to ask how the migration itself remains understandable. Someone needs to know what a field means and which transformation produced the current value.
A mapping document can become stale as the design changes. A report template can use a field differently from the operational interface. An integration can preserve the expected shape while altering an interpretation. Those are reasons to maintain the mapping as a reviewed part of the product, not an attachment that is finished once.
I would identify who approves a mapping change and how its effect is checked against representative tasks. If a transformation is necessary, record its purpose and limitations. A later investigation should not depend on finding the person who remembers why a value was handled that way.
The same principle applies to migration evidence. Keep the result of the checks that matter, along with the scope they covered. Evidence from one test should not be stretched into assurance about a different population or a later version.
Historical data is still operationally relevant
Archived records may be absent from today's main screen while remaining important for returns, support, investigations or analysis. The source matrix lists sales histories, return logs, price histories, attendance and inventory movements among examples.
I would decide the use before deciding the destination. Which historical questions must the new system answer directly? Which can be answered through a separate access route? Who can use that route, and what happens if the record is incomplete? Keeping every record in the same place is not the only possible design, but losing the ability to answer the agreed questions is not acceptable.
An illustrative earlier transaction might be retained elsewhere rather than imported into the new checkout. That can be a deliberate choice if the access and exception workflow are clear. It is a gap if the team discovers the choice only when a colleague needs the record.
Retention and access decisions also need current organisational requirements. The matrix's sensitivity labels are a prompt for review, not a substitute for determining what information the records actually contain and what rules apply to it.
Live operational state needs a timing model
The source notes distinguish live inventory, POS status, open tickets, on-duty staff and other operational information. These records can change while a migration task is being performed. The team needs to agree which state is being transferred and what happens to subsequent changes.
I would make timing and reconciliation explicit in the plan. What is the reference moment? Which activity continues elsewhere? How will the team identify a difference caused by timing rather than by an incorrect value? The exact mechanics vary, but the decision should not remain implicit.
An illustrative open task may have started before the switch and finish afterwards. The team needs to know which system owns its completion and which records prove the result. A record that exists in both systems can create ambiguity unless that ownership is clear.
The important product question is what the colleague should experience during the transition. A correct backend plan can still be confusing if the interface does not explain which actions are available and where an unresolved case belongs.
Analytics should not redefine the transaction
Analytical data includes measures such as sales indicators, basket size, promotion performance and stock ageing in the matrix. I would separate those derived views from the events and definitions they depend on.
A migration may change a report because the calculation, source coverage or timing changed, even when the underlying operational activity is similar. The team should understand those differences before treating a new number as a business change.
I would review a few important reports alongside their definitions and source records. What population is included? What is excluded? Which statuses count? What period does the measure represent? A matching report title does not establish a matching calculation.
The same care applies to trend continuity. If the new system changes how an event is represented, the team may need an explicit note or reconciliation before comparing periods. The purpose is to preserve honest interpretation, not force every new report to look numerically identical regardless of meaning.
Data shape does not settle sensitivity
The matrix also discusses structured, semi-structured, unstructured, external and behavioural information. I would use those lenses to find data that might otherwise be missed. An attachment, log or feedback record can carry important information even if it is not part of the main transaction schema.
Its format does not determine whether it is sensitive. A tidy table can contain personal information. An image or free-text note can contain confidential material. The team needs to inspect the content and its intended use rather than rely on a broad category label.
I would ask who needs access, for what purpose and through which approved route. The migration should not widen the audience just because a new tool makes sharing easier. Access that was narrow in the old system needs an explicit review before it becomes broad in the new one.
External or behavioural signals also need provenance and context. They should not quietly become transaction facts. A suggested interpretation can help a person ask a question; it does not automatically belong in the official record of what happened at checkout.
Make ownership a practical map
A useful ownership map should name decisions, not just departments. “IT owns the data” is too broad to tell a colleague who can resolve a disputed product value or approve a transaction mapping.
I would distinguish the person responsible for the business meaning, the source system, the receiving workflow and the technical movement. Those responsibilities may overlap, but they should not be assumed to overlap. An integration owner can deliver a value without being authorised to decide that the value is correct.
For each critical information journey, ask who can approve the definition, who keeps it current and who resolves an exception. Record the route in a form the project can use. The aim is to shorten the distance between finding a problem and reaching someone who can decide it.
This map should be tested through examples. Give the team a plausible mismatch and ask where it goes. If everyone points to a different owner, the document is not yet doing its job. Resolving that disagreement before migration is often more useful than adding another status meeting.
Define readiness and recovery together
A migration plan needs a clear account of what would make the scope ready and what would make the team pause. I would connect those conditions to the selected tasks and their evidence, rather than rely on a general statement that testing is complete.
Which records were checked? Which exceptions remain? Can store colleagues complete the agreed journeys? Are the owners available to resolve an unexpected case? The result should make the remaining uncertainty visible to the people making the decision.
Recovery also needs its own review. What can be restored, what must be reconciled and which actions cannot simply be replayed? This article does not offer a generic rollback procedure. It argues that recovery is part of the decision to migrate, not something to invent after the first problem.
A smaller scope may be the right outcome if the evidence is not strong enough. Readiness is not a reward for reaching the planned date. It is a judgement about whether the organisation can operate and support the agreed change without leaving people to guess.
The migration conversation I want to have
Before discussing the first store switch, I would bring the data matrix, a few representative tasks and the unresolved ownership questions into the same conversation. The team should see how a product definition, a transaction event, a reason code and a historical record meet in one colleague's work.
That changes the question from “Can we move this table?” to “Can the right person make and explain the right decision after the move?” It gives technical planning a more dependable business frame without pretending that product reasoning replaces implementation detail.
This is a data-classification perspective, not a claim of a completed migration or guaranteed compliance. I can help a retail team pressure-test the definitions, lifecycles and owners before the new till becomes the place where those unresolved questions surface. The receipt may be the visible output. The ownership decisions underneath it determine whether the output can be trusted.
Related reading: Between scan and settlement: the checkout plumbing nobody sees.