The field that cannot explain the offer
When a subscription platform asks for a product code, it is asking the enterprise to make a statement about an existing promise. The technical question looks small: which value should appear in the destination field? The commercial question can be much larger. A reader may have purchased a bundle under an earlier offer, received a complimentary period or retained access through an arrangement the current product catalogue no longer describes. The need to complete a migration does not settle what those terms meant.
I learnt this distinction before common digital accounts became a routine part of publishing. Subscriber-service colleagues could explain why two records that looked similar belonged to different histories. One was a paid edition, another a combined offer and another a temporary arrangement with a particular end point. Technology needed a usable representation, but the business first needed to decide what it was representing. If the sequence was reversed, the field's limitations could quietly become the reason for a commercial decision nobody had consciously approved.
Our review of 72,000 legacy entitlements made that problem concrete. Sixty-six thousand mapped to an explicit meaning. Six thousand needed interpretation, including four thousand earlier bundles and two thousand complimentary arrangements. Those categories did not imply that every record was wrong. They identified where the proposed mapping lacked enough support. A neat destination table could have hidden the difference by placing all six thousand into a convenient current category, leaving the reader or service colleague to discover the mismatch later.
The case for a standard mapping was not frivolous. A migration has a timetable, ongoing costs and people waiting for capabilities the new service is meant to provide. Maintaining special handling can prolong complexity and make the new platform harder to operate. The sponsor wanted to move the estate forward and correct individual problems through normal support. I understood the attraction, but it depended on treating the unresolved promise as a small downstream inconvenience rather than a decision that should inform the conversion itself.
The cost of keeping an unresolved promise visible
I supported an eight-week examination costing AUD1.8 million. Commercial owners interpreted the source arrangements, customer-service colleagues helped describe the likely reader question and technology made the accepted mapping traceable. Existing access continued under agreed commercial authority during the review. That was an explicit operating decision, not a technical team's independent grant of new rights. The distinction mattered because the migration team could not acquire authority over subscription terms merely by being responsible for the application change.
Four thousand five hundred of the disputed entries acquired a confirmed mapping. The remaining 1,500 retained an assisted route and an owner for the unresolved question. Our account therefore contained 70,500 mapped entitlements and 1,500 exceptions. It would have been easier to describe the programme as almost complete and move the residual group into a footnote. I preferred to state what the service still needed to do for those entries, because the remaining work was part of the obligation we were carrying into the new arrangement.
An assisted route is not automatically a satisfactory long-term answer. It needs capacity, a clear explanation and a way to reach a decision. Otherwise the enterprise merely moves uncertainty from a database into a queue. I ask who can resolve the underlying interpretation, what evidence they need and what happens if the original material cannot be found. Those are management questions that a programme should expose. The fact that a person can answer a telephone does not by itself make the unresolved entitlement manageable.
I also resist expanding the meaning of the migration figures. The 72,000 entries were entitlements, not necessarily 72,000 people. A reader could hold several subscriptions, and a single account could support more than one publication. The review did not prove an improvement in retention, revenue or audience reach. It established a disposition for a defined set of records. Those commercial outcomes might be examined later, but they would need their own evidence rather than being inferred from the number of rows assigned a confirmed destination.
Common access does not require identical meaning
A shared sign-in can still be valuable. It can make access easier, reduce repeated administration and give colleagues a clearer account of a reader relationship. My objection is not to common infrastructure. It is to the assumption that common access requires every underlying promise to be identical. A system can support several product meanings if the enterprise has taken the trouble to define them. The design question is how to preserve necessary distinctions without turning every historical variation into an indefinite exception that nobody understands.
That requires a conversation about which differences remain material. Some may be superseded through an appropriate commercial process. Others may expire according to their original terms. Some may need a carefully agreed replacement. Technology should help implement those decisions and retain the explanation that supports them. It should not make the choices indirectly through a default value whose convenience obscures its effect. I want the commercial owner to recognise the statement the new system is making and the service colleague to be able to explain it to the reader.
The same discipline improves the way an executive team evaluates progress. A report can distinguish mapped records, interpreted exceptions, unresolved obligations and the cost of carrying them. It can show whether a programme is reducing uncertainty or simply relabelling it. It can also identify the point at which further technical work will not help because the decision belongs elsewhere. That makes a CIO's account more useful: the board or sponsor sees the relationship between expenditure, evidence and the authority still needed to finish the work.
For me, a successful migration is one in which the enterprise can explain its commitments at least as well after the change as before it. The reader should not have to understand our new product taxonomy to ask for what they bought. The service team should not have to reconstruct an old promise from memory because the conversion discarded the context. A login opens the door; it does not define everything on the other side. Keeping that distinction visible is part of the technology leader's responsibility when a simpler platform inherits a complicated commercial history.