/workers-migrate

name: cloudflare-workers:migrate
description: Platform migration assistant for moving applications from AWS Lambda, Vercel, Netlify, or Cloudflare Pages to Cloudflare Workers.
allowed-tools:
  - Read
  - Write
  - AskUserQuestion
  - Grep
  - Glob
  - Bash
argument-hint: "--from <lambda|vercel|netlify|pages> (source platform)"

Workers Migrate Command

Guided migration assistant for moving applications to Cloudflare Workers from other platforms.

Execution Workflow

Phase 1: Source Platform Detection

**If --from argument provided**:

• Use specified platform (lambda, vercel, netlify, pages)
• Skip detection step

**If no --from argument**: Use AskUserQuestion:

**Question**: "Which platform are you migrating from?"

• Options:
• AWS Lambda (serverless functions)
• Vercel (Edge Functions, Serverless Functions)
• Netlify (Functions, Edge Functions)
• Cloudflare Pages (Functions)
• Other (custom platform)

Phase 2: Project Analysis

Scan the project to understand its structure:

**For AWS Lambda**: 1. Look for `serverless.yml` or `template.yaml` (SAM) 2. Find Lambda handler files (usually `index.js` or `handler.js`) 3. Check for AWS SDK usage:

   grep -r "aws-sdk" .
   grep -r "@aws-sdk" .

4. Identify runtime (Node.js, Python, etc.) 5. Check for environment variables in config 6. Identify triggers (API Gateway, S3, etc.)

**For Vercel**: 1. Look for `vercel.json` configuration 2. Find Edge Functions (`middleware.ts`) and Serverless Functions (`api/`) 3. Check framework (Next.js, SvelteKit, etc.) 4. Identify environment variables in `.env` or dashboard 5. Check for Vercel-specific features (ISR, Edge Config)

**For Netlify**: 1. Look for `netlify.toml` 2. Find Functions in `netlify/functions/` or `functions/` 3. Check for Edge Functions in `netlify/edge-functions/` 4. Identify redirects and rewrites 5. Check for Netlify-specific features (Forms, Identity)

**For Cloudflare Pages**: 1. Look for `_worker.js` or `functions/` directory 2. Check `wrangler.toml` for Pages configuration 3. Identify framework (if any) 4. Note bindings already configured

Phase 3: Compatibility Analysis

Analyze what can be migrated automatically vs. manually:

**Compatible Features** (auto-migrate):

• HTTP request/response handling
• Environment variables → Workers env
• Basic routing
• JSON APIs
• Static file serving → Workers Static Assets

**Requires Adaptation**:

• AWS SDK → Cloudflare equivalents (S3→R2, DynamoDB→D1/KV)
• File system access → R2 or KV
• Long-running tasks (>30s) → Workflows or Queues
• WebSockets → Durable Objects with hibernation
• Cron jobs → Cron Triggers

**Incompatible** (needs redesign):

• Lambda Layers → Use npm packages
• VPC access → Use public APIs or Cloudflare Tunnels
• Container images → Bundle dependencies normally
• >10MB bundle size → Optimize or split into multiple Workers

Generate compatibility report:

## Migration Compatibility Report

**Source Platform**: [Platform]
**Project Type**: [Type]
**Runtime**: [Runtime]

### ✅ Compatible (Auto-Migrate)
- HTTP handlers: X files found
- Environment variables: X found
- Static assets: X files

### ⚠️ Requires Adaptation
- AWS S3 usage → Migrate to R2
- DynamoDB → Migrate to D1 or KV
- File uploads → Use R2 with multipart
- Scheduled tasks → Convert to Cron Triggers

### ❌ Incompatible (Manual Redesign)
- Lambda Layers → Install as npm packages
- VPC endpoints → Use Hyperdrive for database access

### Estimated Effort
- Auto-migration: ~30 minutes
- Manual adaptation: ~2-4 hours
- Testing & validation: ~1 hour

Phase 4: Migration Strategy

Ask user about migration approach:

**Question**: "How do you want to migrate?"

• Options:
• Full automatic migration (Recommended for simple projects)
• Generate migration template (I'll customize manually)
• Guided step-by-step migration
• Compatibility analysis only (no code changes)

Phase 5: Code Transformation

Based on selected strategy, transform code:

AWS Lambda → Workers

**Handler transformation**:

**Lambda format**:

exports.handler = async (event, context) => {
  return {
    statusCode: 200,
    body: JSON.stringify({ message: 'Hello' })
  };
};

**Workers format**:

export default {
  async fetch(request: Request, env: Env): Promise<Response> {
    return new Response(JSON.stringify({ message: 'Hello' }), {
      status: 200,
      headers: { 'Content-Type': 'application/json' }
    });
  }
};

**AWS SDK replacements**:

• `S3.getObject()` → `env.BUCKET.get()`
• `DynamoDB.putItem()` → `env.DB.prepare().run()`
• `SNS.publish()` → `env.QUEUE.send()`
• `Lambda.invoke()` → Service binding or fetch()

Vercel → Workers

**Edge Function transformation**:

**Vercel format**:

import type { NextRequest } from 'next/server';

export default function middleware(request: NextRequest) {
  return new Response('Hello');
}

**Workers format**:

export default {
  async fetch(request: Request): Promise<Response> {
    return new Response('Hello');
  }
};

**Vercel-specific features**:

• `edge-config` → KV
• `@vercel/kv` → Workers KV
• `@vercel/postgres` → D1 or Hyperdrive

Netlify → Workers

**Function transformation**:

**Netlify format**:

exports.handler = async (event) => {
  return {
    statusCode: 200,
    body: JSON.stringify({ msg: 'Hello' })
  };
};

**Workers format**: (Same as Lambda transformation)

**Netlify-specific**:

• Redirects → Workers Routes or `_redirects` file
• Environment variables → wrangler.jsonc vars/secrets
• Build plugins → Use Workers build process

Phase 6: Configuration Generation

Create wrangler.jsonc configuration:

{
  "name": "[project-name]",
  "main": "src/index.ts",
  "compatibility_date": "2025-01-27",

  // Environment variables (add secrets with: wrangler secret put)
  "vars": {
    "ENVIRONMENT": "production"
  },

  // Bindings (configure as needed)
  {{BINDING