How do you migrate from Azure Pipelines to Jenkins without stopping releases?
Teams migrate from Azure Pipelines to Jenkins by running both systems in parallel: they convert one pipeline at a time, prove each converted Jenkinsfile on a non-production branch, and cut over per project once the Jenkins build and deployment match the Azure Pipelines result. Releases keep flowing through Azure Pipelines until a project has passed that check. The work is usually done by platform engineers working alongside the pipeline owners, because the platform team knows the agents and the pipeline owners know which stages, approvals and deployment targets must not change. Jenkins is distributed under the MIT License, so the software itself carries no per-agent or per-parallel-job fee, but the agents, controller hosting and plugin upkeep become your cost to plan.
Conversion of YAML stages, jobs and templates into Jenkinsfiles is the tractable part. Most of the effort is in the parts that do not translate line by line: service connections and variable groups must be recreated as Jenkins credentials, and because Azure Pipelines does not return secret values, each one has to be re-entered from its source system. Confirm with each owner which secrets are still valid and who can rotate them. Windows and .NET build dependencies carry the second largest risk. Check which SDKs, MSBuild versions and signing tools the build needs, and whether they can run on Linux pod agents or require Windows agents that you must provision and patch yourself.
Decide early whether Azure Repos moves with the pipelines. Jenkins can build from Git repositories hosted elsewhere, so you can keep Azure Repos and point Jenkins at it, or move repositories to a self-hosted forge at the same time. Moving both at once doubles the cutover risk, so most teams split the decisions. Before you retire any Azure Pipelines project, export run history, logs and artifacts, since these are not carried over automatically, and record the agent pool and deployment configuration each project depends on. Ask your Jenkins partner or internal team to document the rollback path for each project so a failed cutover reverts to Azure Pipelines within the same release window.
Which Azure Pipelines capabilities map to Jenkins, and which need rework
This table maps each main Azure Pipelines capability to its closest Jenkins equivalent and marks it as clean, needs rework or gap. Read the status column first, then the reason, to decide where pipeline definitions can move almost unchanged and where credentials, agents and approvals need separate planning. Most of the effort sits in secrets, Windows and .NET builds, and approval gates.
| Azure Pipelines capability | Jenkins equivalent | Status and reason |
|---|---|---|
| YAML stages, jobs and steps | Declarative Jenkinsfile stages and steps | Needs rework: the structure maps directly, but task names and YAML keys must be rewritten as Jenkins steps. |
| Templates and reusable YAML | Shared libraries and Jenkinsfile functions | Needs rework: template parameters must be re-expressed as Groovy functions in a shared library. |
| Classic release pipelines | Pipeline deployment stages | Needs rework: release stages, artifacts and environments must be rebuilt as Jenkins pipeline stages in source control. |
| Service connections | Jenkins credentials (stored in the controller) | Needs rework: connection values cannot be read back from Azure DevOps, so each credential must be re-entered and rotated. |
| Variable groups and secret variables | Jenkins credentials and Configuration as Code settings | Needs rework: secret values cannot be exported, so re-creation and a rotation plan are required before cutover. |
| Microsoft-hosted and self-hosted agent pools | Kubernetes pod agents or dedicated build agents | Clean for Linux containers: each job can run in a pod image. Gap for Windows agents, which need separate hosts. |
| Windows agents and .NET tooling | Windows build agents with .NET SDKs installed by the team | Needs rework: Windows agents, MSBuild, signing and .NET SDK images must be built, patched and maintained by the team. |
| Manual approvals and checks | Jenkins input step or approval plugin | Gap until confirmed: approval gates depend on the plugin set in use, so confirm which plugins and roles your organization requires. |
| Pipeline artifacts | archiveArtifacts step and external artifact repositories | Needs rework: retention is set on the Jenkins side, so define retention and export existing artifacts before the Azure DevOps retention window closes. |
What data and integrations can you export, and which must be re-created?
Some Azure Pipelines assets move cleanly into a Jenkins project, while others cannot be read back from Azure and must be rebuilt by hand. Sorting them before cutover keeps the migration from stalling on secrets or lost history. The cards below separate what you can export, what you must re-create and what you need to rewire.
YAML definitions already in the repository
Azure Pipelines YAML files are already stored in your Git repository, so they travel with the code and remain the reference for translating stages, jobs and templates into a Jenkinsfile. Keep the YAML under version control until the Jenkins pipeline has run successfully on the same commits. Check which template references and variable group names the YAML pulls in, because each one needs a Jenkins equivalent before the pipeline can run.
Classic pipeline definitions via REST API
Classic release and build definitions are not stored in Git, so they must be pulled from the Azure DevOps REST API as JSON before they are deleted or disabled. Save each definition with its task versions and variable references, then map it by hand to a Jenkins deployment stage. Ask Microsoft's current documentation which definition types the API returns for your organization, because coverage differs between build and release objects.
Run history, logs and artifacts
Run history, logs and published artifacts are kept by Azure for a limited period and are not automatically moved to Jenkins. Export the records you need for audit or rollback to your own storage before decommissioning the Azure organization. Confirm the retention settings for your Azure DevOps organization in the Azure documentation, since the period depends on the configuration you have.
Secret variables and service connection values
Secret variable values and service connection secrets cannot be read back from Azure Pipelines. Their names and types can be listed, but the values must be supplied again, so plan to re-create each one as a Jenkins credential with a controlled rotation. Start with the production deployment credentials, because a stale token there blocks the cutover more than any YAML change.
Repository webhooks and build triggers
Azure Repos and other forges send webhooks that start Azure pipelines on push or pull request events. Each trigger must be reconfigured to call the Jenkins controller, and branch filters and path filters must be copied across. Test each trigger on a non-production branch, because a missed webhook can silently stop builds rather than failing loudly.
Azure Boards links and Artifacts feeds
Azure Boards work item links and Azure Artifacts feeds are separate integrations that Jenkins does not inherit. Decide whether work item references in commit messages still need to resolve, and where package feeds will be hosted after migration, since build steps that publish or restore from them need new endpoints and credentials. Confirm feed authentication with your package managers before removing the Azure feed.
What are the migration steps from inventory to decommissioning Azure Pipelines?
This sequence moves Azure Pipelines builds to Jenkins one repository and environment at a time, with each phase closed by a written output that proves the new pipeline matches the old one before the old one is switched off.
Inventory pipelines, variables, connections, agents and artifacts
Engineering leads and the platform team list every pipeline in the Azure DevOps organization, including YAML definitions, classic release pipelines, variable groups, service connections, agent pools and the artifacts and run logs each one produces. Each item is tagged with its owner, target environment and whether it deploys to production. The output is a conversion register that maps each pipeline to a Jenkinsfile target, a credential map that lists every secret and service connection that must be re-created because Azure DevOps does not return secret values, and an agent inventory. The step is done when the owners of each pipeline have reviewed their rows.
Pilot one low-risk pipeline on a Kubernetes pod agent
The team picks one non-production pipeline with few secrets and no classic release steps, converts it into a Jenkinsfile committed to the same repository, and runs it on a Kubernetes pod agent using the Jenkins Kubernetes plugin. Secrets are stored as Jenkins credentials and referenced by ID, not copied into the file. Configuration that must be reproducible is captured in Configuration as Code YAML, and plugins are declared in the Docker image or Helm chart rather than installed by hand. The output is a passing pilot build, a short list of translation gaps for the conversion register, and a decision on whether the pattern is repeatable for other pipelines.
Convert the remaining pipelines by group
Engineers convert the remaining pipelines in batches, starting with the pipelines that share templates, since shared Azure Pipelines templates usually map to a Jenkins shared library. Each conversion updates the conversion register with its status, the Jenkins job it created, and any plugin the job requires. Pipelines that depend on Windows agents or .NET tooling are flagged early, because their agent design needs a separate decision. The output is a complete Jenkinsfile set for every in-scope pipeline, with each entry in the conversion register marked either ready for parallel run or blocked with a named reason.
Run both systems in parallel and compare outputs
For a defined period, Azure Pipelines and Jenkins build the same commits from the same repositories. The team compares build status, test results, package checksums or image digests, deployment manifests and logs, and records every difference. Differences caused by timestamps, build numbers or agent images are documented as accepted, and anything else is investigated before cutover. The output is a signed-off comparison of build outputs for each pipeline, approved by the pipeline owner and a security reviewer. Only pipelines with an approved comparison move on.
Cut over repository by repository and environment by environment
The team switches triggers for one repository at a time, starting with non-production environments, then moves production deployments after the non-production cutover has run cleanly. Azure Pipelines triggers are disabled only after the Jenkins trigger is confirmed to fire on the same branch events. Rollback steps for each pipeline are written down and rehearsed before the production switch. The output is a cutover record per repository and environment showing the date, the approver, the rollback path and the first successful production run on Jenkins.
Export artifacts and logs, then decommission Azure Pipelines
Before the Azure DevOps pipelines are removed, the team exports the artifacts and run history that must be retained for audit or rollback, along with the YAML and classic definitions kept as a record. Retention settings are reviewed so that no build output expires before it is exported. Pipeline definitions are disabled, service connections and variable groups are removed, and agent pools are retired once no pipeline depends on them. The output is an archive index listing what was exported, where it is stored and who can read it, plus a decommissioning record signed off by the security and platform leads. Confirm the retention limits of your Azure DevOps plan and any compliance archive requirements with your auditors before this step starts.
How the Jenkins controller, agents and secrets fit together after the move
Plan the Jenkins controller as a coordinator, not a build machine. The Jenkins scaling guide recommends dedicated build agents so the controller only handles HTTP requests and manages the build environment. In practice, every Azure Pipelines agent pool you migrate becomes a set of Jenkins agents, and the Kubernetes plugin's pod templates replace the Microsoft-hosted or self-hosted VMs you used before. Decide early which workloads need Windows or macOS agents, because the pod model covers Linux containers well and those images need their own sizing and maintenance. The Jenkins scaling guide describes how to grow by adding controllers for new teams or projects rather than loading one controller with everything.
Treat $JENKINS_HOME on the controller as the system of record. Configuration, plugins and secrets all live there, so it is the first thing to back up and the first thing to restore in a recovery test. The Configuration as Code plugin lets you define global settings, security realms and credentials references in YAML files located through the CASC_JENKINS_CONFIG variable (default $JENKINS_HOME/jenkins.yaml). Its documentation states that it does not install plugins, so the plugin set must come from a pinned Docker image or the Helm chart. Keep the plugin list in version control next to the YAML, and confirm the exact plugin versions against the Jenkins LTS changelog before each upgrade, since some bundled plugins were removed from the bundle in the 2.580.1 release.
For availability, the scaling guide describes a primary and backup controller arrangement in which a proxy such as HAProxy or F5 routes traffic to the backup if the primary fails. Confirm that the backup is kept in step with the primary's $JENKINS_HOME and that failover has been tested, because a stale backup can restore old credentials or job definitions. Credentials are the hardest part to move. Azure Pipelines secret variables and service connections cannot be read back, so you re-enter them into Jenkins credentials, ideally through Configuration as Code references, and rotate them at the same time. Record which credential IDs each Jenkinsfile uses, and check that agents can reach the secret store without the controller passing values to them in plain logs.
What drives the cost and duration of the migration
This table lists each cost component of moving Azure Pipelines to Jenkins, who carries it, whether it is one-time or recurring, and what pushes it up or down. Read it as a checklist for scoping a fixed-scope quote, because the largest effort usually comes from the number of pipelines, secrets and Windows-specific steps rather than from Jenkins itself.
| Driver | Why it changes cost or effort | How to keep it down |
|---|---|---|
| Number of pipelines and templates | Each YAML pipeline, classic release pipeline and shared template must be rewritten as a Jenkinsfile or shared library function and tested. Template reuse multiplies the effect of a single error. | Inventory pipelines and templates first, group near-identical ones, and convert shared templates once into a shared library. |
| Service connections and secret variables (one-time) | Secret values cannot be read back from Azure DevOps, so every service connection and secured variable must be re-created in Jenkins credentials by someone who holds the source values. Count them early. | Rotate credentials during the move, remove unused connections, and use short-lived or workload identity where the target supports it. |
| Windows and .NET build needs | Azure Pipelines hosted Windows agents and .NET tooling need Windows build agents or specific Jenkins agent images. Windows-only steps often require separate testing and more agent maintenance. | Confirm which builds truly need Windows, containerize Linux-compatible steps, and isolate Windows agents in their own pool. |
| Plugin count and maintenance (recurring) | Each Jenkins plugin carries its own update cycle and compatibility risk. Some plugins are no longer bundled with the controller, so administrators must install them explicitly. Confirm which plugins the converted pipelines need. | Keep the plugin list short, pin versions in code, and review plugin updates on a fixed schedule. |
| Controller and agent infrastructure (recurring) | The controller hosts configuration, plugins and secrets in $JENKINS_HOME, and agents run the builds. Capacity, backup, and any primary and backup controller arrangement add hosting and operations work. | Use dedicated build agents on Kubernetes so the controller only coordinates work, and back up $JENKINS_HOME on a fixed schedule. |
| Parallel run and cutover (one-time) | Running Azure Pipelines and Jenkins side by side to compare results adds temporary compute and staff time. Length depends on the number of pipelines and release risk. | Migrate in waves by application, and retire each Azure Pipelines definition once its Jenkins replacement is verified. |
| Team hours for conversion and testing (one-time) | Engineers must convert YAML syntax, classic release stages, approvals and variable scoping, then test each deployment path in a non-production environment. | Reuse a tested Jenkinsfile template for similar services and export run history and artifacts before the source is retired. |
| LTS upgrades and Java support (recurring) | Jenkins LTS baselines and the supported Java versions change over time, so the controller and agents need periodic upgrades and plugin regression testing. | Plan upgrades on the published LTS cadence, keep agent images versioned, and include upgrade tests in the pipeline. |
What usually goes wrong when Azure Pipelines moves to Jenkins?
Most failed Azure Pipelines to Jenkins migrations trace back to a handful of avoidable gaps: secrets, plugins, undocumented pipeline behavior, agent tooling, lost history and cutover planning. Each card below names one risk and the check that prevents it, so the team can plan the work before the first pipeline moves.
Secrets re-created with wrong scopes
Azure DevOps secret variables and service connections cannot be read back once set, so every value must be re-entered in Jenkins credentials. Teams often store them at the global scope, which lets any job read them. Assign each credential to a folder or job, use the narrowest credential type that works, and record which pipeline owns each one. Confirm the old values are rotated, not copied, when the source system is retired.
Plugins removed in an LTS upgrade
Jenkins LTS 2.580.1 stopped bundling several plugins, including the bouncycastle API, SSH server and JUnit plugins. A team that upgrades without checking will find builds failing after the controller restarts. Before any upgrade, list every plugin the pipelines call, install the ones no longer bundled through the plugin manager, and test the upgrade on a staging controller first.
Undocumented Azure Pipelines variables and conditions
Predefined variables such as build source and agent paths, along with template expressions and conditions on stages, often hold logic nobody wrote down. These values silently change meaning in Jenkinsfiles, so a deploy step can run on the wrong branch. Inventory every variable and condition used in the YAML, map each one to its Jenkins equivalent, and run both systems side by side on the same commit to compare outputs.
Build agents missing required tools
Microsoft-hosted agents ship with many SDKs and CLIs preinstalled, while a Jenkins agent starts with only what the operating system provides. Builds then fail on missing compilers, Node versions or Windows-only tooling. Document the toolset each pipeline assumes, bake it into container images used as Kubernetes pod agents, and pin tool versions so a rebuilt agent behaves like the old one.
Lost artifact and run history
Azure Pipelines run logs, artifacts and retention settings do not move into Jenkins automatically. Once the old organization is closed or its retention window passes, that evidence is gone, including records auditors may ask for. Export run history, logs and artifacts before the cutover date, store them in a location with its own retention policy, and confirm the export restores with a test read.
Cutover without a rollback path
Switching every pipeline on one date leaves no way back if a Jenkins deployment stage misbehaves. Move one service or branch at a time, keep the Azure Pipelines definitions and service connections intact until the new pipelines pass several releases, and write down the step that restores the old path. Agree the rollback owner and the go or no-go criteria in writing before the first production deploy runs from Jenkins.
How the migration changes by team size and starting point
Teams whose code lives in Azure Repos face the largest scope, because moving CI to Jenkins does not move the repositories, boards or pull request workflow that Azure DevOps provides. Jenkins can build Azure Repos code through its Git and Azure DevOps plugins, so the repository can stay where it is while the pipeline moves, but the team then operates two systems and must keep webhooks, branch policies and build status checks working across both.
- Repository hosting stays separate: Build triggers, status reporting and branch protection must be wired from Azure Repos into Jenkins, and each of these needs an owner.
- Pull request checks are rebuilt: Azure Pipelines validation builds tied to branch policies have to be recreated as Jenkins jobs or multibranch pipelines that report back to Azure Repos.
- Credentials cross two systems: Personal access tokens or service principals used by Jenkins to read repositories must be created, scoped and rotated in Azure DevOps.
- Full forge migration is a separate decision: Moving repositories to a self-hosted forge such as GitLab is a larger project with its own sequencing, so decide it before building Jenkins integrations that would have to be redone.
Before committing, confirm with the Jenkins Azure DevOps plugin documentation which Azure Repos features your branch policies depend on.
Teams already hosting code on GitHub or GitLab usually have the smaller scope, because Jenkins integrates with those forges through established plugins and the repositories stay in place. Some Azure Pipelines projects in these organizations may only use Azure Pipelines because it was the default, so the first task is to confirm which pipelines still run and which are idle.
- Triggers are the main change: Webhook or multibranch discovery configuration replaces Azure Pipelines branch filters, and each repository needs a tested trigger.
- Status checks move with the pipeline: Commit status reporting to GitHub or GitLab must be configured in Jenkins so that protected branches still require a passing build.
- Consolidation may be possible: If the organization already runs GitHub Actions or GitLab CI/CD, some pipelines may be better moved to that tool. This is a decision to make with the owners of each repository.
- Fewer identity changes: Access to the forge is already governed, so the work concentrates on service accounts for Jenkins.
Check which forge plugins your Jenkins version bundles, since bundled plugin sets have changed between LTS releases.
Linux container builds are the most direct case for Jenkins on Kubernetes. Each build can run in a pod with the required tools as containers, which mirrors how many Azure Pipelines jobs already run on Linux images. The migration here is mostly a matter of translating stages and steps and of choosing pod templates that match the old agent images.
- Pod templates replace agent images: Each Azure Pipelines pool or container job becomes a Kubernetes pod template in the Jenkins configuration, with the same base images where licensing allows.
- Build caches need a plan: Dependency caches and Docker layer caches on Microsoft-hosted agents do not carry over, so teams should decide where caches live in their cluster.
- Registry access moves too: Image pull secrets and push credentials must be added as Jenkins credentials and scoped to the pods that need them.
- Pipeline size is manageable: Stage-by-stage translation fits well when most steps are shell commands and container builds.
Ask the platform team to confirm cluster capacity and network policy for build pods before the first pipeline is translated.
Windows-heavy builds are where the migration needs the most planning. Azure Pipelines offers Windows-hosted agents and task libraries for .NET and Microsoft tooling that have no direct equivalent in Jenkins. Teams building desktop software, MSBuild projects with signing steps, or installers may need Windows build agents that Jenkins connects to, and those agents are infrastructure the team must provision, patch and secure.
- Windows agents are self-operated: Jenkins does not provide hosted Windows agents, so the organization must build, license and maintain the machines or images used for builds.
- Tasks become scripts or plugins: Azure Pipelines tasks such as NuGet, MSBuild or code signing steps must be rewritten as command steps or matched to Jenkins plugins, and each match should be tested.
- Code signing needs a secure path: Signing certificates and hardware tokens need access controls in Jenkins that match the existing policy.
- Test before scoping: A pilot pipeline that builds, signs and publishes one application shows the real effort before the whole portfolio is estimated.
Ask the vendor or your Windows engineering team to list every Azure Pipelines task used in these pipelines, then check each against the Jenkins plugin index.
Organizations with many projects that share YAML templates face a different problem: the logic lives in a few central files, and one change can affect dozens of pipelines. Migrating those shared templates to Jenkins shared libraries is the step that determines how much of the rest of the portfolio can be converted in bulk, so it should be done before individual projects are moved.
- Templates become shared libraries: Reusable stages and steps become functions in a Jenkins shared library, versioned in source control and pinned by each Jenkinsfile.
- Pin versions deliberately: Teams should decide whether projects follow the library's main branch or pin tagged versions, since unpinned changes can break many builds at once.
- Parameterize early: Template parameters that vary by project must be mapped to explicit library arguments, which often reveals inconsistent use across teams.
- Plan a staged rollout: Move a few representative projects first, then the rest in groups, keeping the old pipelines available until each group passes.
Confirm with the owners of the shared templates which projects depend on each template before deciding the order.
The presence of classic release pipelines changes the deployment half of the migration. Classic release definitions, task groups and deployment groups are configured in the Azure DevOps interface rather than in source control, so they need to be exported and rebuilt as Jenkins deployment stages. Teams with YAML-only pipelines have the simpler path, since their definitions already sit in the repository and can be translated directly.
- Classic releases need mapping work: Each release stage, approval and environment must be reviewed and recreated, and approvals may need to move to Jenkins input steps or to a separate tool.
- Deployment targets decide the tool: Kubernetes targets may be better served by Argo CD, which is a separate decision from the Jenkins migration.
- YAML-only projects move faster: Repository-stored definitions reduce the export work, although secrets and service connections still need to be recreated.
- Secrets are re-entered: Values of Azure Pipelines secret variables and service connections cannot be read back, so each one must be re-created in Jenkins credentials by its owner.
Before planning, export the classic release definitions and count how many stages, approvals and environments they contain.
What do teams ask before migrating from Azure Pipelines to Jenkins?
How much does a migration from Azure Pipelines to Jenkins cost?
The cost depends on the size and shape of your pipeline estate, and no single figure applies to every team. The main drivers are the number of pipelines and templates to convert, how many classic release pipelines and service connections need rebuilding, how many Jenkins plugins your pipelines depend on, and how much build infrastructure you run. Costs fall into one-time work (assessment, conversion, secret re-creation, testing and cutover) and recurring work (controller and agent infrastructure, plugin upgrades, backups and on-call support). Ask any provider for a written scope that lists each pipeline, the deployment targets, the agent types and the handover documents, so the quote maps to work you can check. DeployOpen provides fixed-scope engagements agreed in writing before work starts, and the quote follows from that scope.
How long does it take to move pipelines from Azure Pipelines to Jenkins?
The timeline depends on how many pipelines run in parallel, how complex their templates are and how much of the estate can be converted in batches. Teams usually run both systems side by side for a period, moving low-risk repositories first and production deployments last. Before estimating, confirm which pipelines are YAML and which are classic release definitions, because classic releases need a redesign into Jenkins deployment stages rather than a direct copy. A written scope should set the milestones, the cutover order and the acceptance tests for each batch.
What does the internal team need to provide during the migration?
The internal team supplies the knowledge of how the pipelines are used and who depends on them, which an outside team cannot infer from the repositories alone. Expect to name owners for each pipeline, provide access to the Azure DevOps organization and the repositories, approve the target architecture and sign off each cutover. Platform engineers also need to agree on the Jenkins controller and agent design, backup targets for $JENKINS_HOME, and who will run upgrades afterward. Confirm these commitments in the scope, because delays usually come from unclear ownership rather than from conversion work.
Can our own team migrate from Azure Pipelines to Jenkins without outside help?
Yes, a team with Jenkins and Azure DevOps experience can do the migration in-house, and many do. The questions to answer honestly are whether the team has run Jenkins in production, can maintain plugins and Kubernetes agents, and has capacity alongside its normal delivery work. A partial approach also works, where internal staff handle simple pipelines and an outside team handles the release redesign, secret handling or security hardening. Whichever path you choose, document the decision and the runbooks, since the knowledge needs to outlast the migration.
Can Jenkins run Windows and .NET builds that Azure Pipelines handles today?
Jenkins can run builds on Windows, but it needs Windows build agents that you provision and maintain, while Azure Pipelines offers Microsoft-hosted Windows agents. Confirm the exact toolchains, such as .NET SDK versions, MSBuild, Visual Studio components and code signing tools, and test each one on a Windows agent before cutover. Some Azure Pipelines tasks have no direct Jenkins equivalent, so the conversion may use plugins or scripts instead. Plugin compatibility is also a point to verify against the Jenkins plugin list for your controller version.
How are secrets, service connections and variable groups handled during the move?
Secrets cannot be exported from Azure Pipelines in readable form, so each secret, service connection credential and variable group value must be re-created in Jenkins credentials or an external secrets store. Plan for a rotation step as well, because the values are often reused across systems and rotation limits the impact if an old value was exposed. Keep an inventory of every secret, its owner and the pipelines that use it, and verify each one in a non-production run before cutover. Hosted CI services hold deployment secrets for every connected project, which is one reason many teams want these values under their own control.
Does Azure Repos have to move when we switch CI to Jenkins?
No, Jenkins does not require you to move repositories. Jenkins can read source from Git repositories it can reach, including Azure Repos, so the source stays where it is while the build engine changes. You need to confirm that the Jenkins controller and agents can authenticate to Azure Repos, that webhooks or polling are configured, and that the Jenkinsfile conventions suit your branching model. Moving repositories is a separate decision, with its own scope, and should not be bundled into the CI migration unless you have chosen to do so.
What happens to build history and artifacts when we leave Azure Pipelines?
Export run history, logs and artifacts before you decommission Azure Pipelines, because the move to Jenkins does not carry them over. Keep a retention plan for logs needed by auditors or incident reviews, and confirm where exported artifacts will be stored. YAML definitions already live in your repositories, so they are the easiest part to keep. Classic pipeline definitions can be retrieved through the REST API before shutdown. Agree on the exported formats and retention periods in the written scope.
How DeployOpen scopes and runs a Jenkins migration
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For a move from Azure Pipelines to Jenkins, we start with a written scope that maps your existing pipelines, credentials and agents, then build and test the Jenkins side in your environment before any cutover.
How we scope
- We inventory existing YAML pipelines, classic release pipelines, variable groups and service connections before agreeing any deliverables.
- The written scope names which pipelines move to Jenkinsfiles, which deployment targets get Jenkins stages, and what is retired.
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we build
- We convert pipelines to Jenkinsfiles and shared libraries, then rebuild secrets as Jenkins credentials rather than copying values.
- We set up Kubernetes pod agents or dedicated build agents in your cloud account or data center, following the scope agreed.
- We run each converted pipeline side by side with the Azure Pipelines original and record differences in build output and artifacts.
How we hand over
- You receive documentation of the controller configuration, plugin list, credential inventory and agent setup used in your environment.
- We document how to back up the Jenkins home directory, which holds configuration, plugins and secrets, and test a restore.
- Handover covers runbooks for each migrated pipeline, plus a record of which Azure Pipelines artifacts and logs were exported.
How we support
- Ongoing support, plugin and Jenkins upgrades, and continuous testing are available as a retainer after handover.
- Retainers can cover LTS upgrades, Java runtime changes and removal of plugins that are no longer bundled with Jenkins.
- Ask us to confirm the support scope, response expectations and upgrade cadence in writing as part of your quote.
