The intelligence platform
The Family Office Stack/Analysis/Family Office Software Implementation Checklist for…

Family Office Software Implementation Checklist for a Defensible Go-Live

The migration can finish on schedule and still produce the wrong family report.

Black-and-white office desk with laptop, financial reports and entity-mapping papers; no title overlay.
Operations & Governance

The migration can finish on schedule and still produce the wrong family report. A custodian feed may reconcile, while an investment already on an entity's books enters the consolidated view a second time. The office needs proof that the new system can carry a complete reporting cycle without silently changing what a number means.

This family office software implementation checklist treats go-live as an evidence decision. It identifies what must be mapped, tested and signed off before the old workflow loses authority. The exact scope depends on whether the new platform will own the legal-entity books or add a reporting layer over books kept elsewhere.

The short version
  • Name the authoritative data source for each transaction, entity balance and ownership percentage, then name who produces and approves each report.
  • Reconcile the same dated close in both workflows, then test a deliberately difficult exception—not just a dashboard that looks right.
  • Record pass/fail evidence, the exception owner and the authorized go/no-go decision. Keep a controlled old-system route until cutover and recovery tests pass.

01Seven Gates Before the CFO Go/No-Go Decision

Use these gates as a working checklist. The evidence and thresholds are office-set. Each gate owner signs their test evidence; the CFO or authorized business owner accepts the aggregate go/no-go decision. A vendor's “implementation complete” notice does not sign for the family office.

  1. Scope and authority. Evidence: a signed phase-one list of entities, books, feeds, historical periods, outputs and record owners. Signer: CFO or delegated project owner. No-go if: an authoritative ledger or report owner remains undefined.
  2. Entity and holding map. Evidence: source-to-target mapping for legal owner, look-through percentage, instrument identity, date and valuation basis, tested on a representative entity. Signer: controller plus investment-data owner. No-go if: ownership or duplicate holdings can change a family total without an exception.
  3. Migration reconciliation. Evidence: agreed counts, opening balances, transactions and unresolved-difference log at one cutover date. Signer: controller. No-go if: a material balance or transaction difference is unexplained. Apply ledger-specific checks only when the books move.
  4. Report acceptance. Evidence: old and new report outputs on the same date and basis, with source-to-report trace for every material line and a signed disposition of differences. Signer: report owner. No-go if: a material entity or family number remains wrong; the worked LP case below fails here.
  5. Feeds and access. Evidence: a dropped or delayed feed is flagged, a retry preserves lineage, and negative permission tests block unauthorized view, change and export. Signer: data-operations and security owners. No-go if: a feed gap goes unflagged or any prohibited view, change, approval or export succeeds.
  6. Users and first-cycle support. Evidence: named users perform their actual close and review tasks, training gaps are recorded, and a support owner, escalation route and response window cover the first live cycle. Signer: COO or operations lead. No-go if: a critical task depends on an untrained or unavailable person.
  7. Cutover and recovery. Evidence: rehearsed freeze, final delta import, sign-offs, rollback trigger and a plan to capture and reconcile post-freeze activity. Signer: CFO with technical lead. No-go if: the office cannot restore an authoritative workflow after a failed launch.

A conditional pilot can expose a labeled, non-authoritative view to a limited team. It is not permission to send a failed family report or move the official books. Record the acceptance evidence, residual defects and the person who authorized that limited use.

Decision diagram for test RPT-07: a US$4.0m duplicate family exposure blocks report release; a traced and signed US$2.0m retest permits go, while any pilot remains internal.

Open the full-width desktop diagram. The RPT-07 failure blocks the family report; the corrected source trace and gate-owner signatures allow Gate 4 to pass. The other gates still apply.

02Decide What Is Actually Going Live

An accounting replacement and a reporting overlay have different completion tests. If the new platform becomes the official ledger, opening balances, chart-of-accounts mappings, journal permissions, intercompany balances and close reports need approval. If it is a reporting layer, the existing ledger remains authoritative; ingestion, ownership look-through, valuation dates and report calculations need validation. A portal may be ready for secure document access before its wealth report is ready for family distribution.

Write the phase-one scope as named outputs rather than features. For example: “The April entity trial balances remain on the existing ledger; the new system will produce a 31 March family exposure report for four named entities. The principal will not receive a current net-worth total until source dates and private holdings reconcile.” That is a fictional scope, not a recommended cutover date.

The FundCount implementation guide lists an entity chart, current report pack, trial balances, custodian files and private-investment samples as preparation inputs, and advocates validating a model entity before expanding. Its product-specific method is useful as a scoping prompt; the office still has to choose its own system-of-record and acceptance rules. Addepar's family-office description likewise says implementation varies with legacy data, custodial feeds and historical migration. No vendor timeline is a substitute for a tested office-specific scope.

Before configuration starts, attach the phase-one entity and account list, current report pack, source inventory and permission matrix to the signed scope. Name which reports are deferred and who can accept each exception. The seven gates above turn those boundaries into a release decision.

