Leading zeros can look like an inconvenience when a technology team wants to bring several systems into a common representation. Removing them makes a field easier to treat as a number, and numbers are familiar things for software to compare. That convenience says nothing about whether the field is a quantity. In our 2019 migration rehearsal, customer article identifiers were labels whose exact form carried a distinction. I had approved treating them as numeric keys. The conversion did not merely tidy the source. It made different identities appear to be the same.
The source contained 1,240 text identifiers. After conversion, the new representation contained 1,192 unique keys. Forty-eight pairs collided, affecting 96 source identifiers; 1,144 others were unaffected by that pattern. The difference was small enough to invite a reassuring summary about the proportion that had transferred correctly. That would have missed the point. Identity is the basis on which later records are attached. A high percentage of unchanged values does not make the collapsed pairs acceptable, and the operating meaning of those pairs cannot be decided by the convenience of the receiving table.
Ask what makes two records different
My first question should have been how the source owners distinguished one article record from another. Instead, I accepted a technical representation before that convention had been made explicit. The mistake was not that numeric fields are inherently unsuitable for every identifier. It was that we had not established that this conversion preserved the identity used by this business. A string of digits may look like a number while functioning as a label. Arithmetic equivalence is then a different question from whether two source records refer to the same thing. The migration needed to respect the second question.
Operating colleagues demonstrated that the paired values belonged to distinct records. They were not asking IT to preserve an arbitrary preference simply because the old screen displayed it. They were explaining the distinction on which their records depended. That explanation changed the nature of the task. We needed a mapping that retained the original text identity and associated information, rather than a cleansing exercise that forced the source into our chosen type. The business convention still needed to be documented and tested, but it could not be removed merely because the new system found another form easier to handle.
I also needed to distinguish a collision from every other kind of migration issue. A missing value, an invalid character and two distinct values collapsed into one may all appear in a broad exception count, yet they require different decisions. If management receives only the percentage transferred, it can approve progress without understanding what kind of information was lost. The case made me more interested in the consequence of an exception than its share of the population. A few identity collisions can matter differently from many cosmetic differences, and the review should make that difference intelligible to the people deciding whether to proceed.
A rehearsal can reveal a design error rather than dirty data
I initially asked whether the source needed cleaning. That response placed the burden on operating colleagues before I had examined my own assumption. It is a familiar temptation in system replacement: the new model is treated as the desired truth, and anything that does not fit becomes a legacy defect. Sometimes the source does need correction. In this case, the source preserved a meaningful distinction and the new representation removed it. Recognising that reversed the work. We stopped before production cutover, retained the text identifiers and rebuilt the mapping rather than ask users to make distinct articles conform to a simpler key.
The rehearsal therefore did valuable work, but I do not describe it as an uncomplicated success. The programme required six additional weeks and ₹36 lakh of rework. Colleagues had to revisit implementation and testing, and the operating teams continued using existing systems longer than planned. The flawed mapping had not reached production, so the case does not invent a hospital incident. Equally, the absence of that incident does not erase the cost of the decision. A credible technology account can recognise the value of catching an error while retaining the responsibility for having approved the assumption that caused it.
The revised mapping needed more than a corrected sample. We repeated collision checks on the programme's identifier set and retained the source representation. That established the correction within the reviewed scope. It did not make every later integration safe by implication. Other systems may use different conventions, and an apparently similar field can have a different purpose. The useful change in leadership was to require the identity question before approving a transformation, with source owners able to explain what must survive. It was not to turn one technical fix into a universal rule that every digit string must always be stored in one particular way.
Keep the consequence with the person who approved the assumption
The development team had implemented the design I approved. Blaming the implementation would have made the account easier for me and less accurate for everyone else. I wanted colleagues to see that challenging a senior decision in a rehearsal was legitimate and that the response would follow the evidence. That does not remove the team's responsibility to raise concerns, but it keeps accountability proportionate. The manager who signs off a simplification should be willing to explain which meaning was assumed to survive and to reopen the decision when the test shows otherwise.
For a board, the relevant questions are about how management knows a migration preserves the business record and how exceptions affect the decision to proceed. Directors need not choose a database type or inspect every identifier. They can ask which distinctions the business relies on, how those distinctions were tested and whether the reported success rate conceals a more serious class of error. They can also ask who owns the unresolved judgement. A programme should not advance merely because an exception has been assigned a technical ticket number if the underlying identity question remains unanswered.
The zero in our case was ordinary, visible and easy to discard. Its importance came from the relationship it preserved, not from its size or mathematical value. That is why the story belongs in my leadership profile. I approved a convenient representation, operating colleagues showed what it removed, and we paid to correct the programme before cutover. The lesson is a habit of enquiry: understand what makes two records different before deciding how much of their form can be simplified. A cleaner table is useful only if it still describes the business it was built to serve.