Importing Data into Migration Assistant

Import Overview

The first phase of any migration is getting your legacy CI/CD data into Migration Assistant. There are two ways to import from each source system:

Run the importer - A containerized importer connects to your live Jenkins instance or Azure DevOps organization and extracts data directly through its API. This is the standard path.
Upload a JSON export - If you already have a pre-exported JSON file (for example, produced by an earlier importer run or shared by another team), upload it under Migration Assistant → Import → JSON and continue straight to the mapping wizard.

In both cases, only metadata and configuration are imported. Sensitive credential values are never extracted or stored — credentials are imported as definitions only, and you recreate their values as GitHub Secrets during mapping.

Setting Up the Importer

The Jenkins and Azure DevOps importers run as a Docker container on your machine (or any host with network access to your source system) and connect back to CodeCargo using a downloaded credentials file. Setup follows three steps, designed so that sensitive tokens never appear in your shell history:

Log in to the registry - Authenticate with the CodeCargo container registry using your generated token
Configure and download the credentials file - Configure the connection in the CodeCargo UI, then download the generated .env file
Run the importer - Execute the Docker container using the credentials file

Configuring the Connection

You configure the importer in the CodeCargo UI before downloading the credentials file, rather than hand-editing the .env file afterwards:

Jenkins - Provide your Jenkins controller URL. localhost is rejected, since inside the importer's container localhost refers to the container itself rather than your host machine; use http://host.docker.internal:8080 for a Jenkins instance running locally.
Azure DevOps - Provide your organization name (a full URL is rejected here) and choose an import scope: specific repositories via a CSV list, specific project names, or everything in the organization.
On-premises Azure DevOps Server - Toggle On-Premises Server under the organization field to switch to a full server URL. The scope CSV template is automatically stamped with the URL's collection segment, which the importer matches against.

Once your configuration is complete, the page shows a summary of what will be downloaded — organization or server, scope, and import mode. Click View file contents if you want to inspect the raw .env file before downloading. The Download button stays disabled until your configuration is complete, and if you change settings after downloading, a warning lets you know the downloaded file is stale.

Environment-Aware URLs

The importer setup page automatically displays the correct controller and registry URLs for your environment (development, staging, production). Local development mode pre-populates the Jenkins URL as http://host.docker.internal:8080 for convenience.

The Credentials File

The downloaded .env file includes:

Pre-filled CodeCargo API credentials
Template entries for your source-system authentication — Jenkins URL, username, and API token, or your Azure DevOps Personal Access Token
Import mode configuration (if not using the default merge-keep mode)

Fill in the source-system authentication entries locally in your editor — these secrets stay on your machine and are never sent to or stored by CodeCargo. After the import completes, delete the credentials file to remove sensitive tokens from your local filesystem.

Jenkins Import

Start a Jenkins import under Migration Assistant → Import → Jenkins. The importer extracts data directly from your Jenkins API.

What Gets Imported

Jobs and Pipelines - All job configurations and pipeline definitions
Plugins - Installed plugins and their configurations
Credentials - Credential definitions (values are not imported for security)
Shared Libraries - Global pipeline libraries
System Configuration - Relevant Jenkins system settings

Azure DevOps Import

Start an Azure DevOps import under Migration Assistant → Import → Azure DevOps. The importer extracts data directly from the Azure DevOps REST API.

What Gets Imported

YAML Pipelines - Modern Azure Pipelines definitions from azure-pipelines.yml files
Classic Build Definitions - Legacy build configurations (flagged as anti-patterns)
Classic Release Pipelines - Release definitions and deployment stages
Tasks and Templates - Referenced tasks and reusable template dependencies
Service Connections - External service integrations
Variable Groups - Shared variables and secret references
Secure Files - Certificate and key file references
Agent Pools - Build agent configurations
Environments - Deployment target environments

Pipeline Types

Azure DevOps pipelines are handled differently based on their type:

YAML Pipelines

The pipeline source file (e.g. azure-pipelines.yml) lives in its repository. When you launch a migration workspace, the file is attached as a read-only linked file so the AI agent can read it directly from disk — the content is not copied onto the entity record.
Template and task references are tracked for dependency mapping.

Classic Pipelines

Build and Release definitions are imported as JSON because no in-repository file exists; the imported definition is the source of truth.
Can be viewed through the "View Pipeline Definition (JSON)" option.

Repository Linking

For YAML pipelines to appear correctly in the migration workspace, ensure the source repository is linked and active in your CodeCargo organization. See GitHub Integration for how repositories are connected.

Repository Link Resolution

When importing Azure DevOps pipelines, Migration Assistant resolves each pipeline's repository link using two facts, in order:

