Org X-Ray — Migration Readiness Report

Ready today 81 items

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

Needs translation 144 items

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

Needs a person / not in a pipeline yet 122 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.

4 file(s) across 3 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.

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).

Reports · Dashboards · Workflow rules · Approval processes · Email templates · Record types · Connected apps · Remote site settings · Roles · Sharing rules · Queues · Assignment rules · Escalation rules · Auto-response rules · Duplicate rules · Matching rules · Territory management · Forecasting types · Global value sets · Public groups · Quick actions

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.

14 integration point(s) total — 1 mapped to an owned-stack equivalent, 13 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)

0 of 7 LWC (0.0%) convert to a compiling React .tsx deterministically; 1 convert their template only (behavior stubbed for a person); 6 need a full manual rewrite. All 0 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 1 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.

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

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).

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.

0 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.