Many large tech migrations are thought of as ‘problems’ that can be managed: deadlines to meet, risks to mitigate, multi-year programmes to navigate with minimal disruption. The primary ambition is to come out the other side roughly where you went in, but on a new system that's still supported.
However, it’s worth asking whether that's the right framing.
Large scale migrations, while rare, are valuable opportunities for organisations to revisit how they really run, and the follow-on benefits can often be worth more than the cost of the programme itself.
The pre-season nobody uses
A migration is a bit like pre-season football. It's the window where the squad is together, the league hasn't started, and the manager can still change things. New formations. New patterns of play. Drill the back four on a different shape. Bring in signings who fit the footballing philosophy, loan out players who don't.
A key factor in the success of any football team is how they use pre-season. The best managers ask hard questions: what kind of opposition are we going to face this year, what are the patterns we'll need to break, what shape do we want to be able to play when the game's getting away from us? This informs the squad design, the formation(s), and the training methods to support the answers to those questions. The teams that stay mid-table from season to season run last year's drills with the same eleven, in a new kit. They turn up in August looking the part. By November the league table looks much like last year's.
It's not that tactical fixes can't be deployed mid-season – they often are – but pre-season provides a golden opportunity to reset the foundations upon which adjustments can be made where needed.
Many ERP migrations end up looking like the November table where the new system goes live, the badge is new, the away kit is fresh, yet the same processes, data fragmentation and workarounds invented years ago are still running.
The opportunity was never really in the new system, but rather in deciding what the ‘team’s’ identity would be in the first place.
Designing the team around what you'll face
The questions worth considering aren’t ‘which system do we move to’ or ‘how do we lift and shift safely.’ More useful, is asking yourself: ‘what decisions does the business need to be able to make, in data, post-migration?’
Having this as a guiding principle helps to mentally extract away the day-to-day reality of frustrations with data access, cleanliness and fragmentation, to focus on the decisions that really move the needle on outcomes.
What does our business look like, expressed as a data model? What are the entities that matter, what are the relationships between them, can we see that in our existing architecture?
And the harder version: what do we want to know about our business that we can't easily know today? What questions do we want to answer in five seconds rather than five weeks? Which decisions do we keep making with bad or limited information, because the data is fragmented across systems that don't talk to each other?
The questions that need to be asked, and the decisions that need to be made, help shape the data model. It's the same process a manager uses in pre-season. What styles of play do the opposition teams have, what's the best formation for combating those styles, how much flexibility do I need in my formations - the answers to these questions informs the make up of the team and the pre-season activity.
Many migration programmes work the other way around: start with the system, configure it in a similar way to the previous system, land the data and only then ask whether the resulting model answers the right questions.
But by that point, the formation is picked. You're playing it whether it suits the season or not.
Reading the game in-flight
A good manager doesn't just design the team in pre-season and hope the plan holds for ninety minutes every weekend. They read the game in-flight. They make the substitution at 65 minutes. They change shape when the opposition's pressing is hurting them. The team has been trained to ask different questions of the match as it unfolds, and to act on the answers.
There is some similarity here when it comes to an enterprise organisation. The data model and the operating model that is built during a migration aren't just designed to answer today's questions. They're designed to ask new ones when conditions change, and to act on the answers without waiting six months for someone to build a report. That's what AI-native operations look like in practice, with the technology not a feature switched on after go-live, but a way of designing the organisation so decisions can be made and acted on in real-time.
For me, the intersection of ontology and AI is where this comes to life. A well-designed ontology describes the business in data, encoded with business logic and battle-tested metadata. Put AI capability on top of that and you have something more than a migration accelerator: you have a future-proofed, flexible data model that can support in-game decisions when conditions change.
A season is a long time
The reason all of this is worth thinking about is that a migration of this scale tends to come round once every fifteen to twenty years. Think of that as a season. You don't get another pre-season until this one is over.
Whatever is built/migrated now is what the business will be running on through the next economic cycle, new CEOs, geopolitical changes, additional acquisitions and the next wave of AI capability. Lift-and-shift defers most of the interesting decisions. The argument for doing it that way is usually risk-based: change the system without changing the business, and modernise later.
The budget gets spent, the steering committee ends, the appetite for change reduces, the momentum slows and the operating model questions go back into the drawer. The next chance to open the drawer is the next pre-season, likely 10-15 years. That's a long time to run on a system that was decided more by default than by design.
The fundamental question that needs answering here is not one about cost, scope or timeline. It's ‘what do we want our business to be able to do when this is finished, and have we built the migration around that answer – or around the system?’
Reasonable people will disagree on how far to push this, and not every business is ready to redesign itself in the middle of a system change. But the team is being picked either way, and it’s better to have the style-of-play nailed down before the losses pile up.
