Exchange Migration and Handover

Not every exchange begins from nothing. Many of the most consequential projects an operator undertakes involve an existing, running platform: moving it to new infrastructure or new software, or taking over responsibility for a platform someone else built and operated. These are migration and handover, and they are a different discipline from building fresh. The work is done on a live system that already holds customer balances, open positions and records, where a mistake is immediately visible and directly costly. The value at stake is continuity, and the challenge is to change the foundations of a business without interrupting the business itself.

Migration and handover, though related, are distinct events. Migration is the movement of an operating exchange — its data, its assets and its running services — from one system, provider or infrastructure to another. Handover is the transfer of responsibility and control: the point at which one party takes over the source code, the operation and the knowledge needed to run and extend the platform from another. They frequently happen together, as when an operator moves off a hosted white-label arrangement and onto source code it owns, but they are not the same thing and each carries its own risks.

The decision reaches every part of the business. For a chief executive it is a question of business continuity, of cost and of the reputational risk that downtime or lost balances would bring. For a technology leader it is a demanding exercise in data integrity, sequencing and taking ownership of an unfamiliar system. For a compliance or finance function it is a test of whether client-asset accounting and the audit trail survive the move intact. This article sets out how to think about migration and handover at the level of planning, risk and provider evaluation, rather than offering a cutover runbook or a data-migration recipe.

Why Migration and Handover Matter

A migration is unlike a greenfield build because it is performed on a business that is already trading. Customers expect uninterrupted access to their accounts and assets, and they judge the operator by whether that expectation holds. A move that is planned carelessly risks downtime, data loss, reconciliation gaps and a loss of trust that is hard to recover, and it does so at the moment the platform is most exposed. The reason to treat migration as a deliberate programme, rather than a technical task to be rushed, is precisely that the cost of getting it wrong lands directly on live customers.

Handover matters for a different reason. An operator that takes over a platform without also receiving the knowledge, documentation and operational understanding to run it has gained files rather than control. The purpose of taking ownership — often the whole point of moving from a hosted arrangement to owned source code — is to be able to run, extend and support the platform independently. A handover that stops at delivering code leaves the operator dependent in all but name, and the reasons behind the move, whether outgrowing a platform, changing providers or shifting regulatory posture, shape how complete that transfer needs to be.

Exchange Migration and Handover Defined

Migration, in this context, means moving an operating exchange from where it runs now to somewhere new. It can be an infrastructure migration, where the platform moves between data centres or hosting environments while the software stays the same; a platform migration, where the operator moves from one software system to another; or both at once. In every case the defining feature is that real data, real balances and real customers come along, so the move must preserve them exactly rather than simply reproduce a feature set.

Handover means the transfer of responsibility and the capacity to exercise it. Where migration moves the thing, handover moves the accountability for it: the source code, the operational understanding and the ability to build, deploy, operate and extend the platform pass from a vendor or previous operator to the new one. The distinction drawn in the discussion of crypto exchange software between a hosted white-label service and owned source code is the setting where handover most often arises, because moving to ownership is only real when the handover is complete enough to run the platform without the party that built it.

Moving Data and Assets Without Loss

The hardest part of a migration is moving data completely and accurately. Customer records, account balances, ledger history, transaction history and KYC and AML records all have to arrive intact, and the balances above all: the recorded balances on the new system must reconcile exactly to what customers are owed and to what the platform actually holds. A discrepancy here is not a cosmetic defect but a direct harm, because it means a customer's stated balance no longer matches reality. Reconciliation before, during and after the move is what turns a data transfer into a trustworthy one.

Asset migration is a distinct and especially sensitive strand. Moving control of on-chain assets is not the same as copying a database, and how it is approached depends heavily on the custody model the platform uses and on who holds the keys. The relationship between the balances a platform records and the assets it actually controls, which underpins any exchange, must hold true on the far side of the move as firmly as it did before. This article stays at the level of what has to be preserved and evidenced rather than how keys are handled, but the principle is constant: nothing may be lost, duplicated or left unaccounted for.

Planning the Cutover and Continuity

A migration is a planned event rather than a switch to be flipped. The planning centres on minimising disruption to a live business: deciding how much downtime, if any, is acceptable, how customers are kept informed, how the move is sequenced, and — most importantly — how to reverse course if something goes wrong. A migration undertaken without a considered fallback position is a gamble with customer assets, because it assumes an outcome it cannot guarantee and leaves no way back if that assumption fails.

