The trigger is a capability gap, not an outage
A legacy core that has run reliably for fifteen years rarely gets replaced because it’s unstable. It gets replaced because it can’t onboard a new asset class, can’t expose a real-time API to a custodian, or can’t produce the audit trail a new regulator now expects. The trigger is almost always a business capability gap, not a system outage.
Why “rip and replace” is the wrong first move
The core rarely needs to disappear on day one — it needs to stop being the only source of truth. The pattern we see work is a strangler approach: build the new investor onboarding, portfolio, or reporting capability as an independent service, run it alongside the core, and migrate books of business into it deliberately, asset class by asset class. This keeps the firm operating while the platform changes underneath it.
Reconciliation is the real engineering problem
The harder part isn’t the migration sequencing — it’s reconciliation. Every parallel-run period needs a rigorous, automated way to prove the new platform and the old core agree on positions, NAV, and cash, because the business will not accept “trust us” as a cutover criterion. Firms that plan for reconciliation as a first-class engineering problem, not an afterthought, are the ones that hit their cutover dates.