Migration Assistant

What Is Migration Assistant?

Migration Assistant moves your repositories to GitHub and converts your legacy CI/CD pipelines to GitHub Actions workflows. It connects to your source systems, imports their pipeline data, maps jobs, plugins, and credentials to their GitHub equivalents, and converts jobs with AI in CodeCargo workspaces. For a large estate, the Migration Plan runs that work as one program, in dated waves.

This page says what each source supports, which way to run a migration, how a migration flows, and what the terms on the other Migration pages mean.

What's Supported

Source	Pipelines	Repositories	Rewire
Jenkins	Available	—Not applicable	—Not applicable
Azure DevOps	Available	Available	Available
GitLabgitlab.com	Available	Available	AvailableIn a Migration Plan
GitLabSelf-managed	Available	Available	AvailableIn a Migration Plan
BitbucketData Center	—Not applicable	Available	—Not applicable
GitHub Enterprise ServerWorkflows move with the repository	—Not applicable	Available	—Not applicable

Jenkins doesn't host code, so its repositories move from wherever they live today. Bitbucket Cloud and Azure DevOps Server can't be used for repository migration because neither offers a repository migration export: Atlassian provides one only for Bitbucket Data Center, and Azure DevOps Server's only migration path is moving a whole collection to Azure DevOps Services with Microsoft's Data Migration Tool. Repository migrations copy each repository's Git LFS objects too.

Rewire keeps a source's pipelines building from the GitHub copies after the repositories move. Azure DevOps and GitLab do it differently, as Key Terms describes. Importing Data lists what each source's import brings in.

Which to Use

There are two ways to run a migration. Both use the same tools underneath.

• The Migration Plan runs an Azure DevOps, GitLab, or Jenkins estate as one program: a dry run, destination orgs, dated waves, and reports for stakeholders. Use it when you want dated waves, several destination orgs, or both. A plan lives in a CodeCargo organization created for the migration, the sandbox, and each wave moves into the production orgs you choose. Only an organization admin can start a plan, and the Migration Plan is available on CodeCargo plans that include it.
• The tool pages on their own, from Connecting Sources to Prepare for Rewire, worked in your own organization. Use them for Bitbucket Data Center and GitHub Enterprise Server repositories, which a plan doesn't cover, for a move into a single organization, or when you don't want a plan.

Rewiring Azure DevOps pipelines works either way. Rewiring GitLab projects runs only in a plan.

How a Migration Flows

Every source starts with a connection. Connecting Sources connects Azure DevOps, GitLab, Bitbucket Data Center, and GitHub Enterprise Server, inventories their repositories, and can sync Azure DevOps and GitLab pipelines. Jenkins jobs come in through the importer. From there, a migration moves through five broad phases, each covered in detail on its own page:

1. Migrate Repositories (Azure DevOps, GitLab, Bitbucket Data Center, and GitHub Enterprise Server) - Copy repositories to GitHub from inside CodeCargo. Each copy is recorded so the later phases know where every repository went.
2. Import - Bring pipeline data in from Jenkins, Azure DevOps, or GitLab. On a connected Azure DevOps organization or GitLab group, turn on pipeline sync and CodeCargo imports for you; otherwise run the importer against your live instance, or upload a JSON export. Post-import discovery then maps the dependencies between your jobs, shared libraries, and templates.
3. Map - On the Migration Mappings page, match legacy jobs to GitHub repositories and building blocks, plugins to GitHub Actions, and credentials to GitHub secrets or variables.
4. Migrate - Convert jobs to GitHub Actions workflows with AI assistance — one at a time in the GenAI Editor, or at scale with Migration Batches and the migration agent.
5. Prepare for Rewire (Azure DevOps) - Once repositories have moved to GitHub and their pipeline definitions are imported, fix lingering Azure DevOps references and rebind the pipelines onto the copies, so they keep building until you map and migrate them. It does not wait for those two phases.

You don't have to complete each phase for every job before starting the next — most teams import everything, then map and migrate in incremental batches. Repositories already on GitHub, or moved with gh ado2gh outside CodeCargo, skip the first phase.

Every job and reusable pipeline element carries a migration status that drives the progress bars and completion figures. See Migration Status Lifecycle.

How the Plan Drives the Tools

A Migration Plan runs these same phases for you. Its dry run is a set of repository migrations in the sandbox, and each wave's move is a repository migration in each destination org. Converting a wave sets up a Pipelines wave and its batches in each destination org. Rewiring a wave runs Prepare for rewire in each destination org, from the decisions you made once in the sandbox. How the Plan Drives the Tools maps each plan step to the page that covers it, and says where you act.

The Migration Assistant Sidebar

Migrate, the last group of the organization sidebar, holds one entry: Migration Assistant. Choosing it opens Plan when you can use the Migration Plan. Otherwise it opens Pipelines, or, if you can't use Pipelines, the first section you can.

Inside Migration Assistant, the sidebar lists the tool's own sections in place of the organization's. Back to followed by your organization's name returns to the organization dashboard. Below it:

• Plan - The Migration Plan: the journey, waves, destination orgs, and the dry run. Listed when your CodeCargo plan includes the Migration Plan.
• Repositories - The repositories CodeCargo can see through its source connections, the repository migrations run against them, and the custom properties those migrations stamp. See Migrating Repositories.
• Pipelines - The imported pipelines, with Sources, Batches, and Waves tabs. See The Pipelines Dashboard, Migration Batches, and Pipelines Waves.
• Connections - The source systems connected to CodeCargo, and where a new one is connected. See Connecting Sources.
• Reports - The plan's reports, listed once the plan has started.