03Inventory the Sources and Map Each Record Once

Create a source-to-target inventory before importing a holding. One row should identify the source file or connection, source owner, date and currency, legal owner, instrument, target entity, target account or holding, transformation rule, refresh cadence, reviewer and expected report. Keep the source document and a version of the mapping, so a later disagreement can be traced.

Separate configuration—entities, chart of accounts, ownership percentages, roles and report rules—from migrated data such as opening balances, transactions, tax lots, private-fund commitments and documents. Microsoft's implementation guidance makes that distinction and calls for mapping, testing and verification in integration and user-acceptance environments. The page is about Dynamics 365; the transferable principle is that a correct import cannot rescue an incorrect configuration.

For a family office, three mappings deserve explicit proof:

  1. Entity and ownership: The reporting system knows which legal entity owns the asset and how much of that entity is attributable to each family branch. Legal ownership, economic look-through and report access are different fields.
  2. Asset identity: A GP statement, custodian account and GL asset may describe the same interest. Match them to one holding identity before adding them to a consolidated total.
  3. Date and basis: A September private-fund NAV should not be silently relabeled as a December mark. Book value, fair value and an indicative estimate need separate labels and approval paths.

For an official ledger migration, add trial-balance accounts, intercompany relationships, opening journals and historical adjustment lineage. For a reporting overlay, document the existing GL link and each feed's purpose; do not make the dashboard a second book by accident.

04Test a Duplicate Holding That Cash Reconciliation Will Miss

Consider a fictional office with four entities moving its family reporting into a new platform. One LLC owns an LP fund interest. The agreed 31 March entity carrying value and the GP statement both show US$5.0 million for that same interest on the same basis and date. The family's economic share of the LLC is 40%, so this interest contributes US$2.0 million to its look-through view, subject to other ownership adjustments documented elsewhere.

The migration loads the GL asset and the GP statement as separate holdings. The first new report shows US$10.0 million gross and US$4.0 million attributable. The correct test expectation is US$5.0 million gross and US$2.0 million attributable. The overstatement is US$5.0 million gross and US$2.0 million in the family view. No bank cash moved, so a successful cash reconciliation would not reveal this failure.

The defect is not solved by deleting a source. The GL may remain the entity's official carrying record while the GP statement supplies supporting valuation evidence. The office must link both inputs to the same interest, define which one supplies the report value, rerun the entity and family reports, and preserve the before/after evidence. If the sources later diverge by date or basis, the system must show an exception rather than pick the convenient number.

Gate 4 evidence: failed report-acceptance test

  • Expected: One LP interest, US$5.0m gross and US$2.0m attributable to the family at the agreed date and basis.
  • First run: Two exposure lines, US$10.0m gross and US$4.0m attributable. Fail: duplicate holding identity doubles gross and attributable exposure after 40% look-through.
  • Cross-check: Cash balances still agree. That is a cash-only pass, not a report pass.
  • Disposition: Hold the current-value family report. Link the GL and GP inputs to one holding, rerun both entity and family reports, and obtain report-owner sign-off.

This is a deliberately narrow example. Actual ownership agreements, basis differences, fund transactions and reporting policy may require more than the simple 40% calculation. The office should write its expected result from approved source records before seeing the new platform's number.

05Run One Complete Reporting Cycle, Not Just an Import Check

Test an entire cycle using a dated source snapshot: ingest feeds, investigate exceptions, post or import adjustments in the authorized book, reconcile balances and holdings, calculate ownership, generate the family and entity reports, review them, and record who released each output. User acceptance testing should be done by the people who will own those decisions after the vendor leaves.

At minimum, compare the old and new outputs at the same date and basis for:

  • entity trial balances and intercompany balances if the ledger moves;
  • holdings, cash, transactions and unfunded commitments in the reporting scope;
  • entity-to-family ownership and look-through exposures;
  • private-asset source dates, manual estimates and unresolved values;
  • performance or net-worth totals only where the two systems use the same calculation rules;
  • permissions, exports and evidence links for each report recipient.

A difference is not automatically a defect. It may expose an error in the old workbook, a scope change, a different valuation basis or a real migration fault. Log the cause and decision. Never “reconcile” by forcing an unexplained plug into the new system.

The Microsoft migration guidance recommends verifying migration in system-integration and user-acceptance settings. That supports a controlled test sequence; it does not prescribe how many family-office closes must run in parallel. Choose the number of cycles according to data complexity, month-end duties and defect history, then document why the evidence is enough.

06Give Each Check an Owner, Evidence and a Stop Rule

A checklist works only if a failed item changes the release decision. Record each material test in four grouped lines:

  • Identity: test ID, report and date, source and target.
  • Result: expected number, actual number, difference and cause.
  • Disposition: severity, pass/conditional/fail decision and any permitted limitation.
  • Closure: fix owner, retest evidence, reviewer and sign-off date.

