MigrationLens — Evidence-Grounded Technology Migration Intelligence powered by Sanity

This is a submission for the Sanity Challenge, Path One: Ship an Agent That Queries Real Content

What I Built

MigrationLens is an evidence-grounded technology migration planning agent built for software architects, engineering managers, and developers facing complex stack upgrades (e.g., Next.js 14 to 15, React 18 to 19, Node.js 18 to 20, Python 3.9 to 3.12).

When engineering teams migrate frameworks or runtimes, standard vector search and LLM chatbots frequently hallucinate deprecated flags, miscalculate dependency constraints, or mix advice across incompatible release years.

MigrationLens solves this by reasoning over structured entities stored in the Sanity Content Lake. Rather than generating migration advice from unstructured text embeddings alone, MigrationLens executes parallel GROQ queries across Sanity document schemas:

• technology: Core software stack definitions.
• technologyVersion: Version release timelines and support lifecycle statuses (active, maintenance, deprecated, eol).
• migration: Prerequisites, sequential upgrade steps, validation checks, and rollback procedures.
• dependency: Version constraints (REQUIRES, COMPATIBLE_WITH, CONFLICTS_WITH) and severity bounds.
• change: Breaking changes, deprecations, affected features, and required migration actions.
• claim: Verified technical assertions linked to specific release versions.
• source: Primary documentation sources, release notes, and security advisories backing every claim.

Every recommendation rendered in MigrationLens can be traced back to structured schema entities and primary evidence stored in Sanity.

Demo

• Local Application Host: Run locally via cd web && npm run dev at http://localhost:3000

Key Dashboard Features

1. 1-Click Presets: Immediate analysis for Next.js 14.2 → 15.0, Node.js 18 → 20, React 18 → 19, and Python 3.9 → 3.12.
2. Grounded Intelligence Summary: Displays overall complexity rating, estimated effort timeline, and data source indicators (Sanity Content Lake vs Seed Data Fallback).
3. Grounded Confidence Metric: Calculates a verifiable confidence score (98%) based on Sanity claim density and primary source authority.
4. Breaking Changes Matrix: Detailed breakdowns of severity (CRITICAL, HIGH, MEDIUM, LOW), affected features, required code actions, and compiler validation methods.
5. Actionable Step-by-Step Plan: Ordered migration steps with prerequisite checks, validation steps, and emergency rollback procedures.
6. Dependency Matrix: Required package versions, relationship rules, and severity flags.
7. Evidence Trail: Primary documentation source attribution with authority ratings (PRIMARY, SECONDARY, COMMUNITY) and clickable source links.

Code

• GitHub Repository: https://github.com/NikhilRaman12/MigrationLens

How I Used Sanity

Sanity serves as the core authoritative knowledge graph for MigrationLens. The agent reads and queries structured content using GROQ queries through next-sanity.

1. Schema Graph Modeling

I built 7 interconnected Sanity document types in studio-migrationlens/schemaTypes:

• References connect TechnologyVersion to parent Technology entities.
• Migration documents dereference sourceTechnology, sourceVersion, targetTechnology, and targetVersion.
• Change documents track version transition thresholds (fromVersion → toVersion).
• Claim documents link assertions to TechnologyVersion and Source documents.

2. GROQ Query Execution

When a migration is analyzed, the API agent (src/app/api/migration-agent/route.ts) executes parallel GROQ queries via helper functions in src/sanity/queries.ts:

ts
/** Fetch migration steps, prerequisites, and risk summaries */
export const QUERY_MIGRATION = `*[_type == "migration"
  && (sourceTechnology->name match $sourceTech || sourceTechnology->name == $sourceTech)
][0] {
  _id,
  migrationType,
  "sourceTechName": sourceTechnology->name,
  "sourceVersionStr": sourceVersion->version,
  "targetTechName": targetTechnology->name,
  "targetVersionStr": targetVersion->version,
  prerequisites,
  migrationSteps[] { order, description, prerequisite, validation, rollback },
  validationSteps,
  rollbackSteps,
  riskSummary
}`

/** Fetch granular breaking changes */
export const QUERY_CHANGES = `*[_type == "change" && technology->name match $techName] | order(severity desc) {
  _id,
  "technologyName": technology->name,
  "fromVersion": fromVersion->version,
  "toVersion": toVersion->version,
  title, description, changeType, severity, affectedFeature, migrationAction, validationMethod
}`

3. Agent Synthesis & Grounded Evidence

The Migration Agent processes the returned Sanity document graph:

Filters breaking changes (changeType == 'BREAKING').
Synthesizes migration steps and prerequisite checklists.
Evaluates dependency constraints and severity levels.
Attributes every claim to a primary source document URL.
Sanity Project Details
Sanity Project ID: zp2gmoor
Dataset: production
Sanity Studio Location: studio-migrationlens
Agent Session

The Migration Agent operates deterministically over Sanity GROQ entities. When a user requests a migration strategy:

Request Intake: API receives target technologies (e.g., Next.js 14.2.0 to Next.js 15.0.0).
Parallel Retrieval: Promise.allSettled queries Sanity Content Lake for Migration, Dependency, Change, Claim, and Source documents.
Data Provenance & Fallback Guard: If Sanity content lake queries return empty states (e.g., fresh dataset), the agent seamlessly merges curated seed data (src/sanity/demo-data.ts) so judges always receive complete actionable insights.
Structured JSON Output: Returns structured payload with summary, confidence score, breaking changes, step-by-step recommendations, package dependencies, validation checks, emergency rollback safeguards, and source links.
---