Migrating Jobs

AI-Assisted Migration

Once your data is imported and mapped, the actual conversion to GitHub Actions happens with AI assistance in the GenAI Editor's migration mode. You can migrate jobs one at a time from the dashboard, or at scale using Migration Batches and the migration agent.

Migrating a Single Job

1. Select a job from the Migration Assistant dashboard
2. Click "Migrate in Editor" to open the GenAI Editor in migration mode
3. Review the source - examine the original job configuration from your source CI/CD instance
4. Use AI assistance - ask the Expert Workflow Agent to convert the job to GitHub Actions
5. Refine and test - iterate on the generated workflow with AI help
6. Create pull request - submit the new GitHub Actions workflow for review

Migration Mode Features

Enhanced Context

• Source-specific system prompts (Jenkins-aware AI assistance)
• Access to original source files (Jenkinsfiles, plugin configurations)
• Migration mapping context for accurate conversions

Specialized File Tree

• Source-side nodes showing original CI/CD files
• GitHub Actions workflow files for comparison
• Migration mapping references

Custom Syntax Support

• Jenkinsfile syntax highlighting
• GitHub Actions YAML with migration-aware suggestions
• Side-by-side comparison views

Azure DevOps Context

• Azure DevOps-aware AI assistance with understanding of ADO-specific concepts
• Access to original pipeline YAML, Classic definitions, and variable groups
• Automatic mapping of ADO expressions (${{ }}, $( ), $[ ]) to GitHub Actions syntax
• Multi-stage pipeline conversion to GitHub Environments
• Service connection to GitHub Secrets mapping
• Azure Pipelines YAML syntax highlighting alongside side-by-side comparison with the GitHub Actions format

Migrating Jobs with Dependencies

Many legacy jobs depend on reusable pipeline elements — Jenkins shared-library functions or Azure DevOps templates. Migration Assistant handles both cases: dependencies that are still legacy, and dependencies that have already been migrated to Building Blocks.

Already-Migrated Dependencies

When you launch Migrate in Editor for a job whose dependencies have already been migrated, a pre-checked checklist of those resolved dependencies appears in the launch dialog. Each entry shows the dependency's existing Building Block and its associated legacy repository.

• Pre-checked entries are included in the workspace by default, bringing their Building Block repository and legacy repository in as read-only context — the same behavior batch migrations use.
• Deselect an entry to exclude that Building Block's repository from the workspace. Re-checking it adds it back before you launch.

This lets you control exactly which already-migrated dependencies are available as context during the migration, without having to configure them manually.

Legacy Dependencies: Job + Dependencies Flow

When a job depends on reusable pipeline elements that haven't been migrated yet, you can migrate the job and its dependencies together.

Workspace Configuration

Choose "Include Building Block repositories in this workspace" during migration launch. This creates a workspace containing:

• The job's repository - where the calling job is defined
• The legacy reusable-pipeline repository - read-only context with the original function implementations
• The Building Block destination repository - where new Building Block Workflows will be created

Two-Step Migration Process

The AI agent follows an explicit two-step pattern when both job and dependency mappings are configured:

1. Create Building Block Workflows - Convert legacy library functions to Building Block Workflows in the destination repository
2. Update the calling job - Modify the job's pipeline to invoke the new Building Block Workflow instead of the legacy function

This ensures a complete migration in which the job actually uses the converted workflows, not one that merely creates them.

Legacy Repository Handling

The legacy reusable-pipeline repository appears in the workspace as read-only context:

• Source files are attached as linked files when paths are known
• The AI can read implementations but cannot write to the legacy repository
• Repository context clearly identifies it as legacy source for migration reference

Migration Batches

Migration Batches let you organize migration entities into curated collections for coordinated migration efforts. A batch is a cross-source collection of jobs and reusable pipeline elements that provides:

• Centralized Progress Tracking - View migration status across all batch members
• Repository Management - Configure repositories for batch members inline
• Scope Management - Add or remove entities from batches as needed
• Status Updates - Change migration status for individual entities within the batch

