Org X-Ray — Migration Readiness Report

897 component(s) in this org belong to 5 installed managed package(s). We cannot read a managed package’s source, so it cannot be transcribed — not by us, not by any migration tool: the org holds only the package’s sealed, compiled surface. These components are therefore excluded from the readiness calculation (they are not counted as “covered”, and they are not counted against us either — scoring a wall we cannot see through would misstate the number in both directions). We recommend an equivalent on the owned stack and implement it as separate scope (additional fees). Moving off Salesforce means giving the installed package up; that is a commercial decision, not a failure of the migration.

Detection is mechanical and fail-closed. A component is excluded only when its namespace is proven by API-name evidence in your own metadata — a namespaced object folder (objects/ns__Object__c/) or a component whose API name carries the prefix. A free-text label or layout name can never introduce one, and neither can a folder name in your repository. Un-namespaced metadata always stays in the denominator. 822 of the excluded components are yours, not the publisher’s — your fields, rules, and actions built on package objects. They are named below, one by one.

NPSP Contacts & Organizations (npe01) — npe01__ · 413 component(s), excluded from the readiness calculation.

396 of YOUR OWN component(s) sit on this package’s objects. They are yours, but they depend on package objects and cannot carry over — every one is named here so you can price the rebuild:

NPSP Recurring Donations (npe03) — npe03__ · 376 component(s), excluded from the readiness calculation.

360 of YOUR OWN component(s) sit on this package’s objects. They are yours, but they depend on package objects and cannot carry over — every one is named here so you can price the rebuild:

NPSP Households (npo02) — npo02__ · 53 component(s), excluded from the readiness calculation.

37 of YOUR OWN component(s) sit on this package’s objects. They are yours, but they depend on package objects and cannot carry over — every one is named here so you can price the rebuild:

NPSP Relationships (npe4) — npe4__ · 36 component(s), excluded from the readiness calculation.

19 of YOUR OWN component(s) sit on this package’s objects. They are yours, but they depend on package objects and cannot carry over — every one is named here so you can price the rebuild:

NPSP Affiliations (npe5) — npe5__ · 19 component(s), excluded from the readiness calculation.

10 of YOUR OWN component(s) sit on this package’s objects. They are yours, but they depend on package objects and cannot carry over — every one is named here so you can price the rebuild:

Ready today 3,012 items

Transcribed today — deterministic transcription, running now, no AI in the loop.

Needs translation 1,109 items

Translation required — Apex, Flows and out-of-subset formulas go through the LLM + verification harness.

Needs a person / not in a pipeline yet 288 items

Inventoried but not yet in either automated pipeline — scoped for human work (UI rewrites, endpoint design) or awaiting an engine surface; counted against readiness so the score stays honest.

This org declares a package scope in sfdx-project.json, so the scan looked only inside its packageDirectories. The directories below exist in the retrieve but sit outside that scope — nothing in them is counted in the readiness score above, including any reports, dashboards, or objects they hold. A full migration retrieve should include them if they carry production metadata; re-run the X-Ray against a full retrieve to fold them in.

7,002 file(s) across 16 type(s) carry no data model and no logic a CRM replacement must reproduce — localized label translations, binary/static assets, display-only or theming metadata, build/test tooling. Each is excluded from the “needs a person” count and the human-work denominator, with a per-type reason stated so a skeptical reviewer can challenge any single line. Nothing is hidden.

10 AutoNumber field(s) keep uniqueness (a stable, auto-assigned id) but not the Salesforce sequential display format (10 declare one). The owned schema substitutes a cuid: unique and non-null, but a different shape than ALL-{0}. These columns are already counted as transcribed — this ledger changes no readiness number; it names the one property not reproduced so any process that parsed the SF display string is a known follow-up, never a silent drop.

Surfaces the X-Ray actively looked for in this org and found none of. Listed so a zero reads as “checked, none found” — not “never looked”. Each maps to a real recognizer (an inventory counter or a documented Metadata API type).

