Cursor Projects (beta since September 10, 2026) lets a coordinator agent delegate a migration to parallel subagents instead of you running it step by step. It's strong on mechanical changes like build-tool upgrades, but a September 2026 benchmark found agents pass full-repository migration audits only 5.4% of the time. Stage the work, serialize schema and auth changes, and review before you ship.
A client wants their old app rebuilt on a new stack, and you're eyeing Cursor's new coordinator agent to do the heavy lifting while you sleep.
That instinct makes sense. Cursor Projects rolled out in beta on September 10, 2026. It was built for jobs exactly like this: a coordinator agent takes the big task, splits it into pieces, and hands each piece to a subagent instead of you running every step by hand. This is what using Cursor Projects for client site migrations really looks like — the parts it's good at, and the one number that should slow you down first. We'll get to it.
What Cursor Projects Actually Does
Cursor Projects adds a management layer on top of the editor you already use. Cursor puts it simply in its own announcement: "Projects lets you take on larger bodies of work, such as a feature, a migration, or a full app." A coordinator agent reads your instructions. It breaks the job into pieces and delegates each piece to a subagent. It doesn't write code itself. It directs the agents that do, and it can run "thousands of subagents" in parallel when a job calls for it.
The whole thing runs on Cursor's own cloud infrastructure, not your laptop. Close the lid, and the migration keeps going. Subagents share one synced set of project files. Research one agent does on your codebase — a weird auth flow, a legacy config file nobody documented — becomes available to every other agent on the same project.
There's a third piece worth knowing before you use this on client work. The coordinator can subscribe to signals. It can watch a Slack channel, run on a schedule, or follow your pull requests, and start work on its own. That's handy for ongoing maintenance. It's also the part that needs the most guardrails on a client repo, and we'll come back to that.
Is Cursor Projects Ready for Client Migrations?
Here's the number. A September 2026 benchmark called SWE Refactor Bench tested coding agents on 520 attempts at whole-repository stack migrations — the exact kind of job Cursor is pitching Projects for. Only 28 of those runs, 5.4%, passed a full audit: migration completeness, behavioral correctness, and adversarial checks. The best model in the study scored 47 out of 100 overall.
The type of migration matters more than that headline number suggests. Build-toolchain changes, like swapping a bundler or updating a config, scored 31.4 out of 100. Full language rewrites scored 5.6 out of 100. That's a six-fold gap between a job an agent can likely finish and one it mostly can't.
Read that as a range, not a verdict. A dependency bump is a different bet than rewriting a client's checkout flow into a new language. Cursor Projects is genuinely useful for the first kind of job. Treat it as a fast first draft, not a finished delivery, for the second.
Reviewers who tested the beta found the same pattern by hand. One called the coordinator-and-subagent design "genuinely useful for large codebase migrations — but not as an unattended rewrite button." Parallel subagents also share one limited pool of context. Push past a certain count on one codebase, and they start working against each other instead of dividing the job cleanly. How many is too many depends on the codebase — start small, and we'll give you a number to start from next.
How to Use Cursor Projects for Client Site Migrations
If you're taking on a migration for a client — an old CMS to a new framework, a legacy backend to a modern API layer, an app locked to end-of-life packages — here's a workflow that uses Projects without betting the delivery on it.
Baseline the current system first. Write down what "working" means before any agent touches the code: the user flows that must survive, the edge cases you already know about, the performance floor the client expects.
Pilot one slice, not the whole repo. Point the coordinator at a single module or route. Start with two or three subagents on that one slice before letting the coordinator scale up — that's the range where reviewers saw parallel work stay clean rather than start colliding.
Keep cross-cutting changes serialized. Schema changes, auth, and shared API contracts don't parallelize safely. Two agents editing the same interface at once is how you get silent breakage. Run those changes one agent at a time, with a human reviewing each one before the next starts.
Treat a passing CI run as one signal, not the verdict. The SWE Refactor Bench numbers above came from agents whose code often passed basic checks while still failing behavioral correctness. Add tests for the behavior you baselined in step one, not just the tests that already existed.
Turn off autonomous triggering on client repos. The Slack- and PR-watching behavior from the coordinator is useful once you trust its judgment on a specific codebase. On a client migration you're still staging, keep it off. Let it run only when you tell it to.
Integrate in waves, with sign-off at each one. Merge the low-risk slice first — the build-toolchain-style change, not the language rewrite. Get client or team approval before the next wave touches anything customer-facing.
| Job type | Cursor Projects fit | What to still do by hand |
|---|---|---|
| Dependency or build-tool upgrade | Strong — matches its best benchmark scores | Spot-check the diff, run the full test suite |
| Feature addition in an existing pattern | Good — coordinator can research and build in parallel | Review interdependent files yourself |
| Framework or language migration | Weak — scored 5.6/100 in independent testing | Stage it, serialize risky files, don't ship unattended |
| Auth, payments, or schema changes | Avoid parallel agents entirely | Human-only, one change at a time |
A regular Cursor Agent session is still the better tool for one well-scoped task you're actively watching. Projects earns its keep on the wide, repetitive kind of job — hundreds of similar small changes across a big codebase — where a coordinator dividing the work actually saves time instead of adding a review burden.
DevAegis ships your code encrypted so it only runs while the invoice is current. See how it works
The Real Risk Isn't the Agent — It's the Handoff
None of this is really about whether the agent is good enough. Even a perfect migration doesn't protect you once it ships. The risk freelancers and small agencies carry isn't code quality. It's what happens between "the build works" and "the client paid for it."
You can run the most careful, staged, human-reviewed Projects workflow in this article and still deliver a finished app to a client who stops answering emails on day 40. That's a separate problem from the one Cursor is solving, and it's worth thinking about before you hand anything over, agent-built or not. What you can still do once a client stops paying covers the options once you're already in that spot. Most of them are weaker than the leverage you had before delivery.
What This Looks Like on a Real Project
Picture a small agency migrating a client's aging e-commerce site off a discontinued platform. The coordinator handles the mechanical part well: swapping the build tooling, updating forty near-identical product-page templates, flagging deprecated API calls across the codebase. That's the 31-out-of-100 territory, and it moves fast.
The checkout flow is different. It touches payment state, session handling, and a legacy discount engine nobody fully documented. The agency treats it the way the benchmark suggests it should: only about a one-in-twenty shot of getting it right unsupervised. They pull it out of the parallel run, assign one subagent to draft it, and review every line before it merges. This is an illustrative example, not a specific client or product. The point is which parts got the coordinator and which parts got a human.
Frequently Asked Questions
What is Cursor Projects?
Cursor Projects is a beta feature, launched September 10, 2026, that adds a coordinator agent on top of the Cursor editor. The coordinator plans a larger job — a feature, a migration, or a full app — and delegates pieces of it to subagents running in parallel on Cursor's own cloud infrastructure, then brings the finished work back for you to review.
Is Cursor Projects safe to use on a client's production codebase?
Not unsupervised. A September 2026 benchmark, SWE Refactor Bench, tested coding agents on whole-repository migrations and found only 5.4% of 520 runs passed a full audit for completeness and behavioral correctness. Treat any agent-run migration as a draft that needs staged, human review before it touches a client's live site.
What's the difference between Cursor Projects and regular Cursor Agent mode?
Regular Agent mode is one agent working one task in your active editor session. Projects adds a coordinator layer above that. It can spin up many subagents at once, keep running after you close your laptop, and start work on its own from a schedule, a Slack channel, or your pull request activity.
Does Cursor Projects work better on some migrations than others?
Yes, and the gap is large. Independent benchmark testing found build-toolchain and dependency-style migrations scored 31.4 out of 100, while full language or framework rewrites scored 5.6 out of 100 on the same test. Match the job to the tool. Mechanical, repetitive changes are a much safer fit than a full rewrite.
Do I need a specific Cursor plan to use Projects?
Cursor's own changelog rolled Projects out in beta to existing accounts starting September 10, 2026, without publishing separate per-feature pricing. Check Cursor's own pricing page for current plan details before you quote a client a Projects-based timeline.
Before You Hand Anything Over
Whatever tool builds it, the moment of real exposure for a freelancer or small agency is delivery: the gap between "it's done" and "it's paid for." DevAegis encrypts the compiled build you hand over and holds the key on your side. If a client goes quiet after go-live, you can pause access instead of chasing invoices with nothing to show for it. It's disclosed in the delivery agreement upfront, the same way any licensed software already works.
See how the kill switch and audit trail work at devaegis.com, check plans at devaegis.com/pricing, or start at devaegis.com/signup. If you're already mid-dispute on a project you delivered unprotected, start here instead: Client not paying? What you can still do.
Key takeaways
- Cursor Projects, in beta since September 10, 2026, uses a coordinator agent that plans and delegates work to parallel subagents instead of writing code itself.
- Projects runs on Cursor's own cloud infrastructure, so a migration keeps going after you close your laptop.
- A September 2026 benchmark (SWE Refactor Bench) found coding agents pass only 5.4% of 520 full-repository migration audits, and just 5.6 out of 100 on language rewrites specifically.
- Build-toolchain and dependency migrations score far higher (31.4 out of 100) than language or framework rewrites, so match the job to the tool.
- Schema, auth, and API changes need serialized, human-reviewed changes — parallel subagents can't safely coordinate interdependent contracts.
Frequently asked questions
Straight answers to what people ask about cursor projects for client site migrations.
Stop handing over the leverage
Your code ships encrypted and runs only while you allow it. One toggle and their site shows a payment screen.
Protect Your Code