Creating and Managing Batches

Access Migration Batches from the Batches tab in Migration Assistant:

1. Create a batch - Click "Create Batch" and provide a name and description
2. Add entities - Use the entity picker to add jobs and reusable pipeline elements
3. Configure repositories - Set repositories for entities that need them
4. Track progress - Monitor migration status with live progress rollups

Batch Scope and Readiness

Batches can include jobs (individual CI/CD jobs from your legacy system) and reusable pipeline elements (functions and templates from shared libraries). Entities show "Not configured" when they lack a required repository, but this doesn't prevent adding them to batches — you can resolve repository configuration directly from the batch detail panel.

Batch Execution

Once a batch is configured, you can run migrations as background agent jobs directly from the batch detail page. The Batch Execution panel lets you start, stop, retry, and restart the agent across all batch members:

• Start - Launches the migration agent for the ready batch members. Start applies to your current selection in the batch scope grid: check specific rows to run just those, or start with nothing selected to run the whole batch. Before dispatching, the confirmation dialog lists unresolved template references separately from ordinary unmet dependencies, so you can tell a missing source from an item that's simply waiting its turn.
• Stop - Cancels in-progress agent runs for the batch
• Retry - Re-queues failed items without restarting items that already succeeded
• Restart - Resets all batch members and starts fresh

The agent respects a per-batch concurrency cap so jobs run in parallel without overwhelming your repositories. If you have more ready items than the cap allows, the remaining items queue automatically and start as running items complete.

Dependency gating ensures that items with unresolved dependencies wait until their prerequisites complete before the agent picks them up. If a dependency cycle is detected, the affected items are exempted from gating so the batch can still make progress.

Progress updates stream in real time via the clickable progress-bar legend at the top of the batch view. Click any segment (for example, In Progress or Ready for Review) to filter the batch scope grid to items in that state.

Building Block Blueprints in Batches

Building Block Blueprints — approved during pattern review in the mapping phase — are batch members alongside jobs and reusable pipeline elements. A blueprint describes the block a pattern needs: its name, destination, and interface of inputs, outputs, and secrets.

When a batch contains a blueprint and items that call it, CodeCargo dispatches the blueprint first, within the same batch concurrency cap. The consumers hold until the blueprint's pull request merges and the block is registered, then start automatically.

A blueprint can only be dispatched once it has a destination — the repository and path where its block will live. If a destination is missing, every start path holds that item and the batch page offers an inline control to set it; saving the destination releases the item immediately, without waiting for the next dispatch cycle.

Agent Communication

While the migration agent is running, it surfaces questions and status updates directly in the Migration Assistant interface, so you can monitor and guide large batch migrations without opening each workspace:

• Status reports - The agent posts progress updates as it works through each migration step, visible in the batch detail panel
• Questions - When the agent needs clarification (for example, which target repository to use or how to handle an ambiguous mapping), it pauses and asks you directly in the chat thread attached to that batch item
• Resolve in chat - Reply to the agent's question in the chat thread; the agent resumes automatically once it receives your answer
• BLOCKED - If the agent cannot proceed and no user response resolves the issue, the item moves to a terminal BLOCKED state. You can review the reason, update your mappings or repository configuration, and then retry the item

Not every pause comes with a question you can answer in place. When the agent replies conversationally rather than asking a structured question, the panel shows its message together with an Answer in the editor link that opens the workspace on the exact conversation holding it — reply there and the item resumes. Questions that carry suggested options or additional context keep their inline answer form, so you can respond without leaving the batch view.

Troubleshooting Migrations

AI conversion problems

• Provide more context about the original job's purpose
• Break complex jobs into smaller, focused workflows
• Review and adjust migration mappings for better AI context

Workflow validation failures

• Use CodeCargo's compliance features to identify issues
• Test workflows in a development environment first
• Iterate with the AI agent to resolve syntax and logic problems

Next Step

Migrating from Azure DevOps with repositories moved via ado2gh? Finish with Prepare Rewire to clean up lingering Azure DevOps references before rewiring your pipelines.