VK Orbit · A practitioner's view

The only thing that fails quietly

In a migration, procurement content is the only thing with no hard dependency. Nothing breaks on the night if the catalogue is thin. It breaks three months later, when everyone has gone.

Every migration has a date. It gets set before anyone has looked properly at the content, and once it exists it stops being a plan and becomes a fact. Scope moves around it. Budget moves around it. Content goes across it, ready or not.

Most people who have done this treat that as a governance failure. I have stopped seeing it that way. The date usually wins for reasons that hold up, and the interesting question is not how to beat it. It is what you do once you accept that it is going to.

The last piece argued that a category strategy is only worth whatever a system can execute of it, and that most organisations own the document without owning the channel. This is what happens to that content when somebody puts a date on the wall.

First, what I mean by content

It is doing a lot of work in this piece, so it is worth being precise.

Not documents. Not the category strategy itself. Content is the operable layer. The catalogue lines and the prices attached to them. The buying templates. The punch-outs and marketplace routes. The policy and thresholds that decide who can buy what without asking. The supplier records that make an order possible at all. The mapping that tells the system which category a request belongs to.

Everything a requester touches without knowing they are touching it. It is the difference between a contract that exists and a contract somebody can buy from at 2am.

The cost stack nobody prices in full

Ask why the date cannot move and you get "end of support". That is rarely the whole answer, and on its own it is the weakest part of it.

Vendor support dates are negotiable, and everyone in this business knows it. Procurement suites run on extended and custom support for years at a time. The vendor would rather keep the revenue than lose the customer. The premium is real, but it is a line item, not a cliff.

What actually defends the date is the stack underneath it.

Figure 1 · What a slipped date actually costs

IN THE BUSINESS CASE RARELY MODELLED, ALWAYS PAID Extended or custom support fees a line item Two estates running in parallel Integrator contract, extended without leverage A delivery team you cannot release Infrastructure you cannot decommission Licences paid for twice obvious to whoever signs, absent from the model
Only the top layer usually appears as a number. The five underneath it are the reason the date does not move.

Only some of that sits in anyone's model. None of it needs to be modelled to be obvious to the person signing.

Three kinds of date

The useful distinction is who set it.

Figure 2 · Negotiation, or countdown?

Vendor Someone has a quota. Argue with them. Statutory A tax authority has no view on your catalogue. Contractual A counterparty, a lawyer and a meter. Negotiation Countdown Most programmes treat all three as the same object. They are not. Knowing which one you are facing tells you what kind of conversation you are about to have.
The question is never whether the date is fixed. It is who fixed it, and whether they can be argued with.

Vendor dates are commercial. Someone on the other side has a number and a quota. They can be argued with, and they usually are.

Statutory dates are not. An e-invoicing mandate arrives on a day chosen by a tax authority, and a tax authority has no view on your content readiness.

Contractual dates are the hardest of the three. A transitional services agreement after a divestment comes with a counterparty, a lawyer and a meter. Every day past expiry carries a price someone already agreed to, usually designed to hurt.

Most programmes treat all three as the same object. Knowing which one you are up against tells you whether the conversation you are about to have is a negotiation or a countdown.

Why content is always what gives

This is the part I would defend hardest.

In a migration, everything has a dependency. Finance data has a statutory one. Master data has a system one. Interfaces have a technical one. Break any of them and something stops on cutover night, loudly, in front of everyone.

Content has none of that. Nothing breaks at cutover if the catalogue is thin. The system comes up. The reports run. The demo works.

Figure 3 · Loud and immediate, or silent and late

CUTOVER day 0 +1 month +3 months +6 months +9 PROGRAMME OPEN · budget, attention, a team closed Interfaces Master data Finance fails loudly on the night, fixed within weeks Content escalations, free-text requisitions, a quiet drift back to email nothing happens here
Nothing breaks at cutover if the catalogue is thin. It breaks three months later, by which point the programme bar above has already ended.

