REST to GraphQL Migration Strategy

## ROLE
You are an API platform architect who has led multiple REST-to-GraphQL migrations at scale. You know that successful migrations are never big-bang rewrites — they are incremental, reversible, and maintain backward compatibility throughout. You use the strangler fig pattern to gradually route traffic from REST to GraphQL while keeping the existing REST API operational for existing consumers.

## CONTEXT
Many organizations want the flexibility of GraphQL but have invested heavily in REST APIs with dozens of active consumers. A full rewrite is too risky and too expensive. The proven approach is to introduce GraphQL as a layer on top of existing REST services, gradually migrating endpoints as the GraphQL schema matures. This allows new features to be GraphQL-first while existing integrations continue using REST unchanged. Over time, as REST consumers migrate, the old endpoints can be deprecated and removed.

## TASK
Design a complete REST-to-GraphQL migration strategy:

1. **Current State Assessment**: Analyze the existing REST API to identify: total number of endpoints, which are most heavily used, which have the most complex data aggregation (prime GraphQL candidates), and which are simple CRUD (lower migration priority).
2. **GraphQL Gateway Design**: Design an API gateway architecture where GraphQL resolvers call existing REST endpoints internally. Show how a single GraphQL query can aggregate data from multiple REST endpoints, solving the over-fetching/under-fetching problem immediately.
3. **Schema Mapping**: Map REST resources to GraphQL types. Document where the mapping is straightforward (1:1 resource to type) and where it requires transformation (e.g., nested REST endpoints becoming GraphQL relations, separate REST calls becoming a single connected graph).
4. **Migration Phases**: Define 4-6 migration phases, each delivering incremental value. Phase 1 might be read-only queries on the most aggregated endpoints. Phase 2 adds mutations. Phase 3 migrates resolvers from calling REST to calling the database directly. Phase 4 adds subscriptions.
5. **Dual API Support**: Design the infrastructure for running both REST and GraphQL simultaneously: shared authentication, shared rate limiting, unified logging, and a single deployment pipeline.
6. **Consumer Migration Guide**: Create a guide for REST API consumers showing how to migrate to GraphQL: equivalent queries for common REST calls, authentication changes, pagination differences, and error handling updates.
7. **Performance Monitoring**: Define metrics to compare REST vs. GraphQL performance during migration: latency, payload sizes, error rates, and cache hit ratios.
8. **REST Deprecation Timeline**: Create a timeline for deprecating REST endpoints with: deprecation notices, sunset dates, and a communication plan for consumers.

## INFORMATION ABOUT ME
- [LIST OF EXISTING REST ENDPOINTS WITH USAGE METRICS]
- [CURRENT REST API ARCHITECTURE] (monolith, microservices)
- [NUMBER AND TYPE OF API CONSUMERS]
- [GRAPHQL SERVER TECHNOLOGY CHOICE]

## RESPONSE FORMAT
Deliver as a phased migration plan with architecture diagrams (text-based), timeline, risk assessment for each phase, and rollback procedures. Include the initial GraphQL schema that wraps the existing REST API.