In Q4 2025 we migrated Ameris Wealth Management off a legacy portfolio management system onto BRITech. 1,500 portfolios, six custodian feeds, four market-data vendors, two years of historical transactions. Live cutover ran on a Saturday. Production was running by Monday morning with no manual breaks to clear.
This is the runbook. It’s also a list of three things we’d do differently next time.
The setup
Ameris is a Santiago-based asset and wealth manager with $1.6B AUM across institutional and high-net-worth mandates. Their legacy PMS had served them well for nearly a decade but had become a brake on three operating priorities:
- Real-time NAV across multi-currency portfolios (the legacy system computed end-of-day, with manual override workflows)
- Native NCG 507 indicator generation (the legacy required exports to a separate compliance tool)
- A connector model that didn’t break every time a custodian updated their file format
The decision to migrate was made in mid-2025. The target was BRITech with our Backbone team running the operations layer. Cutover scheduled for Q4 2025. The non-negotiable was: zero data loss, full historical reconciliation, no service interruption.
The four-phase approach
We’ve been refining a migration playbook for four years. The current shape of it is four phases, three months end-to-end:
Phase 1 — Discovery (3 weeks)
Map every data flow. Every. Single. One. We catalogued 47 inbound feeds, 23 outbound reports, 11 manual workflows that had grown up around the old system. The deliverable from this phase is a single diagram that can be printed on one page — but the work behind it is exhaustive.
The key insight: most “manual workflows” turn out to be the most important part of the system. They’re what the operators have built to compensate for the things the platform doesn’t do. You replicate them in the new system or you replicate the failure modes they were compensating for.
Phase 2 — Replay (4 weeks)
We built a migration tool that replayed two years of historical transactions through the new platform — one transaction at a time, in original order, with original timestamps. The output: a fully populated BRITech instance with positions and history matching the legacy system to the cent.
This phase is where most migrations either succeed or fail. We’ve seen vendors deliver “migrations” that involve a single CSV import on cutover weekend. Those are the migrations that turn into year-long reconciliation projects.
The reason replay matters: a year from now, when the regulator asks “where did this position come from?”, the answer should be a transaction, not a CSV import.
Phase 3 — Parallel run (3 weeks)
For three weeks, both systems ran in parallel. Same inbound feeds, same processing, two ledgers. Every difference was investigated; nothing was waved away. We found 14 break categories during parallel run. Eight were genuine migration bugs. Six were latent issues in the legacy system that had been masking themselves as “tolerable noise” for years.
Phase 4 — Cutover (1 weekend)
Cutover ran Saturday evening through Sunday afternoon. Final replay of the last week’s transactions. Full ledger reconciliation against six custodians and four price sources. Sign-off from compliance. Live traffic redirected Monday at 7am.
Three things we’d do differently
1. Start the connector library earlier
We built six custodian connectors during the migration. Three of them — BCI, BCP, Santander — we’d built before in slightly different shapes. Instead of standardising the library before the migration, we did it during. That cost us about three weeks. Next time, the library work happens first; the migration uses it.
2. Run the parallel longer for derivatives
The break categories we found in parallel were almost entirely on derivative positions. Equity and fixed-income were clean within days. Derivatives took the full three weeks to reconcile cleanly, mostly because of corporate actions we hadn’t fully modelled. Next time, derivatives get a four-week parallel; everything else gets two.
3. Brief the front office earlier
The front office found out the migration was imminent about six weeks before cutover. That was enough time to retrain people on the new UI but not enough to surface workflow problems. Two of those manual workflows from Phase 1 turned out to need real engineering effort to replicate — and we discovered that during cutover weekend, not before. Next time, front-office briefings start at week one.
The numbers
For the curious — final cutover metrics:
- 1,500 portfolios migrated end-to-end
- 6 / 6 custodian connectors live on Monday morning
- 0 manual breaks at cutover
- $1.6B AUM under permanent governance from day one
- T+0 reconciliation lag against six custodians from week one
The board memo for the migration was four pages. We’ll publish the redacted version separately.
Patricia Donoso leads implementations at finnerve. If you’re contemplating a PMS migration and want to talk through the approach, start a conversation or read the Backbone service overview.