Content fails three months later, quietly, in escalations and free-text requisitions and a slow drift back to whichever buyer people used to email. By then the programme is closed, the budget is spent and the squad has moved on.

Content does not lose because leaders cannot see its value. It loses because it is the only thing on the plan that fails silently and late. Everything else fails loudly and immediately, which is precisely why everything else gets fixed.

Once you see it that way, the usual advice about making the case better and getting the sponsor to care is treating a symptom. You cannot out-argue a dependency you do not have.

What the research does not count

There is a tell in the literature.

Panorama's 2026 ERP report measures budget overrun and schedule overrun, and attributes them to governance, resistance to change and resourcing. Hackett's 2026 procurement study measures workload, headcount, operating budget, savings and AI adoption. The ASUG and Precisely migration research lists business process change, customisation and organisational resistance as the barriers.

Now try to find catalogue coverage. Or requisition first-time-right. Or the share of addressable spend a requester could buy today without contacting procurement.

Figure 4 · The instrument decides what you can see

WHAT THE BENCHMARKS COUNT WHAT IS NOT EVEN A CATEGORY Budget overrun Schedule overrun Governance and change resistance Headcount and operating cost Savings delivered AI adoption Catalogue coverage Requisition first-time-right Channel compliance Self-service share of spend Content coverage at cutover Absent, not poor. Nobody scored badly.
The instruments we use to explain why programmes fail were not built to see this.

They are not there at all. They do not appear as poor results. They appear as absent categories. Which means the failure I am describing is invisible in exactly the evidence a steering committee is most likely to quote back at you.

So plan for the world where you lost

If bad content migration is closer to a certainty than a risk, prevention is the wrong budget line.

That is uncomfortable, because no business case is ever approved on "we will go live wrong". I have watched that argument die in a room more than once. The version that survives does not say it. It says the content work does not finish at cutover, here is what finishing it costs, and here is the date it finishes.

Six options. I have watched all six.

Move the date

Available only when the date is vendor-set

ForContent crosses clean. No remediation debt to carry into the new estate.
AgainstCost compounds, credibility is spent, and on statutory or contractual dates it is not on the menu. The worse failure sits at the far end: programmes that wait for a readiness that never arrives and deliver nothing at all.

Cut scope, hold the date

What always happens

ForThe date holds. Everyone can see what was given up, at least on the day.
AgainstWhat gets cut is always the layer without a dependency, so you take on a liability nobody prices. Most of the value here is in naming it as a decision, since it usually gets recorded as an accident.

Take everything across as it is

Cheapest before cutover, dearest after

ForFast. And there is a real argument that cleansing before you understand the target model destroys meaning the new system needs.
AgainstYou inherit the mess at scale, now sitting inside a system people trust more than the last one.

Take across deliberately

Coverage over completeness

ForMove what is used. Leave what merely exists. Transactions, not records.
AgainstNeeds behavioural data you may not have yet, and it starts an argument about whose categories get left behind.

Fund remediation inside the migration case

The argument worth having

ForThe squad exists on day one, while there is still money and attention in the room.
AgainstIt can read as planning to fail, and it can become permission not to try. Fund it alongside a minimum content gate. The two are not alternatives.

Diagnose from behaviour after cutover

Where the model earns its keep

ForBehavioural data starts the day you go live and does not care how good your catalogue is. It hands a squad a work queue ranked by observed pain instead of by spend value or alphabet.
AgainstNeeds volume before it means anything, and optimising for what people did can entrench the bad routing you inherited.

That last one is where a propensity model earns its keep earlier than my own sequence suggested, and it is worth taking on its own.

Make it loud and early

Everything above says content fails silently and late. Which points at the fix, and the fix is not a bigger cleansing programme.

If the problem is silence, instrument it.

From day one on the new system you have behavioural data that owes nothing to your catalogue quality. What people searched for and got nothing. What they abandoned. What they typed as free text that already existed under a different name. Which categories they routed around entirely.

Zero-result search rate alone will tell you more about content coverage in a week than a sampling exercise will tell you in a month. E-commerce teams have lived by that number for twenty years. Almost nobody in procurement measures it.

