A migration can end in one of two very different places. In the first, a vendor builds the new system, hands over a finished product, and leaves — and your team, which did not build it and does not fully understand it, now depends on that vendor for every future change. In the second, your own team can run and evolve the new system themselves. Both deliver a working system on go-live day. Only one leaves you in control afterwards, and the difference is decided by how the work is done, not by what is handed over at the end.
This matters more than it first appears, because a system is never finished at go-live. It needs fixes, changes and new features for as long as the business uses it. If only the people who built it can do that work, you have not escaped dependency — you have moved it. The key-person risk that made the old Forms system fragile, where a few individuals held all the knowledge, is recreated in a new form, with the migration vendor now holding the keys. Trading one lock-in for another is a poor return on a migration.
The alternative is to build the system with you rather than for you. In a co-creation model, the partner and your own developers work as one team throughout the project, and knowledge transfers continuously as the work proceeds rather than in a documentation hand-over at the end. Your people are not spectators who receive a finished system; they are participants who help build it, learning the new platform on the real application as it takes shape. The capability to run the system stays in your organisation because it was grown there.
Knowledge transferred continuously sticks in a way a hand-over event never does. Reading documentation about a system someone else built teaches far less than building it alongside the people who know the platform, in the context of your own application and its quirks. By the time the system goes live, your team understands it because they made the decisions that shaped it — why a module works the way it does, where the awkward parts are, how to change it safely. Ownership earned during the build is real in a way that ownership handed over at the end is not.
Building together also de-risks the delivery itself, not just the aftermath. Your developers know the old system and its undocumented quirks; the partner knows the new platform and the migration craft. Put them in one team and each fills the other’s blind spot — the partner is not guessing at business rules, and your people are not guessing at the new technology. Decisions that would otherwise bounce between two organisations over email get made in the room, and the misunderstandings that derail hand-over-style projects have far less room to form.
Co-creation is the right model when the system is complex and business-critical and you intend to keep evolving it — which is to say, most core systems. It is the choice you make when long-term independence matters more than simply outsourcing the work. Other models have their place: a dedicated team, a full turnkey delivery, or augmenting your own team with specialists can each fit particular situations. But when the goal is to come out of the migration able to stand on your own, co-creation is the approach designed for that outcome.
It is fair to acknowledge that co-creation asks something of you in return: your developers have to be freed up to take part, rather than left to watch from the side. That is a real cost during the project. It is also the cost that buys independence afterwards — the time your team spends building the system is the time it spends learning to run it. Organisations that decline to invest that time often pay it back later, and at a higher rate, in dependence on the only people who understand a system they did not build.
Done well, this is visible in the result: organisations emerge able to maintain and extend the system themselves rather than calling the vendor for every change, as in the Van Group migration, where building team independence was an explicit goal. It is worth being precise about what continued partnership then means. When a high share of clients go on working with a partner for years, that is not the dependency of people who have no choice; it is the continued choice of teams who could manage alone and prefer to keep collaborating. Retention earned that way is a sign of trust, not lock-in.
The question to put to a prospective partner, then, is not “will you document the system for us?” Documentation is necessary but not sufficient. The sharper question is “will my team build this with you, and be able to own it afterwards?” The answer reveals whether you are buying a product that leaves you dependent or building a capability that stays. A partner confident in the second answer will welcome your developers into the work; one selling the first will prefer to keep the build to itself.
Next step. An evidence-based diagnosis plus a co-creation approach means the knowledge ends up in your team, not just in the deliverable — so independence is the result, not a hope.