Dashboards · Flows · Approval processes · Record types · Named credentials · Connected apps · Roles · Sharing rules · Queues · Assignment rules · Escalation rules · Auto-response rules · Duplicate rules · Territory management · Forecasting types · Public groups

Named credentials, connected apps, remote-site entries, and outbound Apex callouts this org depends on. Endpoint business logic and live credentials are never inspected or fabricated — only counted and mapped where an owned-stack equivalent exists.

41 integration point(s) total — 4 mapped to an owned-stack equivalent, 37 flagged for human design work.

Custom UI (Lightning Web Components / Aura). LWC templates and the mechanical slice of their JavaScript are converted to a compiling React .tsx by the real deterministic converter (src/translate/lwc-convert.ts) — the same fail-closed posture as the SOQL translator: any construct outside the directive table becomes a NAMED blocker, never a faked translation. Aura is a different framework with no converter and stays 100% manual.

Per-component verdicts (partial / flagged)

5 of 122 LWC (4.1%) convert to a compiling React .tsx deterministically; 47 convert their template only (behavior stubbed for a person); 70 need a full manual rewrite. All 54 Aura component(s) are 100% manual — a different framework with no converter.

Lightning pages (flexipages) are a needs-a-person surface — this labeler names, per page, WHY; it does not claim to build them. None of the 4 page(s) are standard-only record pages a generated layout reproduces. Every page here is already counted once against readiness via the .flexipage-meta.xml line in “Needs a person” above — this subsection is transparency only and changes no count.

Org-wide recurring blockers

A component placed on more than one page is shown once here with its affected pages, instead of repeating the identical reason on every row.

0 covered (layout semantics) · 4 needs a person · 4 page(s) total.

Field sets, quick-create QuickActions, and external-URL WebLinks — run through the real UI-action parser (the same one transcribe uses to emit typed config the generated app consumes). Convertible items are credited ready-today; everything else stays a needs-a-person row with the parser's precise, per-item reason, never a blanket "not built".

Flagged UI actions — per-item reason

Legacy Visualforce pages, each labeled from its <apex:page> markup. A .page and its .page-meta.xml descriptor are ONE unit (the companion folds in, no double-count). Coverage (superseded) is earned only by a pure standardController + <apex:detail>/<apex:relatedList> wrapper the generated record UI reproduces — fail-closed; everything with a custom controller, script, or custom component is a hand rewrite, with its controller classes named and cross-linked to the Apex deep run.

79 page(s) · 0 superseded (credited ready-today) · 79 need a person.

Every *.cls / *.trigger classified by measured properties only — code lines, method count, embedded SOQL, and risk markers (callouts, async, dynamic SOQL) — never by a time estimate. The deterministic verdict is the real pre-pass: TRIVIAL files translate today with no AI in the loop; TEST classes are regenerated as a parity harness, not translated line-for-line.

Conversion complexity buckets

Largest classes (by code lines)

LLM assessment: not run (key-gated per engagement).

Reports translate to a single deterministic SQL SELECT when their shape allows it (Tabular/Summary, implicit-AND filters, no custom summary formulas); Matrix/joined reports and other unsupported shapes are honestly refused, never approximated. Dashboard panels are resolved through the SAME translate/refuse machinery: a panel renders only when it binds exactly to what its backing report produces, and is refused — by construct — whenever the value would have to be fabricated (a renderable chart kind alone is not enough).

Report refusal reasons

Computed fields, split by the owned-stack construct they become: a same-object formula becomes a Postgres GENERATED ALWAYS AS column; a cross-object formula becomes a query-time resolver (generated columns can't reference another table's row); a roll-up summary becomes a trigger-maintained aggregate. Anything outside that subset is flagged, never guessed.

9 computed field(s) classified total.

Org-wide defaults, role hierarchy, and sharing rules — parsed only, not compiled into RLS policies here (that step needs a real owner-column wiring the engine doesn't have yet; see the transcription CLI's Sharing→RLS output for that artifact). Default-deny: anything not modeled below grants nothing.

OWD mix

Flagged count always includes a standing advisory for Manual sharing: it is per-record runtime data with no metadata file to parse, so it can never be transcribed from a snapshot alone.