Relocation map — if the source repository was migrated to GitHub with GitHub Enterprise Importer (ado2gh), the pipeline links to its migrated repository using the confirmed mapping traced from the Migration Log.
Repository name match — for pipelines whose repository wasn't migrated with ado2gh (or hasn't been traced yet), Migration Assistant falls back to matching against your CodeCargo repository names.

A pipeline's existing repository link is never cleared by an import that can't resolve a reference — a link is only ever replaced by a positive match, so re-importing after editing your source data can't accidentally undo a manual mapping.

ado2gh Repositories

If your pipeline's repository was migrated with GitHub Enterprise Importer, you don't need to manually map it — Migration Assistant links it automatically from the Migration Log once post-import discovery runs, even if the initial import couldn't resolve it by name.

Anti-Pattern Detection

The Azure DevOps importer automatically identifies legacy patterns that should be modernized:

Classic Build/Release pipelines - Flagged for conversion to YAML
Deprecated tasks - Tasks that have newer alternatives
Security anti-patterns - Configurations that don't follow current best practices

These anti-patterns are highlighted during the mapping process to help prioritize modernization efforts.

Post-Import Discovery

After an import completes, Migration Assistant automatically analyzes your source data to map reusable-code dependencies. Discovery results surface in the dashboard and detail panels to help you plan migration order.

Jenkins Shared-Library Discovery

Migration Assistant runs post-import discovery for Jenkins shared libraries, building a comprehensive inventory of library dependencies:

Library Surface Scanning - Inventories all shared-library entrypoints and available functions
Usage Resolution - Associates each imported job with the library elements it uses
Dependency Mapping - Creates intra-library reference edges and job entrypoint relationships
Inline Script Analysis - Analyzes jobs with inline pipeline scripts without requiring repository mapping

Discovery parses the Groovy source of your Jenkins pipelines and shared libraries to extract structural facts, providing detailed insights into library usage patterns across your organization.

Automatic Discovery

Shared-library discovery runs automatically after Jenkins import and can analyze both repository-backed jobs and jobs with inline pipeline scripts.

Azure DevOps Pipeline Template Discovery

Migration Assistant analyzes imported Azure DevOps pipelines to identify reusable template references and track their availability:

Resolves template chains - Follows extends and template references to build the complete dependency graph
Cross-repository resolution - Identifies templates in other repositories within your workspace
File status tracking - Verifies whether referenced template files actually exist
Dependency mapping - Creates a persistent graph of template relationships

Pipeline entities display status badges in the dashboard and detail panels:

Badge	Status	Description
Source missing	Red	The pipeline's source file cannot be found
Pending scan	Yellow	Template references an unprovisioned but known repository
Unknown repo	Gray	Template references a repository not in CodeCargo

Discovery runs automatically after import, but you can trigger it manually from Migration Assistant → Dev Tools → Run Discovery, selecting the organization or a specific instance and monitoring progress in the job logs.

Discovery Scope

Discovery resolves same-repository template chains completely and performs one hop of cross-repository resolution. Templates in unprovisioned repositories are flagged for future processing when those repositories are added to CodeCargo.

Entity Dependencies and Impact Analysis

After discovery runs, Migration Assistant builds a persistent dependency graph that powers the Dependencies and Used by sections in every entity detail panel.

Dependencies (what a job relies on)

When you open a job's detail panel or in-editor view, the Dependencies section lists every entity that job relies on — reusable pipeline elements (templates, shared-library functions) and task plugins discovered from the pipeline source. Each entry shows the dependency's name, type, and migration status so you can assess readiness at a glance. Container-level entries (e.g., a shared library) are collapsed when a more specific element from that library is already listed, keeping the list focused.

Used by (what relies on a plugin)

Plugin entities (Azure DevOps tasks, Jenkins plugins) display a Used by section listing every job and template that references them. This lets you understand the blast radius of a plugin before you migrate or deprecate it.

Plugins are context, not migration units

Plugin entities are tracked in the dependency graph for impact analysis but are not migration units themselves. They never appear in the batch dependency advisory and cannot be added to a migration batch — only jobs and reusable pipeline elements are batch members.

Troubleshooting Imports

Connection failures

Verify the source URL and authentication credentials in your credentials file
Check network connectivity and firewall rules between the importer container and your source system
For Jenkins, ensure the Jenkins API is enabled and accessible; remember that localhost inside the container is not your host machine

Incomplete data import

Review the source-system permissions of the importing user — the importer can only see what that account can see
For Jenkins, check for plugin compatibility issues and verify Jenkins version compatibility

Next Step

With your data imported and discovery complete, continue to Mapping to configure how it translates to GitHub Actions.