Notes on what you're actually replacing.

In 2013 I was on a migration at a global asset manager. The system being replaced had been built in-house in the early 2000s. We had documentation, a vendor RFP that ran six months, a deployment plan, an executive steering committee. What we did not have, and could not produce, was an answer to the question: what does the current system actually do, and which parts of it are people relying on? Not the spec. The spec was clear. What it actually did. After a decade in production, absorbing every patch, every workaround, every quiet adjustment that someone made one morning and never wrote down.

This turned out to be the work. Not the data conversion, not the user training, not even the vendor negotiation. Figuring out what the existing system actually was: what people had taught themselves to do because the platform couldn't, and what the platform was doing that nobody had told it to do. That was the migration. The new system was the easy part.

I have watched four full transformation cycles in financial services now, and the pattern is consistent. The technology of each cycle was new. The discovery problem was not. Every successful migration I've been part of started with the same realization: the system being replaced wasn't what the org thought it was.

What you actually have to migrate

What you actually have to migrate isn't the data. The data conversion is a solved problem. There are vendors, methodologies, test harnesses, parallel-run discipline. It's hard, but it's a known hard.

What you actually have to migrate is the workflow that grew up around the system after it shipped. The reports the system produces, and the reports people actually use, and the difference between those two lists. The shortcuts inserted by someone five years ago for a reason nobody remembers. The downstream dependencies that nobody mapped because they didn't exist on the day the platform went live. The judgment calls that look like configurations but are actually accumulated wisdom about edge cases the spec never anticipated.

On the Aladdin work at Deutsche Asset Management (a multi-year program serving portfolio managers across roughly $700B AUM, distributed across New York, Frankfurt, and London) the bulk of the discovery work wasn't about features. It was about understanding what each portfolio manager had built into their workflow that the new platform needed to either replicate, replace, or politely refuse. None of that is a deliverable. It's a conversation, repeated dozens of times, with people who have learned to be skeptical of outside teams holding RFPs. I have written elsewhere on this site about the seat on the trading floor that eventually came out of that engagement. What I want to note here is what produced the seat. Not the project plan. The discovery work.

The reports nobody reads

A few years earlier at the same firm, we had replaced an internally-developed accounting platform with a hybrid State Street solution. Twelve front-office business groups, end to end. Several hundred reports in scope, across roughly seven hundred users.

The hardest part wasn't the data conversion. It was figuring out which of those reports anyone was actually using, and why.

Some were opened daily by people who couldn't articulate what they did with them. Some had not been opened in two years but lived on someone's mandatory checklist. Some existed because a regulator had asked for them five years earlier, and nobody had checked whether the regulator still wanted them. A few were the entire basis of a decision someone made every Tuesday morning, and the consequence of removing one would not show up in any system; it would show up the next quarter, when the decision came out wrong.

The work was political as much as analytical. Asking a senior analyst "do you actually use this report" is asking "can we remove your daily anchor." You cannot do that over email. You cannot do it by audit. You do it by sitting with the team long enough that they trust you to be careful with what they tell you.

By the end of the discovery phase, we had reduced several hundred reports to several dozen. Not by deleting things; by finding out what was actually load-bearing and what was inertia.

What documentation can't carry

I have written elsewhere about a data issue we hit on the Morgan Stanley CCAR Stress Testing program, in the Cross Market Risk workstream. The short version: values appearing in the wrong column, intermittent, not reproducible on demand. The fix came from someone on the source-system team who remembered, when asked directly, why a particular shortcut had been inserted into the data flow years earlier. Not in the documentation. Not in the comments. In someone's head. Six months from retirement.

That story is not unusual. It is closer to typical. On every migration I have been part of, at some point, the question that resolves the hardest problem turns out to be: who remembers why we did it this way. The answer only works if the person who remembers is still in the building.

This is the part the standard playbook underweights. The consultancy-grade method assumes documentation is the answer. It is not. Documentation captures what was true on the day it was written. Memory captures why. And memory leaves with the person who had it.

Documentation has a shorter shelf life than people's memories.

The prework that doesn't get named

None of this is the most under-resourced phase of platform replacement. The capabilities assessment is.

In 2007 and 2008, at Cambrian, my partners and I ran a capabilities assessment for a global asset manager's insurance asset management business. The mandate was to design an industrial-strength outsourced platform to support roughly two hundred billion dollars of new outsourcing flow, across the full back- and middle-office value chain. We reported into the CAO; the team was distributed across London and Zurich. We built a vendor scoring methodology and benchmarked against the leading insurance asset managers of the time.

What I took from that work was not the scoring methodology. It was that before you can run a migration, you have to answer a harder question: what are we replacing, why now, and what would the next platform need to do that the current one can't. Most organizations underinvest in this phase because it doesn't produce shippable artifacts. What it produces is institutional clarity about what the next ten years of operational infrastructure needs to be.

The migrations that fail aren't migrations that picked the wrong vendor. They are migrations that didn't honestly answer the prework question.

What the AI moment changes, and what it doesn't

The current generation of platforms (modern fund accounting systems, cloud-native back-office tools, agentic workflow agents that promise to automate the steps that used to require a team) is the loudest version of the platform-replacement moment I have seen in thirty years. The pitches promise faster migrations, lower friction, better defaults.

Some of that is true. The tools are better. None of it changes the discovery problem. If anything, the AI moment makes the discovery problem more important, not less. Models trained on documented workflows cannot learn what isn't documented. Agents acting on incomplete process maps will execute the gaps as faithfully as they execute the rules. The institutional memory layer hasn't gotten smaller. It has gotten more consequential.

The vendors promising to do this for you are not lying, exactly. They are selling the part of the work they can solve. The part they cannot solve, you still have to do yourself.

What I keep

I have been part of four full platform migrations in financial services over the past thirty years. Each one started with a leadership case built on cost reduction or capability expansion. Each one ended somewhere else: in a conversation about reports nobody reads, shortcuts nobody remembered, knowledge that was about to walk out of the building.

The lesson isn't that migrations are hard. Everyone knows that. The lesson is more specific. The migration you can describe in a deck is rarely the migration you're actually doing. The work is in the part that isn't on the deck.

// DG