Migrate 50 Files from REST to GraphQL
Scope a 50-file REST-to-GraphQL migration, split it into conflict-free work packages, and run them all at once with batch sessions.Scope the migration with Ask Devin
You have 50 files that import from This tells you whether parallelization makes sense. If most files are tightly coupled across domains, a sequential migration is safer. Here, 6 of 8 domains are fully independent — you can run them in parallel.
src/lib/restClient.ts and need to move to the new graphqlClient. Before splitting anything into parallel work, you need to know how those files are connected. Use Ask Devin to map the migration surface area — which files import the legacy client, how they cluster by domain, and where the risky coupling lives. Devin uses DeepWiki and semantic search under the hood, so it can answer these questions grounded in your actual code.Open Ask Devin and ask:Ask Devin returns a breakdown like this:Create a migration playbook
Every parallel session should follow the same migration pattern so the resulting PRs are consistent and easy to review. Create a playbook that defines exactly how each file should be migrated.Go to Settings > Playbooks > Create Playbook and define the steps:Or use Advanced Devin to generate the playbook for you — describe your migration pattern and it will produce a complete playbook:Referencing this playbook in your orchestration prompt ensures all parallel sessions produce PRs that look like they came from the same developer.
Launch parallel sessions with Advanced Devin
Open Advanced Devin (the sparkle icon in the web app) and give it the orchestration prompt. Advanced Devin analyzes your codebase’s dependency graph, creates independent work packages, and launches one batch session per package — all running simultaneously.Advanced Devin presents a grouping for your approval before launching anything:Approve the grouping and six sessions launch at once. Auth runs first, then Admin follows once Auth merges.
Review and merge the results
Each session opens its own PR. Since the packages are independent, you can review and merge them in any order — but merge Auth first since Admin depends on it, and run full CI after each merge to catch any unexpected interactions.Once all 8 migration PRs are merged, use a follow-up session to clean up dead code:
