In PR #1584 (migration-guides branch), make two changes to the migration guides:

1. Move migration guides to a top-level "Migration Guides" nav section:
   - Create docs/content/docs/migration-guides/ directory
   - Move the 3 migrating-from-*.mdx files from getting-started/ into migration-guides/
   - Create migration-guides/meta.json with title "Migration Guides" listing temporal, inngest, aws-step-functions
   - Add "migration-guides" between "errors" and "api-reference" in docs/content/docs/meta.json
   - Remove the 3 migration entries from getting-started/meta.json

2. Replace all "Vercel Workflow" language with "Workflow SDK" across docs and skills:
   - In all 3 MDX migration guides: replace "Vercel Workflow" with "the Workflow SDK" or "Workflow SDK" in frontmatter, headings, table headers, and body text
   - Replace "shipping on Vercel" with neutral phrasing, "Vercel-managed execution" with "managed execution", "Vercel's infrastructure" with neutral phrasing
   - Replace Vercel-specific pricing paragraphs with generic "Efficient resource usage" bullet
   - Replace "Deploy to Vercel first..." checklist items with neutral deployment guidance
   - Keep vercel-world prerequisite links (real package name)
   - Rename skills/migrating-to-vercel-workflow/ to skills/migrating-to-workflow-sdk/
   - Update all skill SKILL.md, evals/, and references/ files to replace "Vercel Workflow" with "Workflow SDK"
   - Update runtime-targets.md section headers from "Non-Vercel" to "Self-hosted"

Author: johnlindquist

docs/content/docs/getting-started/meta.json

@@ -9,10 +9,7 @@
     "nitro",
     "nuxt",
     "sveltekit",
-    "vite",
-    "migrating-from-temporal",
-    "migrating-from-inngest",
-    "migrating-from-aws-step-functions"
+    "vite"
   ],
   "defaultOpen": true
 }

docs/content/docs/meta.json

@@ -10,6 +10,7 @@
     "testing",
     "deploying",
     "errors",
+    "migration-guides",
     "api-reference"
   ]
 }

docs/content/docs/migration-guides/meta.json

@@ -0,0 +1,8 @@
+{
+  "title": "Migration Guides",
+  "pages": [
+    "migrating-from-temporal",
+    "migrating-from-inngest",
+    "migrating-from-aws-step-functions"
+  ]
+}

…ed/migrating-from-aws-step-functions.mdx …es/migrating-from-aws-step-functions.mdxdocs/content/docs/getting-started/migrating-from-aws-step-functions.mdx renamed to docs/content/docs/migration-guides/migrating-from-aws-step-functions.mdx docs/content/docs/getting-started/migrating-from-aws-step-functions.mdx renamed to docs/content/docs/migration-guides/migrating-from-aws-step-functions.mdx

@@ -1,8 +1,8 @@
 ---
 title: Migrating from AWS Step Functions
-description: Move an AWS Step Functions state machine to Vercel Workflow by replacing JSON state definitions, Task states, Choice/Wait/Parallel states, Retry/Catch blocks, and .waitForTaskToken callbacks with Workflows, Steps, Hooks, and idiomatic TypeScript control flow.
+description: Move an AWS Step Functions state machine to the Workflow SDK by replacing JSON state definitions, Task states, Choice/Wait/Parallel states, Retry/Catch blocks, and .waitForTaskToken callbacks with Workflows, Steps, Hooks, and idiomatic TypeScript control flow.
 type: guide
-summary: Translate an AWS Step Functions state machine into Vercel Workflow with side-by-side code and a realistic order-processing saga.
+summary: Translate an AWS Step Functions state machine into the Workflow SDK with side-by-side code and a realistic order-processing saga.
 prerequisites:
   - /docs/getting-started/next
   - /docs/foundations/workflows-and-steps
