Horus Eye · NPSP → Agentforce Nonprofit

NPSP migration deliverables: what an assessment hands you

NPSP migration deliverables are the product of an assessment, so judge them directly. These pages are rendered from NPSP migration assessments of Kemisoft’s own test orgs — seeded example data, never customer data — and each document is written for a specific reader: the sponsor, the architect, or the delivery manager. Every report carries its own disclaimer, because evidence with stated limits is the whole point.[2][3]

Request an Assessment The NPSP migration desk

How to read an assessment report

Reading Guide

A good assessment report earns trust by how it argues, not how it looks — so read these samples the way a skeptical sponsor would, with three checks:

  1. Every claim names its evidence. The record type, the field, the flow the scan actually saw — and a plain statement of what was not assessed and why. “Not assessed” stated out loud is a feature; a report with no gaps is hiding them.
  2. Recommendations are separated from decisions. The report proposes, the decision register records what your organization chose, and nothing is presented as settled that you have not settled.
  3. Each document knows its reader. The sponsor’s deliverable argues impact and risk, the architect’s carries field-level mappings, the delivery manager’s turns both into owned, sequenced work. One undifferentiated PDF for everyone is how findings get ignored.
One assessment, three readers: the sponsor gets impact and risk, the architect gets field-level mappings, the delivery manager gets owned and sequenced work
One evidence base, three documents — each written for the person who has to act on it.

NPSP Readiness Summary

The Gallery
Cover of the NPSP readiness summary report
The Readiness Summary: the short read for the sponsor.
Executive summary page of the readiness summary
The executive summary: the answer first, the evidence behind it.
Domain readiness page showing each migration domain and its standing
Readiness by domain — and what is holding each one back.

Readiness Report & Decision Register

The Gallery
The roadmap section of the readiness report, ordered by workstream
The order of work, by workstream: blockers first, then evidence, then decisions.
Decision register page listing recorded decisions with who decided and when
The Decision Register: every answer, with who decided it and when.

The three delivery documents

The Gallery
Cover of Deliverable A, written for the executive sponsor
Deliverable A — for the sponsor: impact by team, strategy, risks.
Top risks and key decisions page of the sponsor deliverable
Top risks and the decisions that retire them.
Roadmap page of the sponsor deliverable with six stages and exit gates
The six-stage roadmap with exit gates.
A field-mapping page from Deliverable B, written for the architect
Deliverable B — for the architect: field-level mappings.
Delivery dashboard page from Deliverable C, written for the delivery manager
Deliverable C — for the delivery manager: the work, its state, its owners.

Validation & cut-over

The Gallery
The go / no-go criteria page of the validation and cut-over assessment
Go / no-go: every criterion, its threshold, and its state.

Also in the bundle

Workbook & Backlog

Beside the PDFs above, the NPSP deliverables include the Mapping Workbook[1] (Excel — source fields, destinations, transformation choices, one-to-one and many-to-one mappings, omitted fields and newly created data) and a Jira-ready backlog (CSV) so the delivery manager’s work packages land directly in your tracker. The counts on these pages describe Kemisoft’s own seeded test orgs; your report would carry your org’s numbers, reconciled against your data. Any vendor sample — ours included — shows the shape of the work, never the size of yours.

About the figures on this page: counts and percentages describe Horus Eye’s own test orgs, which hold seeded example data. They are examples of what an assessment reports — never typical results and never a benchmark for your org.

Sources & further reading

References

Protected AI — the Trust Layer

Every AI read in Horus Eye is metadata-first: built from an allowlist, sanitized by pattern, made through one audited gateway and checked by an output firewall on the way back — and AI is off by default, per org. Every request carries an audit id and an AI Data Scope manifest you can open.

See the Trust Layer

Want these pages about your nonprofit’s org instead?

Horus Eye

A read-only assessment produces the same documents from your evidence — written for your sponsor, your architect and your delivery manager.

Try Horus Eye Free Request an Assessment All Horus Eye pages

Free start · 250 credits for 60 days · no card required · scans are free