sandbox-migrate-to-next

1# Migrate stable → Sandbox SDK 1.0 preview (`@next`)
2 
3**Perform** the port. Follow the steps in order. Depth lives in docs—fetch the linked page when a step needs detail.
4 
5Human guide: [Migrate](https://developers.cloudflare.com/sandbox/sdk/migrate/index.md) · [1.0 preview](https://developers.cloudflare.com/sandbox/index.md)
6 
7**New projects** should start on `@next` (**`sandbox-next`**), not this skill. **Day-to-day stable work** → **`sandbox-stable`**. Deprecated-API cleanup **without** moving to `@next` → [2026 deprecation guide](https://developers.cloudflare.com/sandbox/sdk/migrate/index.md) first if needed.
8 
9Existing apps should migrate **when you can**, so you are ready when 1.0 becomes the stable release. Do **not** force production cutover without the user agreeing.
10 
11**Prefer installed `@next` types and the migrate doc over memory.**
12 
13## Workflow
14 
151. **Review** hard rules and the replacement map  
162. **Audit** the codebase; list hits and target shapes  
173. **Clarify** with the user (cutover, bridge, Python image, unclear sites)  
184. **Upgrade** package, image, and code  
195. **Validate**  
20 
21Stop after any step that needs a user decision.
22 
23## Hard rules
24 
25- Worker package and container image must be the **same** `@next` line.  
26- Production cutover uses **immediate** container rollout. Stable and `@next` control protocols are incompatible both ways; gradual rollout leaves a broken mixed window. In-flight container work can stop.
27…