For the duplicate LP interest, the record can read:

  • Test: RPT-07, 31 March family exposure report; GL asset and GP statement map to one LP holding.
  • Expected / actual: US$5.0m gross and US$2.0m attributed / US$10.0m gross and US$4.0m attributed.
  • Severity and disposition: Material report overstatement; block family-report go-live. The working dashboard may remain in a clearly labeled test environment.
  • Fix owner: The data-mapping lead links the GL and GP inputs to one holding without deleting either source.
  • Retest evidence: In the fictional second run, the feed still arrives and the report shows one exposure line: US$5.0m gross and US$2.0m attributable at the same date and basis. Attach source-to-report lineage for the entity and family views.
  • Closure: The controller signs the corrected calculation, then the report owner accepts Gate 4 and authorizes the family-report release. Until both observations and signatures exist, the gate remains No-go; an internal pilot is separate.

The office should set its own tolerances before testing. A low-value display issue may be deferred with a named owner. A wrong legal owner, duplicate investment, unauthorized posting right or material unexplained balance cannot be treated as a cosmetic item merely to meet a launch date.

Security and access deserve a separate trial. Have a test user attempt to view another family's entity, modify a posted transaction, approve their own mapping and export sensitive documents. A test that only confirms a permitted action says little about whether prohibited actions are blocked. Preserve the test identities and results without exposing confidential records in the public article.

07Rehearse Cutover and Define How to Reverse It

The final go/no-go meeting should not begin with “Is the vendor ready?” It should read a rehearsed cutover plan: freeze window, last old-system posting, final delta import, source-versus-target checks, user access, report rerun, sign-offs, communication, support coverage and rollback trigger. Keep the old records and mappings available in a controlled, read-only state until the office has accepted the first live cycle.

Microsoft's cutover guidance calls for task ownership, verification, sign-off, a rollback plan and a mock cutover. Those are general implementation disciplines. The family office must set its own window around capital calls, payroll, reporting and payment deadlines.

Define the reversal path before launch. For a reporting overlay, rollback may mean withholding the new family report and distributing the approved old report while feeds and mappings are repaired.

For a ledger replacement, rehearse a stricter handoff:

  1. The CFO authorizes reopening the old ledger and imposes a temporary posting freeze in both systems.
  2. The controller records every transaction since the first freeze in a dated delta log with transaction ID, source, and bank or payment status.
  3. The accountant posts only activity missing from the old ledger to that ledger once. The controller reconciles the restored old ledger to bank and custodian activity and logs differences from the failed new ledger for investigation.
  4. The CFO signs the reconciliation and restores the old ledger as the sole posting authority. The new ledger remains isolated until its defects are repaired and retested.

If the office cannot complete this handoff within its recovery window, the decision is no-go. A backup alone does not solve divergent books.

Record the go/no-go decision in one place:

  • Go: Every blocking test passes, unresolved exceptions have approved labels and owners, users can perform their assigned work, and the report signer accepts the output.
  • Conditional pilot: A non-authoritative view can be used by a limited team with explicit limitations, while the old record and reporting route remain authoritative.
  • No-go: A material mapping, balance, permission or report issue remains unexplained or unowned. Preserve the old workflow and set the next retest date.

The first live report still needs a post-cutover check. Compare its source population and totals to the approved test baseline, account for new transactions, verify the report label and document any changed mapping. Only then retire the corresponding old manual control. An implementation is complete when the office can reproduce the number, name who owns it and recover from a failed run—not when the login page works.

08Frequently Asked Questions

How Long Should Family Office Software Implementation Take?

There is no safe universal duration. Entity count, historical scope, feed availability, private-asset documents, accounting replacement and report customization change the work. Agree on gated deliverables and acceptance evidence rather than adopting a vendor's typical calendar as a promise.

Must We Move All Historical Data Before Go-Live?

Not necessarily. Define which opening balances, transactions, tax lots, documents and comparative periods the first live workflow actually needs. Keep accessible archives and a reconciliation path for anything deferred. Formal reporting and tax requirements may demand more history than a management dashboard.

Can the New Dashboard Go Live While the Old Ledger Stays?

Yes, if the new view is explicitly a reporting layer and its data, ownership mappings, as-of dates, permissions and release controls pass the relevant tests. The old ledger remains the official record. A dashboard pass does not authorize a ledger cutover.

Who Signs Off on Go-Live?

The office should name a business owner for the reporting or accounting result, alongside technical and data owners. The vendor can attest that a migration task ran, but the family-office owner decides whether the output meets the agreed operating and control requirements.

M
Marcus Dossler, CPA
20 years managing family offices · US · Germany · Dubai · India

Marcus Dossler, CPA, has 20 years of experience managing family offices in the US, Germany, Dubai and India. Independent of the vendors covered.

Stay ahead

The stack is changing fast.
Don’t navigate it blind.

Weekly intelligence on tools, providers and strategy — curated for family-office professionals. No noise, no spam.

Double opt-in · confirm by email · unsubscribe anytime · your data stays private