System migrations, proved line by line.
Moving from one platform to another is mostly a data problem: extract, map, transform, load. The part that keeps people awake is different, proving nothing was lost, every balance ties, and the history survived. That’s the part we’re built for.
| Trial balance, old system to new, by entity |
| Opening balances and retained earnings |
| Transaction history, count and value |
| Investor, unitholder and beneficiary positions |
| Cost basis and acquisition history |
| FX rates and revaluation history |
| Open items, accruals, prepayments, POs, unsettled trades |
Why migrations go wrong
Almost nobody loses the data. Plenty of people can’t prove they didn’t.
The transfer itself is rarely the failure. The failure is six weeks after cutover, when a balance doesn’t agree with the old system, nobody can explain the difference, and there’s no evidence trail back to what was migrated. By then the legacy system is being decommissioned and the audit is asking questions.
The mapping hides the judgment
Chart-of-accounts mapping is presented as a technical task. It isn’t, it’s an accounting decision about what each balance means in the new structure. Get it wrong and everything downstream inherits the error.
History gets quietly simplified
Transaction-level history is the first thing dropped when a deadline bites, migrated as opening balances only. It’s the decision teams regret first, usually at the next audit.
The tie-out is done by eye
Someone spot-checks a sample in Excel and calls it reconciled. Across dozens of entities and years of history, a sample is not evidence.
What we do
The data work, and the proof.
Chartered accountants doing the mapping, and engineers doing the conversion, the same people, which is why the accounting decisions and the code agree with each other.
Extraction
We pull what the legacy system will give us, exports, reports, database extracts, and the awkward stuff nobody has looked at since it was archived. No vendor cooperation required.
Mapping
Chart of accounts, entity structures, security masters, investor records. Mapped by accountants who know what the balances have to mean on the other side, and documented so a reviewer can challenge every decision.
Conversion
Transformation into the target system’s exact upload format, with dates as real dates, encodings that survive, and the edge cases handled rather than discovered later.
Dry runs
Loaded, checked, broken, fixed, repeated, as many cycles as it takes, before anyone touches production. The first live run should be boring.
Parallel running
Both systems run side by side and every output is compared automatically, not sampled. Differences are listed with amounts and explanations, entity by entity.
The tie-out
A reconciliation pack that evidences every balance from old to new, with the exceptions listed and explained. That’s the document your auditor asks for, and the reason to sign off with confidence.
Any system to any system
We work on your data, not on a vendor partnership.
We’re not a reseller and we’re not certified to one platform’s party line, which means we have no stake in where you land. Fund platforms, trust and corporate systems, ERPs, cloud ledgers, or twenty years of spreadsheets: if it can be exported, it can be migrated, and it can be proved.
No integration project
We work on exports and source files, so getting started doesn’t require system access, vendor sign-off or an IT workstream of its own.
Alongside your implementation team
The vendor configures the new platform; we handle the data and the evidence. Those are different jobs, and the second one is usually nobody’s.
Legacy is not a problem
Discontinued systems, lost documentation, a database nobody has credentials for. We’ve built pipelines out of worse.
How a migration runs
Four phases, and you see the evidence at each one.
Assess
What exists, what can be extracted, what’s missing, and what the mapping decisions actually are. You get a written scope and a fixed price before any commitment.
Build & dry run
Pipelines built, loaded into a test environment, reconciled, broken, fixed. Repeated until the exceptions report comes back clean.
Parallel
Both systems live, every output compared automatically each cycle. Differences investigated and explained while the old system is still there to check against.
Cutover & tie-out
The switch, then the reconciliation pack that evidences every balance from old to new, with an audit trail that survives scrutiny long after we’ve gone.
Who this is for
Anyone mid-migration, or dreading one.
Migration work is where our two halves matter most at once: the mapping is an accounting judgment, the conversion is engineering, and the tie-out is both.
Finance teams changing platform
You’ve bought the new system and the implementation is underway. The vendor configures it; nobody owns the data, the mapping, or the proof that it landed correctly. That’s the gap we fill.
- Who this is for
- Fund finance teams·GPs & management companies·trust & fiduciary businesses·family offices·corporate groups
Administrators consolidating systems
Onboarding a book of business, retiring a legacy platform, or consolidating after an acquisition, with a deadline and a team that already has a day job. We take the data workstream so your people stay on clients.
- Who this is for
- Fund administrators·trust companies·outsourced finance providers
Questions
The things people ask first.
Do you replace our implementation partner?
No. The vendor or implementation partner configures the new platform. That’s their job and they’re good at it. We own the data workstream: extraction, mapping, conversion, parallel running and the reconciled tie-out. In most migrations that second job isn’t formally anyone’s, which is exactly why it goes wrong.
Which platforms do you work with?
Whichever you’re leaving and whichever you’re joining. We work on exports and source files rather than plugging into system internals, so we don’t need a vendor partnership, a certification, or access to the platform itself. That also means we have no commercial interest in where you land.
Our legacy system is ancient and undocumented. Is that a problem?
It’s the normal case: discontinued platforms, missing documentation, a database nobody has credentials for. If the data can be got out in any form, it can be mapped, converted and reconciled.
How do we know nothing was lost?
Because we prove it, rather than sample it. Every balance is reconciled from old to new and evidenced in a tie-out pack: trial balance by entity, opening balances, transaction history by count and value, positions, cost basis, FX history and open items. Exceptions are listed with amounts and explanations rather than quietly rounded away.
Where does our data sit?
With you. The work happens in your environment, on your systems and source files. Your data stays where it already lives, and it doesn’t leave Jersey unless you ask. Where a workflow uses AI, that’s designed in explicitly and agreed up front; we never put client data through AI tools by default.
What does it cost?
The assessment phase produces a written scope and a fixed price before you commit to the build. We’d rather tell you a migration is bigger than you hoped up front than discover it together at phase three.
Migrating, or putting it off?
Start with the free process review. We’ll look at what’s actually in the legacy system, what the mapping really involves, and give you a straight answer on the size of it, before anyone commits to a date.
Book a process review