Firms do not change their onboarding platform because they are bored of it. They change because the system they have outgrown has started to cost them something, in analyst hours lost to manual workarounds, in audit findings that keep recurring, in the quiet erosion of confidence that the client record in front of them is actually complete. By the time a migration is seriously on the table, the case for moving is usually settled. What is rarely settled, and what tends to keep compliance officers awake the week before go-live, is how to move years of client due diligence from one platform to another without dropping a single obligation on the floor.
A migration of this kind is not a software swap. It is the wholesale transfer of the evidence that demonstrates your firm has met its regulatory obligations, carried out across live client relationships that do not pause while you switch systems. Customer Due Diligence (CDD) records, beneficial ownership structures, screening histories, periodic review schedules, and the audit trail that ties them all together must arrive intact, attributed correctly, and ready to stand up to scrutiny on the other side. Done well, the process is almost invisible to clients and leaves the firm in a demonstrably stronger position. Done badly, it introduces exactly the gaps a regulator is trained to find.
Over years of working with regulated firms across Jersey, Guernsey, the UK, and other international finance centres, a pattern has become clear: the migrations that go smoothly are the ones treated as a compliance project with a technology component, rather than a technology project with a compliance footnote. The firms that come unstuck are almost always those that underestimated the data or assumed the new platform would simply absorb whatever the old one handed over. What follows is a staged way of thinking about an onboarding platform migration, drawn from how these projects actually unfold rather than how a Gantt chart imagines they will.
Why are onboarding platform migrations so easy to underestimate?
The difficulty is rarely the new platform. Modern onboarding technology is designed to be adopted. The difficulty is everything the old platform has accumulated, and the fact that a regulated firm cannot simply archive it and start fresh.
Consider what a single corporate client relationship contains after a few years on a platform. There is the original CDD, the identity evidence gathered at onboarding, the ownership structure with its Ultimate Beneficial Owners (UBOs) mapped and verified, the Politically Exposed Persons (PEPs) and sanctions screening results, the risk rating and the rationale behind it, every periodic review since, and the documents and decisions attached to each. Multiply that by a book of several hundred or several thousand relationships, many of them layered entities rather than individuals, and the scale of what is being moved becomes clear. A migration is not moving a list of clients. It is moving the lifecycle of each one.
This is why migrations are underestimated. The visible work, configuring the new system, looks like the whole job. The real work is reconstructing the integrity of the record. A firm that treats the project as the former and discovers the latter halfway through is the firm that ends up running two systems in parallel for far longer than planned, paying for both, and trusting neither.
Stage one: establish why you are moving, and what good looks like
Before any data moves, the firm needs a clear and documented account of why it is migrating and what the new platform must do that the old one could not. This sounds obvious, and it is routinely skipped. Yet it is the single most useful artefact in the entire project, because every later decision, what to migrate, what to leave behind, how to configure risk models, where to draw the line on data cleansing, gets measured against it.
A good statement of intent is specific. "The current system cannot support multi-jurisdictional risk models, forces analysts to re-key UBO data already held elsewhere, and produces an audit trail our last examiner found difficult to follow" is something a project can be steered by. "We want something better" is not. This is also the right moment to involve the people who will live with the new system every day. The compliance analysts who know precisely where the old platform creaks will surface requirements that no procurement document captured, and their buy-in is what turns a mandated change into an adopted one.
If your firm is still weighing whether to move at all, it is worth working through whether to build a replacement or buy one before committing to a migration, and being clear on how to assess a platform on its merits once you do.
Stage two: audit and cleanse the data before it moves
A migration is the best opportunity a firm will ever have to understand the true state of its client data, and the worst time to discover that state is poor. The instinct to move everything, immediately, on the assumption it can be tidied later, is the instinct to resist most firmly. Data that is incomplete, inconsistent, or duplicated on the old platform does not improve by being copied. It simply becomes the new platform’s problem, with the added confusion of no longer being where anyone remembers leaving it.
The disciplined approach is to audit first. Map what you hold, identify the gaps, the duplicate entities, the records where a periodic review is overdue, the UBOs verified to a standard you would no longer accept, and decide deliberately what happens to each category. Some records will migrate cleanly. Some need remediation before they move. Some, dormant or closed relationships retained only for record-keeping, may not belong in the live system at all and can be archived in line with your retention obligations. Making these decisions consciously, and documenting the rationale, means the migration becomes an act of strengthening the book rather than merely relocating it.
This stage is also where the structural complexity of regulated client bases reveals itself. A trust with a corporate trustee, underlying companies, and beneficiaries across several jurisdictions does not map neatly from one platform’s data model to another. Funds with layered ownership, nominee arrangements, and look-through requirements are harder still. The mapping between the old structure and the new one has to be worked out explicitly, entity type by entity type, rather than assumed. The firms that invest here are the ones whose data arrives meaning the same thing on both sides.
Stage three: configure the new platform to your obligations, not to the old defaults
It is tempting to configure the new platform to mirror the old one, on the reasoning that staff already understand the existing setup. This is usually a mistake. The old configuration is, after all, part of what you are leaving behind. A migration is the moment to set up risk models, screening parameters, workflow rules, and review cycles to reflect your firm’s obligations as they are now, across every jurisdiction you operate in, rather than to replicate decisions made years ago for reasons no one can fully reconstruct.
For firms operating across the Channel Islands and the UK, this is where multi-jurisdictional configuration earns its keep. The obligations a relationship attracts can differ depending on jurisdiction, sector, and risk, and a well-configured platform should encode those differences so that the right level of due diligence is applied automatically rather than left to an analyst’s memory. Every jurisdiction a firm operates in maintain their own handbooks and expectations, and a platform configured to a single generic standard will inevitably either over-burden low-risk relationships or under-serve high-risk ones.
Configuration is also where the audit trail is either built in or bolted on. The new platform should record who did what, when, and why, automatically and immutably, from the first day of live operation.
Stage four: migrate in controlled phases, and run in parallel
The actual transfer of data should almost never happen as a single overnight event for a regulated firm of any size. The more defensible approach is a phased migration, moving a controlled subset of records first, validating them thoroughly, and only then proceeding. A sensible first phase is a representative sample that includes the awkward cases, the layered entities, the high-risk relationships, the records with extensive screening histories, precisely because those are where mapping errors surface. If the difficult records migrate cleanly, the straightforward ones almost certainly will too.
Running the old and new platforms in parallel for a defined period is the safety mechanism that makes the whole project defensible. During parallel running, the firm can verify that migrated records are complete and accurate, that workflows behave as expected, and that nothing has been silently lost or transformed in transit. It is during this window that the data audit pays off, because you have a clear specification of what should have arrived and can check the reality against it. Parallel running costs money and patience, and the temptation to cut it short is real. It is also the single thing most likely to catch a problem while it is still cheap to fix.
Validation during this stage should be structured rather than impressionistic. Reconciling record counts, spot-checking high-risk relationships in full, confirming that ownership structures resolved correctly, and verifying that screening histories transferred with their dates and outcomes intact are the kinds of checks that distinguish a migration the firm can stand behind from one it merely hopes went well.
Stage five: cut over, then review honestly
The cutover, the point at which the new platform becomes the system of record and the old one is decommissioned, should be the least dramatic moment of the project if the earlier stages were done properly. By the time you switch off the old system, you should already know, from parallel running, that the new one holds everything it needs to, correctly.
What matters after cutover is resisting the urge to declare victory and move on. A migration is not finished when the data lands; it is finished when the firm has confirmed, through use, that the new platform supports its obligations in practice. The first periodic reviews run on the new system are a particularly useful test, because they exercise the migrated data in anger and reveal anything that looked fine at rest but behaves oddly in motion. They are also a reminder that a periodic review is a substantive obligation, not an administrative refresh, a distinction worth holding onto well beyond the migration itself.
A short, honest post-migration review, what went as planned, what did not, what the firm would do differently, is worth the hour it takes. It is also exactly the kind of documentation an examiner appreciates, because it demonstrates that the firm treated the change in its compliance infrastructure with the seriousness that infrastructure deserves.
How the stages hold together
It is tempting to read these stages as a checklist, each one completed and set aside before the next begins. In practice they reinforce one another, and their interdependence is the real lesson. The statement of intent in stage one is what makes the configuration decisions in stage three defensible. The data audit in stage two is what makes the validation in stage four possible. The parallel running in stage four is what makes the cutover in stage five uneventful. Skip or rush any one of them and the weakness surfaces later, usually at a point where it is more expensive and more visible to fix.
The firms that handle migration well are not the ones with the largest budgets or the newest technology. They are the ones that understood, from the outset, that they were moving the evidence of their compliance rather than merely changing a tool, and who gave that evidence the care it warranted at every stage. The reward is not just a working platform. It is a client book that is cleaner, better understood, and more defensible than it was before the migration began.
For any regulated firm planning a move between onboarding platforms, treating the project as a staged compliance exercise rather than a technology cutover is the lens that tends to keep it safe. If you would like to discuss how Vaiie supports regulated firms with client lifecycle management and onboarding, from data migration and multi-jurisdictional configuration through to ongoing monitoring, we would be glad to hear from you.
Frequently asked questions
How long does an onboarding platform migration take?
It depends far more on the state and complexity of your data than on the new platform itself. A firm with a clean, well-structured book of mostly individual clients can move in a matter of weeks; a firm with thousands of layered entities, trusts, and funds, and years of inconsistent record-keeping, should plan for several months, much of it spent auditing and remediating data before anything moves. The phased approach and parallel-running period described above add time deliberately, because they are what make the migration defensible.
Will we lose any client due diligence records during migration?
You should not, provided the migration is treated as a transfer of compliance evidence rather than a simple data copy. The safeguards that prevent loss are a thorough data audit before moving, a phased migration that validates a representative sample first, and a period of parallel running during which migrated records are reconciled against a clear specification of what should have arrived. Records are lost when firms skip these steps and discover gaps only after the old system is switched off.
Should we migrate all our data or only part of it?
Not everything necessarily belongs in the live system. A migration is the right moment to decide deliberately what to carry forward, what to remediate first, and what, such as dormant or closed relationships retained only for record-keeping, to archive in line with your retention obligations rather than move. Copying incomplete or duplicated data simply relocates the problem, so the decision should be made consciously and documented rather than defaulted to "move everything".
What is parallel running, and why does it matter?
Parallel running is the period during which the old and new platforms operate alongside each other before the old one is decommissioned. It matters because it is the firm’s opportunity to confirm, through use, that migrated records are complete and accurate and that workflows behave as expected, while the old system is still available as a reference. Cutting it short to save time and cost is the most common way a migration problem goes undetected until it is expensive to fix.
Can we keep operating normally during the migration?
Yes, and this is precisely why migrations are demanding: client relationships do not pause while you switch systems. New onboarding, periodic reviews, and screening all continue throughout, which is part of the reason a phased migration and parallel running are sensible rather than a single overnight switch. A well-planned migration is close to invisible to clients.