That turns a three-month silent drift into a week-one signal. A failure that is loud and early gets treated like every other loud failure, and we already know those get fixed.

Then there is the other half, which is about cost.

The reason "fund the remediation" dies in a steering committee is not that anyone disagrees with it. It is that remediation has always meant a squad of humans rewriting content category by category for the better part of a year, and nobody can size that credibly enough to defend it.

Classification, de-duplication, attribute extraction and description normalisation are the least glamorous things a model can do and among the things it is genuinely good at. If that work costs a fraction of what it used to, the remediation line stops being the number that gets struck out.

The most useful thing AI does here is not fixing your content. It is making the argument for fixing it winnable.

There is a third use, and this one belongs before cutover. Score every item for completeness, duplication and mapping confidence, then publish a readiness figure by category. Content finally has a number in the board pack, which is the whole problem in figure four. And you can decide deliberately what crosses and what waits, instead of discovering the answer later in the escalation queue.

Two cautions, because this is where I would argue with myself.

Point automation at a bad taxonomy and you will industrialise it beautifully. Models trained on a legacy catalogue learn a legacy mess at speed. Whatever direction you were already facing, this makes you travel further in it.

And the sequencing rule from the last piece still holds. Diagnosis from day one is fine. Recommending from a misfit catalogue is not, because it surfaces the wrong price with more confidence than any human would.

Figure 5 · Three places a model earns its keep, and one where it does not

CUTOVER Before Score every item for completeness, duplication, mapping confidence. Content gets a number. Day one Zero-result searches, abandonment, free text that already existed. Month three becomes week one. Ongoing Classification, de-duplication, attributes, descriptions. Remediation at machine cost. Not yet Recommending from a misfit catalogue. Models that observe can run on bad content. Models that act on it cannot.
Diagnosis on day one is fine. Acting on the same content is not, and the difference is the whole of the last piece.

Build it and they will come is not a plan

Say you have won the argument and the squad exists. You still have to decide what it works on, and the obvious answer is wrong.

The obvious answer is to rank categories by spend and start at the top. But content is not exercised evenly. Software renewals cluster and arrive once a year. Leases and maintenance agreements have dates on them. Tail and ad-hoc buying never stops. A top-spend category whose next event is eleven months away is less urgent than a mid-spend category somebody hits every week.

Historical demand tells you which is which. It also lets you position benefit realisation honestly, which almost nobody does. If a category's content gets exercised in the third quarter, that is when its benefit shows up, and a business case that draws a straight line from go-live is describing something that has never happened.

Then instrument the two things that actually tell you whether curation is working: adoption, and deviation. Not as a monthly report to a steering committee that has stopped meeting. Show a category manager their own deviation rate on their own categories and something happens that no training deck has ever achieved. That is change management wearing a dashboard, and it is the cheapest change management there is.

On what to prioritise, I would hold two lists, not one. Top spend categories, because that is where leakage concentrates. And preferred and diverse suppliers, because their content is usually the thinnest and their strategic weight is the highest, and a pure spend ranking buries them every time.

The last thing, and the reason none of this ever finishes. Content decays. Prices move, suppliers change, somebody reorganises the taxonomy, a category manager leaves and takes the reasoning with them. Curation is a standing job. Treat it as a project task and you will be having this conversation again in three years, about a different system.

That is a piece of its own, and it is the one I want to write next. It is written: You touch it. You own it.

The one thing to change

If you take one thing from this, take this. The remediation squad belongs in the migration business case, not in a request made after go-live when everyone upstream already believes the thing is finished.

And instrument it from day one, so the failure stops being silent. Content has never lost the argument on merit. It loses because nothing goes bang.

That is not pessimism. It is the only version of the plan that matches what actually happens on the ground.

Anything you would add, or argue with?

Everyone I speak to is at a completely different point in this, and the "we tried that and it did not work" stories are the most useful ones. Tell me where you are and I will reply properly.