Migrate an existing fund

Before you start

The fund record and its investors must already exist in NAVdryx, along with any GP or management-company commitments, because the history and the opening balances refer to them. Every investor who will get a migrated commitment needs approved KYC on their investor record: a migrated commitment has no subscription packet, so no review stage runs KYC for it. The fund must have no capital-account runs yet, and no live capital events dated on or before the cutover.

You need two dates. The inception date is the first day of the fund’s history, and the cutover is the last day the previous system’s books cover. The cutover can’t be in the future. From the previous administrator, collect the commitment register, every capital event from inception to cutover, and each party’s inception-to-date capital account at the cutover.

Steps

1. Open the migration. On the fund’s capital activity page, follow the Fund migration link and enter the two dates. A fund accountant, fund administrator, or fund controller can open it. A fund is migrated once, and the dates can’t be changed afterwards. From then on, a live capital event must be dated after the cutover, and live capital-account runs wait until the migration is locked.
2. Import the commitment register. On Imports, choose the commitment register kind and the fund being migrated. Each row names an investor (by its investor register ID, or by a legal name that matches exactly one investor), the amount, the currency, and an admission date on or before the cutover. Promoting it records each commitment with the register as its evidence; no subscription packet, review stage, or signature is created.
3. Import the capital history. One row per party per event, grouped by an event reference that can be imported once per fund. All seven event types are accepted — contributions, distributions, in-kind contributions and distributions, transfers, recallable distributions, and tax distributions — for LPs, the GP, and the management company. A recall is a recallable distribution with negative amounts. Promoting the import creates draft events. Then, on the migration page, a fund manager or fund controller who did not upload the file approves that import’s history in one step. Approving it notifies nobody.
4. Import the opening balances. One row per party, even when every figure is zero: inception-to-date net transfers, contributions, ordinary, in-kind, tax, and recallable distributions, income or loss, expenses, the ending balance, the unfunded commitment, and the recallable headroom. The calculation engine checks that each row foots exactly to its ending balance, that net transfers net to zero across the fund, that the recallable headroom does not exceed the recallable distributions, and that the unfunded commitment is neither below zero nor above the commitment plus that headroom. One bad row refuses the whole statement. Promoting it creates the fund’s opening capital-account run in draft, which is submitted for review and approved on the fund’s capital accounts page. Only a fund controller can approve it, and not the person who uploaded the opening balances.
5. Check the tie-out. The engine compares each party’s opening net transfers, contributions, and each type of distribution with the approved history, and the migration page lists every difference. Income, expenses, and the ending balance are not compared, because the history holds capital events only.
6. Lock the migration. A fund controller locks it once the opening run is approved, no imported history is still a draft, and the opening ties out to the approved history. An opening that states no contributions, distributions, or transfers ties out with no history at all. Locking makes the opening balances the fund’s starting capital accounts, closes the accounting period from inception to cutover, and ends migration imports for the fund. Live capital-account runs start the day after the cutover.

Every import is promoted by someone other than the person who uploaded it, saved its column mapping, or validated it — see Import data. The imported history and the opening run each count the uploader as their preparer, so the controller who promoted them can approve them: a migration needs at least two people.

How migrated history behaves

Migrated history is a record of what already happened, so it never runs the live lifecycle. It is never noticed, sent, settled, or reconciled, approving it sends no notification or push, and it never appears on an LP’s capital activity page. It cannot be reversed, and it cannot source receivables, payables, payment batches, or notice PDFs. Performance and DPI take paid-in capital and distributions from this history, which is why a migration with an opening that states contributions or distributions cannot lock without it.

Correcting a migration

• A wrong history import. While the migration is open, a fund manager or fund controller who did not upload it voids the import’s history from the migration page, approved or not. The voided events leave the tie-out, performance, and DPI, and their event references are freed, so the corrected file can be imported and approved again.
• Wrong opening balances. Import them again; the new opening run replaces the earlier one. If the fund’s commitments change after the opening balances were computed, the migration page says so, and the opening has to be imported again before the migration can lock.
• Abandoning. A fund controller can abandon an open migration. Every imported history event is voided and every opening run retired, so nothing from the migration reaches capital accounts, performance, DPI, or reports. Abandoning is refused once any commitment has been recorded from the register, because those commitments can’t be removed; from then on the way out is to complete and lock the migration. Abandoning is final: the fund can’t be migrated again.

What a migration does not bring over

The opening balances are capital accounts only; tax basis is not imported. Chart of accounts and trial balance imports can be staged and validated, but promoting them is not yet available, so the previous system’s ledger and opening trial balance stay outside NAVdryx. Fund migration is not available in the demo workspace.