The single most common misconception about moving a fund onto tokenized infrastructure is that the fund's securities must somehow be reissued — that investors will be asked to surrender one instrument and accept another, with all the legal and tax anxiety that implies. That is not what happens. A migration is a registrar change: the fund's official ownership records move from one recordkeeper to another. There is no reissuance, and no change to the security itself. The LP's interest — the same units, the same rights, the same economics defined in the same LPA — is untouched. What changes is who maintains the register and how well the register works.
The precedent is a century old
Public companies change transfer agents routinely. When they do, nobody's stock is reissued; the incoming agent takes over the securityholder file, reconciles it against the outgoing agent's records, and continues the register from that point forward. A tokenized fund migration follows exactly the same pattern. The novelty is not the legal mechanics — it is that the incoming register happens to be one where transfer restrictions, holder eligibility, and audit anchoring are enforced in the data model rather than checked after the fact.
The mechanics, step by step
A recordkeeping migration onto AKRU runs as a structured implementation with hard compliance gates — five of them, each requiring written clearance before the next phase begins. The ones that matter most for migration are the reconciliation gates.
First, the prior records are extracted: the cap table, capital account histories, distribution records, and investor files from the outgoing administrator, whether that is a legacy platform, a fund administrator's system, or a set of spreadsheets. Second, every holder is re-verified — KYC, sanctions screening, and, for 506(c) funds, accreditation status — so the new register starts clean rather than inheriting stale eligibility data. Third, the incoming register is reconciled against the outgoing records position by position, LP by LP, down to the capital account level. In AKRU's implementation playbook this reconciliation is a formal gate: prior-admin records must tie to the AKRU ledger before launch authorization is issued. Fourth, the register goes live, and from that point every transaction posts to one event fabric with a single source of truth.
The scale of this is proven, not theoretical. AKRU has executed a registrar change covering 549 limited partners from a prior tokenization platform — with the LPs' interests continuing uninterrupted and per-distribution processing costs on the new register of $0.01. Sponsors who ran the old and new stacks side by side report admin-time reductions of roughly 87%.
What the LP experiences
Almost nothing, which is the point. The LP receives a notice that the fund's recordkeeping is moving, completes a verification step if their KYC or accreditation file needs refreshing, and gains access to a portal where their commitment, capital account, distribution history, and K-1s are current and self-service. Their units were never touched. Their basis, holding period, and tax position are unaffected, because a registrar change is an administrative event, not a disposition. Counsel should always confirm the specifics for a given fund, but the structure of the transaction is designed so that there is nothing to dispose of.
Where migrations actually go wrong
The failure modes are operational, not legal. Records that don't reconcile — a capital account that disagrees with the sum of its transactions, a distribution that was paid but never booked. Holder files with expired accreditation quietly grandfathered in. A cutover with no parallel period, so discrepancies surface after the old system is gone. The discipline that prevents all three is the same: reconcile before cutover, gate the launch on written clearance, and keep an audit trail of every record change with timestamps and approver identity. That discipline is what a registered transfer agent brings to the process — AKRU's SEC transfer agent registration is effective July 4, 2026 — and it is why migration on this platform is a gated project with defined exit criteria rather than a data import.
For real estate sponsors, the migration question usually arrives mid-fund: an active vehicle, distributions flowing, K-1 season looming. The registrar-change model is built for exactly that situation — records move, operations continue, and nothing about the security changes. The sponsor's communication burden is correspondingly small: one notice, one verification step where files need refreshing, and a portal that works better than what it replaced. In practice the migration is the quietest infrastructure change a fund can make, precisely because it is the most precedented one.
Frequently asked questions
Does a migration change my investors' securities?
No. A registrar change moves the fund's records to a new recordkeeper. There is no reissuance and no change to the security itself — the same interests, rights, and economics continue under the new register.
How long does a recordkeeping migration take?
It runs as a gated implementation: records extraction, holder re-verification, position-by-position reconciliation, and a launch clearance that only issues when prior records tie to the new ledger. The reconciliation gates are the schedule drivers — clean records move fast; messy records get fixed before cutover rather than after.
Can we migrate mid-fund, with distributions in flight?
Yes — that is the common case. The parallel reconciliation period is designed so that in-flight distributions and capital activity are captured in both records until the registers tie, then operations continue on the new register without interruption.
Related reading
What a transfer agent does for a tokenized fund
Choosing deployment: full platform vs modular vs white-label vs API-first