Execute Vercel major re-architecture and migration strategies with strangler fig pattern. Use when migrating to or from Vercel, performing major version upgrades, or re-platforming existing integrations to Vercel. Trigger with phrases like "migrate vercel", "vercel migration", "switch to vercel", "vercel replatform", "vercel upgrade major".
From vercel-packnpx claudepluginhub nickloveinvesting/nick-love-plugins --plugin vercel-packThis skill is limited to using the following tools:
references/errors.mdreferences/examples.mdreferences/implementation-plan.mdreferences/pre-migration-assessment.mdGuides Next.js Cache Components and Partial Prerendering (PPR) with cacheComponents enabled. Implements 'use cache', cacheLife(), cacheTag(), revalidateTag(), static/dynamic optimization, and cache debugging.
Migrates code, prompts, and API calls from Claude Sonnet 4.0/4.5 or Opus 4.1 to Opus 4.5, updating model strings on Anthropic, AWS, GCP, Azure platforms.
Details PluginEval's skill quality evaluation: 3 layers (static, LLM judge), 10 dimensions, rubrics, formulas, anti-patterns, badges. Use to interpret scores, improve triggering, calibrate thresholds.
Migrating to Vercel from another deployment platform or migrating a Vercel-hosted application to a different architecture is most safely done incrementally using the strangler fig pattern. The key risk in any migration is a hard cutover that cannot be quickly reversed if problems emerge. Building gradual traffic shifting into your migration plan gives you the ability to limit user impact during the transition and validate that the new deployment behaves identically to the old one before fully committing.
Document the existing deployment configuration: build pipeline, environment variables, serverless function patterns, custom headers and redirect rules, domain configuration, and any Vercel-specific features in use (edge functions, incremental static regeneration, middleware). Identify which aspects of the current deployment have no direct equivalent in the target architecture and require architectural decisions before proceeding.
Create an abstraction layer for gradual migration using Vercel's rewrite rules or middleware to route a percentage of traffic to the new deployment. This allows you to run both versions in parallel and compare behavior under real traffic without fully committing to the migration.
For migrations involving data store changes alongside the platform migration, run batch data migration with error handling and verification checksums. Keep both data stores in sync during the parallel-run period.
Gradually increase traffic to the new deployment, monitoring error rates and latency at each increment before proceeding. Decommission the old deployment only after running fully on the new configuration for a stability period with no regressions.
See ${CLAUDE_SKILL_DIR}/references/errors.md for comprehensive error handling.
See ${CLAUDE_SKILL_DIR}/references/examples.md for detailed examples.
Execute Vercel major re-architecture and migration strategies with strangler fig pattern.