Client records aren't what breaks a stack consolidation. The data nobody owns does: the spreadsheet on someone's desktop, the fee basis that only exists inside a PDF, the vulnerability note living in an email thread. Moving from several tools to 1 platform is a mapping problem before it's a migration, so inventory everything you hold, decide what's authoritative, move in phases with a single source of truth at each step, and keep the audit trail continuous across the join. Cancel nothing until the replacement has run a full case end to end.
Key takeaways
- The structured data usually moves cleanly. The unowned data is what causes the pain.
- Decide what's authoritative before you move anything. 2 half-right systems is the worst state to be in.
- Migrate in phases with a clear cutover for each, not in 1 weekend.
- Your audit trail has to survive the join. A file from before the move must still be complete and retrievable after it.
- Keep the old subscriptions running until a full case has gone through the new system, start to finish.
Why consolidation is worth doing at all
Every extra system in an advice firm is a copy of the truth that can drift. The same client's address in 4 places means 3 of them are eventually wrong, and you won't find out from a report, you'll find out from a client.
The cost isn't the subscriptions. It's the re-keying, the reconciliation, and the quiet risk that the version you used for the recommendation wasn't the current one. Consolidation removes copies. That's the whole benefit, and it's a bigger one than the invoice saving people usually lead with.
What breaks when firms consolidate their software?
I've seen the same 5 failures. None of them are the client database.
1. The data nobody owns. Fee agreements in a shared drive. A risk questionnaire in a form builder. Review dates in someone's calendar. It's real firm data, it's needed by the new system, and no vendor's import tool knows it exists because you never told anyone it did.
2. Fields that mean different things. Your CRM's "review date" is the anniversary. Your workflow tool's "review date" is when the pack goes out. Map them naively and every client's review lands a month early or late.
3. Free text carrying facts. Notes fields hold vulnerability indicators, capacity for loss commentary, family context. They migrate as a blob and stop being findable, which matters more than it sounds when you need to evidence how you treated a vulnerable client.
4. Partial adoption. Half the team moves, half don't, and for 6 weeks nobody knows which system is right. This causes more damage than a botched import, because a botched import is obvious and this isn't.
5. The join in the audit trail. Records from before the move sit in a system you've cancelled. If you can't produce a complete file across the boundary, you've created a compliance problem while trying to solve an efficiency one.
Step 1: inventory what you hold
Before any demo, list every place firm data lives. Every one, including the embarrassing ones.
For each, write down: what it holds, who owns it, whether anything downstream depends on it, and whether it's the authoritative copy or a copy of something else. A shared document is fine for this. The point is that the list exists before a vendor sees it, so you're negotiating from a known position instead of discovering scope halfway through.
Expect the list to be longer than you thought. Once the spreadsheets, shared drives and form builders are counted, the number climbs fast, and finding that out during a migration is far more expensive than finding it out now.
Step 2: decide what's authoritative
For every field that appears in more than 1 system, pick the winner and write it down. Client address: the back office. Fee basis: the signed agreement, transcribed into the record. Review date: define which meaning you're using, then apply it everywhere.
This is the step firms skip, and it's the step that decides whether the migration works. A mapping document nobody argued over is a mapping document that encodes an assumption someone will discover later, in front of a client.
Where 2 systems disagree, don't let software resolve it. A wrong value that arrives silently is worse than a gap that shows up as blank, because a gap gets fixed and a wrong value gets used.
Step 3: move in phases
Phased means each phase has its own cutover, and after that cutover there's exactly 1 system anyone touches for that job.
A sequence that works for most small firms:
- New cases only. Everything starting from today runs on the new platform. Existing work in flight finishes where it started. No migration risk at all, and the team learns on live work with a safety net.
- Active clients. Migrate the clients with something scheduled in the next 2 quarters. This is the set where data quality matters most and where errors surface fast, while you still have the old system to check against.
- The remainder. Everyone else, in batches, with a reconciliation check on each batch.
- Historic records. Usually an export and archive rather than a live migration. Decide the format and test that you can retrieve a full file from it before you cancel anything.
Do not run 2 systems as equals in the same phase. Parallel running is for checking, not for working. If both accept new data, you've built a reconciliation job that runs forever.
Step 4: keep the audit trail continuous
Agree in writing, with whoever provides your compliance oversight, how records from before the move stay complete and retrievable after it. That means:
- A tested export in a format you can still open in 6 years, not a proprietary one you can only read with a licence you're about to cancel.
- A documented note of what moved, what was archived, and where each lives. Written at the time, because nobody remembers this accurately a year later.
- A retrieval test: pick 3 old cases at random and produce the full file from the archive. If you can't, you don't have an archive, you have a backup you've never opened.
Your record-keeping obligations don't pause for a migration, and UK GDPR still applies to what you copy, keep and delete along the way. A migration is a good moment to delete what you shouldn't still hold, and a bad moment to copy everything into a new place without deciding.
Step 5: cancel nothing early
The saving is the reason the project got approved, so there's pressure to cancel fast. Don't.
Run 1 complete case through the new platform first, from enquiry to signed recommendation to file. Then keep the old subscriptions for at least one full billing cycle after that. The overlap costs 1 or 2 months of a subscription you were going to stop anyway. Discovering in month 3 that a report template only existed in the old system costs considerably more.
What to ask the vendor to do
Get specific answers before you commit:
- Who does the mapping? If the answer is "we provide a template", you're doing the mapping.
- What happens to unmapped fields? They should surface as a list you review, never be dropped silently.
- Can I do a trial import and throw it away? A vendor confident in their tooling will let you load a copy, inspect it and reset.
- What does the rollback look like? If there isn't one, the phase is too big.
- How do I export everything, and what does it cost? Ask on the way in, because the answer changes on the way out.
Frequently asked questions
How long does it take to move an advice firm onto one platform?
Plan 2 to 3 quarters for a small firm using the phased approach, with new cases moving in the first few weeks and historic records last. The calendar time is dominated by data cleansing and by running the phases at a pace that doesn't disrupt client work, not by the technical import, which is usually days.
Should I migrate all my client data at once?
No. Move new cases first, then clients with something scheduled soon, then the rest in batches. A single big-bang import gives you no way to catch a mapping error before it has touched every record, and no way back if you find one.
What happens to my old records if I cancel the software?
That depends entirely on the contract, so read it before you sign the new one. Export everything in an open format, test that you can retrieve a complete client file from the export, and document where the archive lives. Your obligation to produce records outlasts your subscription.
Can I keep my back office and still consolidate everything else?
Yes, and for many firms it's the lower-risk route. If the client record is fine and the pain is in the work on top of it, add a platform that reads and writes to your back office instead of replacing it. You get the consolidation benefit on the parts that hurt without a system-of-record migration.
What's the most common migration mistake?
Not deciding what's authoritative. Firms map fields by name, discover 2 systems used the same name for different things, and only notice when a review date or a fee is wrong on a live client. 1 afternoon spent writing down which system wins for each field prevents most of it.