@@ -18,13 +18,13 @@ related:
 
 With AWS Step Functions, you define workflows as JSON state machines using Amazon States Language (ASL). Each state — Task, Choice, Wait, Parallel, Map — is a node in a declarative graph. You wire Lambda functions as task handlers, configure Retry/Catch blocks per state, and manage callback patterns through `.waitForTaskToken`. The execution engine is powerful, but the authoring experience is configuration-heavy and detached from your application code.
 
-With Vercel Workflow, you write `"use workflow"` functions that orchestrate `"use step"` functions — all in the same file, all plain TypeScript. Branching is `if`/`else`, waiting is `sleep()`, parallelism is `Promise.all()`, and retries are step-level configuration. There is no state-machine JSON to maintain, no Lambda function wiring, and no IAM roles to configure between orchestrator and compute.
+With the Workflow SDK, you write `"use workflow"` functions that orchestrate `"use step"` functions — all in the same file, all plain TypeScript. Branching is `if`/`else`, waiting is `sleep()`, parallelism is `Promise.all()`, and retries are step-level configuration. There is no state-machine JSON to maintain, no Lambda function wiring, and no IAM roles to configure between orchestrator and compute.
 
 The migration path is mostly about **replacing declarative configuration with idiomatic TypeScript** and **collapsing the orchestrator/compute split**, not rewriting business logic.
 
 ## Concept mapping
 
-| AWS Step Functions | Vercel Workflow | Migration note |
+| AWS Step Functions | Workflow SDK | Migration note |
 | --- | --- | --- |
 | State machine (ASL JSON) | `"use workflow"` function | The workflow function _is_ the state machine — expressed as async TypeScript. |
 | Task state / Lambda | `"use step"` function | Put side effects and Node.js access in steps. No separate Lambda deployment. |
@@ -94,7 +94,7 @@ export const handler = async (event: { id: string }) => {
 };
 ```
 
-### Vercel Workflow
+### Workflow SDK
 
 ```typescript
 // workflow/workflows/order.ts
