Step 1
Split the migration into steps
Break the move into steps that each fit one pull request and leave main working, such as one package, module or route at a time. Your own coding agent can draft the list with you.
Code migrations
Migrate your codebase one verified pull request at a time
Split the migration into steps small enough to review, and SHIP runs each one. Every step lands as a pull request that passed your CI, a code review and a test.
- For
- Engineers facing a framework, language or major version migration.
- Instead of
- A long-lived migration branch that drifts further from main every week.
Answer 4 questions to request access. SHIP is invite-only for now.
ship delegate plan SHIP-412 --file docs/plan.mdHow it works
Plan the move, then take it in steps
Step 2
Hand each step to SHIP
File each step as an issue and assign it to SHIP, with a planner checkpoint if you want to approve the approach before anything is built. Or write the step's plan yourself and hand it over with ship delegate plan.
Step 3
Merge each step as it lands
Each step runs as its own mission: build, your CI, a code review and a test. Merge it before you hand over the next, and main stays releasable between steps.
Capabilities
Keep behavior the same while the code changes
Gate every step on your existing tests
Your CI and test suite run on every step, so a behavior change your tests cover is caught on the step that caused it.
Hold a step for review
A checkpoint holds a step after its plan or its code review until someone on your team resumes it or asks for changes.
Run every step on the models you choose
Pick the harness and model per role, and every agent runs on the credentials you connect, billed at your own rates.
Read what each step cost
Every mission reports its cost and duration, so the migration's cost is the sum of its pull requests.
Comparison
Compare SHIP with Devin and Factory
| Devin |
|
|---|---|
| Factory |
|
| SHIP |
|
FAQ
Frequently asked questions
How do I split a migration into steps?
Split it so each step fits one pull request and leaves main working, such as one package, module or route at a time. File each step as an issue for the Planner, or write its plan yourself and hand it over with ship delegate plan.
What happens when a step breaks something?
Your CI or the Tester catches it, and the Builder fixes the failure on the same pull request before it is ready for you. If the same failure keeps coming back, the mission stops and asks for you instead of looping.
When is Devin or Factory the better fit?
Factory fits a team that wants to plan a large migration into features and milestones up front and hand the whole plan over, which its Missions page describes. Devin fits a team running large-scale modernization, the kind its docs describe with multi-million-line ETL monoliths moved to modular components. SHIP fits when every step should arrive as a small pull request that passed your CI, a code review and a test before your team merges it.
What does a code migration cost?
Each step is one mission: one credit covers up to 3 agent-hours, and each further 3 agent-hours or part of them uses one more. Credits come back when a step ends in failure or needs attention with no pull request, and your own provider bills model usage.
Start your migration with a plan you approve
Hand over the first step, and read it as a pull request that already passed your CI, a code review and a test.
Start your first mission
Answer 4 questions to request access. SHIP is invite-only for now.