Selected Work · Reflection 01 · Danske Bank
What Gets Embedded
Moving customers onto a new platform is not the same as creating a new experience. The remaining seams reveal which parts of the product have truly changed, and which have only been moved behind a new interface.
There is a help panel, inside an otherwise carefully built banking platform, that still runs on Flash. You have to go looking for it. It sits several clicks deep, behind a login screen that was ahead of its category: built for treasurers and CFOs, capable of forecasting cash flow, modelling hedges, and adapting around what different businesses needed to see. And then, behind one particular screen, a format that had already been dead for years by the time anyone thought to look.
The platform had begun with a broader ambition: not just replacing old banking software, but creating a more connected environment across services and products. Making that kind of transition happen across a large organisation is hard, and much of it succeeded.
Once you’ve seen the Flash panel, though, you start seeing the rest of the platform differently. It didn’t look like one thing. It looked like several things, wearing the same login page – some screens considered and on-brand, others still carrying the visual grammar of a decade earlier. A customer moving between them wasn’t moving between features. They were moving between decades of the same bank.
The old screens were easy enough to forgive. Nobody had defended them or been proud of them; they were simply what hadn’t yet been reached. The more interesting problem was in the new ones. Two of the platform’s most important products had, in fact, been properly rebuilt, by teams who clearly cared about doing it well – and the result still arrived in front of the customer looking like everything it was meant to replace, because each had been built to its own team’s standard rather than one shared across the platform. The missing piece was not technical capability. It was a shared decision about what consistency meant across products.
What got tracked, easily and often, was how many customers had moved onto the new platform – the number every steering committee could take in at a glance. A number like that has no opinion about what’s inside the box it’s counting. It only confirms that the transition happened, not what the customer actually inherited.
Once migration progress became the dominant measure of success, certain trade-offs became more likely. Everything a customer might touch needed to arrive on roughly the same timeline, whether or not it was actually ready, and the only way to make that true – when only some of it had been properly rebuilt – was to embed the difference and frame it consistently enough that it read as one experience rather than several.
The deeper point, I think, is this: migration is not only a technical process of moving functionality from one system to another. It is a product decision about which inconsistencies customers are asked to absorb, and on whose timeline.
Migrations don’t remove complexity. They relocate it. The question I carry forward is where that complexity lands: with the teams building the systems, or with the customers trying to use them.