Confidence before commitment is the discipline that separates a controlled cutover from a hopeful one. The moved data and the reconciled balances should be validated on the new system before the old one is retired, and the cutover should be treated as reversible until that confidence is established. Rehearsing the move, rather than performing it for the first time in production, is how an operator learns where it breaks without customers bearing the consequences. These are matters of planning posture and provider capability; the detailed sequence belongs to the delivery itself, not to a decision-level view.

Handover of Responsibility and Ownership

A genuine handover delivers far more than a copy of the source code. Receiving code without the documentation, the operational knowledge and the understanding needed to run it is a hollow transfer that leaves the operator holding something it cannot actually use. A complete handover includes the ability to build, deploy, operate, extend and support the platform independently, so that ownership translates into control rather than a new form of dependency dressed up as a transfer. This is where owning the platform, examined in the comparison of building against adopting an existing platform, becomes concrete.

How a provider approaches handover is therefore one of the more revealing things to evaluate. A provider that delivers something the operator can genuinely own and run — with documentation, knowledge transfer and a period of support through the transition — is offering a different proposition from one that hands over files and withdraws. The underlying technology matters here too, because a platform built to be understood, deployed and extended by its owner is far easier to hand over cleanly than one that only its original builder can operate. The question to ask is not merely whether code will be delivered, but whether the operator will be able to stand on its own once it is.

Where Risk Sits During a Move

Migration concentrates risk into a window of time. During the move the live business is at its most exposed, and the principal risks cluster there: data loss or corruption, balance discrepancies, extended downtime, security exposure while assets are in motion, and the possibility of being unable to roll back. Each of these strikes a running platform directly, which is why the move is planned around containing them rather than assuming they will not occur. The window is where a migration is won or lost, and shortening and de-risking it is much of the work.

Handover carries a quieter but no less serious risk: an incomplete transfer that leaves the operator unable to run what it now owns, dependent on the previous party for the very independence the move was meant to secure. Neither kind of risk is removed by planning; it is managed by reconciliation, rehearsal, a fallback position and a transfer thorough enough to stand on. Throughout, the operator remains accountable to its customers and its regulators. A migration does not pause those obligations, and responsibility for the customer relationship stays with the platform even while its foundations are being moved.

Migration and the Regulatory Frame

The duty to account for customer assets does not pause during a migration, which is why a move is not only a technical undertaking. In the United Kingdom, the framework around cryptoasset and payment firms places weight on knowing what is owed to customers and being able to reconcile it against what is held, with strengthened safeguarding expectations reinforcing that customer assets are accounted for and kept appropriately apart; those expectations apply during and after a move, and the records and audit trail must survive the migration intact. In the European Union, the cryptoasset regime that now applies to authorised providers treats custody of client assets as a regulated activity. The MiCA transition has ended, and new EU cryptoasset projects must be designed for an authorised CASP operating model from the beginning, so a migration into or within the EU has to land on that model rather than defer it.

A migration that breaks the continuity of records or the reconcilability of balances is therefore a regulatory problem as much as a technical one, because it undermines the evidence a firm relies on to show control over customer assets. Grumpio's position on this is deliberately bounded. We do not provide legal opinions or guarantee authorisation. We implement regulatory and audit requirements across technology, infrastructure and operations. How the continuity of client-asset accounting through a move sits alongside the wider obligations a regulated platform is expected to meet is developed further in the regulatory readiness pages, which treat control over client assets as one component of a broader readiness posture rather than an isolated feature.

Summary and Next Steps

Exchange migration moves a live platform's data, assets and services from one home to another, while handover moves the responsibility and the capacity to run it. Both are planned events, reversible where they can be, that concentrate risk onto a business that is already trading. The quality of a move lies in the completeness of the data and asset migration and the reconciliation that proves it, in a cutover plan that keeps a fallback in reserve, and in a handover that leaves the operator genuinely able to own and run the platform rather than dependent in a new guise. It is closely tied to the continuity of client-asset accounting and to the regulatory expectation that records and reconciliation survive the move. The strongest position is one in which an operator controls the move on a platform it owns. Do not buy software alone. Buy the process that makes it work. A migration is judged not by the day the switch is thrown but by whether the business it carries emerges whole.