On the other sections, Plan shows how many plan steps need you, when any do. It takes you back to the plan page you last opened in this browser, or to the plan's Overview. Favorite and recent projects are hidden until you go back to the organization.

These pages write a section and its tab as a path, such as Migration Assistant → Repositories → Migrations.

If your CodeCargo plan doesn't include Migration Assistant, the entry is locked. An organization Member doesn't see it. See Migration Assistant Access.

Key Terms

These pages use one word for each idea below, and say which one they mean where a word has more than one.

• The sandbox - The CodeCargo organization a Migration Plan lives in, created for the migration. The plan's dry run copies repositories into its GitHub organization, and you work through the plan there. It is never a destination. Close Out asks you to archive it once the last wave has moved.
• Destination org - A production GitHub organization that plan waves move repositories into. Once connected, it is linked to a CodeCargo organization of its own, where each wave prepares its migrations, its conversion, and its rewire. See Plan the Org Layout.
• Wave - Three things carry the name:
  • A plan wave is a dated group of repositories a Migration Plan moves together, with their pipelines. See Schedule Waves and the Wave Page.
  • A Pipelines wave is a group of jobs and reusable pipeline elements you convert together under Migration Assistant → Pipelines → Waves. See Pipelines Waves.
  • When a plan wave converts pipelines, the plan writes a Pipelines wave of its own in each destination org, named for the plan wave, and decides what it holds. See A Wave the Plan Converts.
• Dry run - Two things share the name. The plan's Dry run phase copies the plan's repositories into the sandbox before any wave moves them. See Dry Run. The Dry run switch on the Prepare for rewire page stops an organization from rebinding pipelines, and a plan turns it on in the sandbox. See Dry-Run Organizations.
• Rewire - Keeping a source's pipelines building from the GitHub copies after the repositories move:
  • For Azure DevOps, update pull requests point references at the GitHub copies, and each pipeline is rebound onto its GitHub repository, so it keeps running in Azure Pipelines. See Prepare for Rewire. In a plan, the Prepare the Rewire step reads the sandbox's decisions, and each wave's Rewire pipelines stage carries them to its destination orgs.
  • For GitLab, each moved project gets a pull mirror of its GitHub copy and reports pipeline status to it, so its pipelines keep running in GitLab. It runs only in a Migration Plan, and needs GitLab Premium or Ultimate. See Rewiring GitLab Projects.
• Converged - In a Migration Plan, a pipeline is converged once it is migrated or done externally. See How Conversion Is Going. In a job's migration status, a GitHub Actions workflow reads Converged in place of Migrated once it calls its building block, and Already converged in place of Uses existing. See Migration Status Lifecycle.
• Job and pipeline - Jenkins calls a build unit a job, and Azure DevOps and GitLab call it a pipeline. The tool pages say job for any source, as Source-Aware Terminology describes. The plan pages say pipeline, and count Jenkins jobs among the pipelines a plan converts.
• Move, migrate, and convert - Repositories move, or migrate, to GitHub. Pipelines convert to GitHub Actions workflows. The tool pages call converting a job migrating it, as the app's Migrated status does.

On the Free Plan

On the free plan, Migration Assistant limits how much you can bring in and how much you can run.

In the repository picker on the connect pages and the import pages, you choose what to include:

• At most 10 repositories in the source inventory at a time. This is separate from the GitHub repositories you activate. Change the selection to hold different repositories. If a connection already holds more than 10, narrow it in the picker.
• At most 10 imported pipelines at a time.

In all, the free plan moves 10 repositories to GitHub and converts 10 pipelines. A finished move or conversion still counts.

Discovery and planning are not counted against these limits. Organization Settings → Usage & Budget shows how much of each limit you have used. Upgrade your plan to go further.

Source-Aware Terminology

Migration Assistant displays entity types using each source platform's native vocabulary while maintaining a stable internal data model. This ensures the interface feels natural regardless of your source CI/CD system.

This terminology layer applies across the overview landing, scoped entity tables, and mapping pages. When viewing data from multiple sources simultaneously, the interface falls back to neutral cross-platform terms for aggregate views while preserving source-specific labels in detailed breakdowns.

These docs use the neutral terms job (a build unit), plugin (an extension), and reusable pipeline element (a function, template, or include from a shared library, template repository, or component project) when a statement applies to more than one source system.

Why Enterprises Migrate with CodeCargo

GitHub's importers move code and convert files. An enterprise migration is a program: thousands of pipelines across Jenkins, Azure DevOps, and GitLab, shared libraries and templates tying them together, plugins and credentials with no one-to-one equivalent, and a deadline. CodeCargo's migration agents do the conversion work, and your engineers review and approve the results.

CodeCargo vs. GitHub's Importers

In the Service Catalog

On the Service Catalog graph, a Migration Assistant card holds your imported jobs. Expand it to see each job with its migration status, linked to the repository it is mapped to. Select a job to see its type, repository, folder, migration status, and detected operations, with Migrate in Editor when you can manage Migration Assistant.

Best Practices

• Start small - Convert a few simple jobs, and check their repository and plugin mappings, before you run large batches.
• Use Building Blocks - Map recurring patterns to Building Blocks so converted pipelines call one shared workflow.
• Recreate credentials early - Credential values are never imported. Add each GitHub secret or variable under the name you mapped before the converted workflows run.
• Test before production - Run converted workflows in a test environment, and use Workflow Compliance to catch issues.
• Check what still points at the source - Before you turn a source off, check the migrated copies for leftover references, such as Ready to Turn Off GitLab for GitLab.