@@ -196,7 +196,7 @@ export const handler = async (event: {
 };
 ```
 
-### Vercel Workflow
+### Workflow SDK
 
 ```typescript
 // workflow/workflows/refund.ts
@@ -348,7 +348,7 @@ A Step Functions saga requires explicit Catch blocks on each state to trigger co
 
 Each Task state maps to a separate Lambda function, and the compensation chain (CancelShipment → RefundPayment → ReleaseInventory → Fail) must be wired explicitly in the state machine.
 
-### Vercel Workflow version
+### Workflow SDK version
 
 ```typescript
 import { FatalError, getStepMetadata, getWritable } from 'workflow';
@@ -486,16 +486,16 @@ async function emitProgress(update: { stage: string; orderId: string }) {
 
 ## Why teams usually simplify infrastructure in this move
 
-Step Functions requires you to define state machines in JSON (Amazon States Language), deploy each task as a separate Lambda function, manage IAM roles between the orchestrator and every Lambda, and configure CloudWatch, X-Ray, or third-party tooling for observability. These are powerful primitives when you need visual workflow editing or cross-service AWS orchestration — but for TypeScript-first teams shipping on Vercel, they are overhead without a corresponding benefit.
+Step Functions requires you to define state machines in JSON (Amazon States Language), deploy each task as a separate Lambda function, manage IAM roles between the orchestrator and every Lambda, and configure CloudWatch, X-Ray, or third-party tooling for observability. These are powerful primitives when you need visual workflow editing or cross-service AWS orchestration — but for TypeScript-first teams, they are overhead without a corresponding benefit.
 
-With Vercel Workflow:
+With the Workflow SDK:
 
 - **No state machine JSON.** The workflow function _is_ the state machine. Branching, looping, and error handling are TypeScript — not a JSON DSL with its own type system and reference syntax.
 - **No Lambda function wiring.** Steps run in the same deployment as your app. There are no separate functions to deploy, version, or connect with IAM policies.
-- **No infrastructure to provision.** There is no CloudFormation/CDK stack for the orchestrator, no Lambda concurrency limits to tune, and no Step Functions pricing tiers to navigate.
+- **No infrastructure to provision.** There is no CloudFormation/CDK stack for the orchestrator, no Lambda concurrency limits to tune, and no pricing tiers to navigate.
 - **TypeScript all the way down.** Workflow and step functions are regular TypeScript with directive annotations. State transitions are `await` calls, not `"Next"` pointers.
 - **Durable streaming built in.** `getWritable()` lets you push progress updates from steps without adding DynamoDB, SNS, or a WebSocket API Gateway.
-- **Usage-based pricing with active-CPU compute.** Workflow bills for Workflow Steps and Workflow Storage, and the functions that execute those steps continue to use standard Vercel compute pricing. If you use Fluid Compute, CPU billing pauses while code waits on I/O. When a workflow is suspended on `sleep()` or a hook, it pauses cleanly instead of keeping a worker process alive.
+- **Efficient resource usage.** When a workflow is suspended on `sleep()` or a hook, it pauses cleanly instead of keeping a worker process alive.
 
 This is not about replacing every Step Functions feature. It is about recognizing that most TypeScript teams use a fraction of Step Functions' state-language surface and pay for the rest in configuration complexity and AWS service sprawl.
 
@@ -512,4 +512,4 @@ This is not about replacing every Step Functions feature. It is about recognizin
 - Move Retry/Catch configuration down to step boundaries using default retries, `maxRetries`, `RetryableError`, and `FatalError`, with standard `try`/`catch` for error handling.
 - Add idempotency keys to external side effects using `getStepMetadata().stepId`.
 - Stream user-visible progress from steps with `getWritable()` when you previously polled DynamoDB or used SNS notifications.
-- Deploy to Vercel first so the guide can truthfully lean on zero-config infrastructure and built-in observability.
+- Deploy your app and verify workflows run end-to-end with built-in observability.

…tting-started/migrating-from-inngest.mdx …ration-guides/migrating-from-inngest.mdxdocs/content/docs/getting-started/migrating-from-inngest.mdx renamed to docs/content/docs/migration-guides/migrating-from-inngest.mdx docs/content/docs/getting-started/migrating-from-inngest.mdx renamed to docs/content/docs/migration-guides/migrating-from-inngest.mdx

@@ -1,8 +1,8 @@
 ---
 title: Migrating from Inngest
-description: Move an Inngest TypeScript app to Vercel Workflow by replacing createFunction, step.run(), step.sleep(), step.waitForEvent(), and step.invoke() with Workflows, Steps, Hooks, and start()/getRun().
+description: Move an Inngest TypeScript app to the Workflow SDK by replacing createFunction, step.run(), step.sleep(), step.waitForEvent(), and step.invoke() with Workflows, Steps, Hooks, and start()/getRun().
 type: guide
-summary: Translate an Inngest app into Vercel Workflow with side-by-side code and a realistic order-processing saga.
+summary: Translate an Inngest app into the Workflow SDK with side-by-side code and a realistic order-processing saga.
 prerequisites:
   - /docs/getting-started/next
   - /docs/foundations/workflows-and-steps
@@ -18,13 +18,13 @@ related:
 
 With Inngest, you define functions using `inngest.createFunction()`, register them through a `serve()` handler, and break work into steps with `step.run()`, `step.sleep()`, and `step.waitForEvent()`. The Inngest platform manages event routing, step execution, and retries on its infrastructure.
 
-With Vercel Workflow, you write `"use workflow"` functions that orchestrate `"use step"` functions — all in the same file, all plain TypeScript. There is no separate function registry, no event-driven dispatch layer, and no SDK client to configure. Durable replay, automatic retries, and step-level persistence still exist — they are built into the Vercel runtime.
+With the Workflow SDK, you write `"use workflow"` functions that orchestrate `"use step"` functions — all in the same file, all plain TypeScript. There is no separate function registry, no event-driven dispatch layer, and no SDK client to configure. Durable replay, automatic retries, and step-level persistence still exist — they are built into the runtime.
 
 The migration path is mostly about **collapsing the SDK abstraction** and **writing plain async functions**, not rewriting business logic.
 
 ## Concept mapping
 
-| Inngest | Vercel Workflow | Migration note |
+| Inngest | Workflow SDK | Migration note |
 | --- | --- | --- |
 | `inngest.createFunction()` | `"use workflow"` function started with `start()` | The workflow function itself is the entry point — no wrapper needed. |
 | `step.run()` | `"use step"` function | Each step is a standalone async function with full Node.js access. |
@@ -72,7 +72,7 @@ export const processOrder = inngest.createFunction(
 );
 ```
 
-### Vercel Workflow
+### Workflow SDK
 
 ```typescript
 // workflow/workflows/order.ts
@@ -141,7 +141,7 @@ export const refundWorkflow = inngest.createFunction(
 );
 ```
 
-### Vercel Workflow
+### Workflow SDK
 
 ```typescript
 // workflow/workflows/refund.ts
@@ -377,7 +377,7 @@ export const processOrderSaga = inngest.createFunction(
 }
 ```
 
-### Vercel Workflow version
+### Workflow SDK version
 
 ```typescript
 import { FatalError, getStepMetadata, getWritable } from 'workflow';
@@ -515,15 +515,15 @@ async function emitProgress(update: { stage: string; orderId: string }) {
 
 ## Why teams usually simplify infrastructure in this move
 
-Inngest adds an event-driven orchestration layer between your app and your durable logic. You configure an Inngest client, register functions through a `serve()` handler, route work through events, and manage step execution through the Inngest platform. This is a clean model when you want event-driven fan-out across many loosely coupled functions — but for TypeScript teams shipping on Vercel, the indirection often outweighs the benefit.
+Inngest adds an event-driven orchestration layer between your app and your durable logic. You configure an Inngest client, register functions through a `serve()` handler, route work through events, and manage step execution through the Inngest platform. This is a clean model when you want event-driven fan-out across many loosely coupled functions — but for TypeScript teams, the indirection often outweighs the benefit.
 
-With Vercel Workflow:
+With the Workflow SDK:
 
 - **No SDK client or serve handler.** Workflow functions are regular TypeScript files with directive annotations. There is no client to configure, no function registry to maintain, and no serve endpoint to wire up.
 - **No event bus.** Start workflows directly with `start()` from your API routes, server actions, or app boundary. You do not need to define event schemas or route through a dispatch layer.
 - **TypeScript all the way down.** Steps are named async functions, not inline closures passed to `step.run()`. They are easier to test, type, and reuse.
 - **Durable streaming built in.** `getWritable()` lets you push progress updates from steps without adding Inngest Realtime or a separate WebSocket/SSE transport.
-- **Usage-based pricing with active-CPU compute.** Workflow bills for Workflow Steps and Workflow Storage, and the functions that execute those steps continue to use standard Vercel compute pricing. If you use Fluid Compute, CPU billing pauses while code waits on I/O. When a workflow is suspended on `sleep()` or a hook, it pauses cleanly instead of keeping a worker process alive.
+- **Efficient resource usage.** When a workflow is suspended on `sleep()` or a hook, it pauses cleanly instead of keeping a worker process alive.
 
 This is not about replacing every Inngest feature. It is about recognizing that most TypeScript teams use a fraction of Inngest's event-routing surface and pay for the rest in SDK complexity and platform coupling.
 
@@ -540,4 +540,4 @@ This is not about replacing every Inngest feature. It is about recognizing that
 - Move retry configuration down to step boundaries using default retries, `maxRetries`, `RetryableError`, and `FatalError`.
 - Add idempotency keys to external side effects using `getStepMetadata().stepId`.
 - Replace `step.realtime.publish()` with `getWritable()` for streaming progress to clients.
-- Deploy to Vercel first so the guide can truthfully lean on zero-config infrastructure and built-in observability.
+- Deploy your app and verify workflows run end-to-end with built-in observability.