CI/CD for complex legacy systems

Implementing CI/CD for complex legacy systems with modern DevOps

The most effective way to modernize CI/CD for legacy systems is to automate around the existing system first, then modernize incrementally. You don't need to rewrite a mainframe application, a monolithic Java service, a .NET Framework application, or a tightly coupled enterprise platform before you can benefit from DevOps.

The goal is to build a reliable delivery pipeline that improves testing, deployment safety, traceability, and release frequency without destabilizing critical business operations.

1. Start with a modernization strategy

Phase 1 — Stabilize and understand

(Assess)

Inventory applications, dependencies, build processes, environments, deployment scripts, and manual approval steps. Identify which systems are business-critical and which changes carry the greatest risk.

Phase 2 — Automate the existing lifecycle

(Automate)

Put source code in version control, make builds repeatable, automate available tests, version deployment artifacts, and establish a controlled release process.

Phase 3 — Modernize selectively

(Improve)

Add containers, infrastructure as code, API-based integration, automated security checks, and service decomposition where they provide measurable value.

Important: A legacy application does not have to run in Kubernetes to benefit from CI/CD. It can use a modern pipeline while continuing to run on a virtual machine, application server, mainframe, or physical server.

2. Design a pipeline that fits legacy constraints

A practical reference architecture looks like this:

1. Source control

Git · Pull requests · Code review

2. Continuous integration

Compile · Lint · Unit tests · Dependency checks

3. Immutable artifact

Versioned package · Checksum · Provenance

4. Validation environment

Integration · Regression · Database compatibility · Security

5. Controlled deployment

Approval gates · Backups · Health checks · Rollback

6. Production monitoring

Logs · Metrics · Alerts · Release verification

The key design rule is to build once and promote the same tested artifact through environments, rather than rebuilding separately for testing and production. Keep environment-specific configuration outside the artifact and version the deployment scripts. This supports reproducibility and safer releases.dora.dev+1

What changes for legacy systems?

For highly coupled applications, begin with a modular pipeline: one pipeline can build the whole application, while tests and deployment stages target the components or release units that can safely be separated.

3. Choose tools based on your environment

You don't need every tool in this table. Prefer a small, integrated toolchain that your team can operate and maintain.

Need	Suitable tools	Best fit
CI/CD orchestration	Jenkins; GitHub Actions; Azure Pipelines; GitLab CI/CD	Existing ecosystem, runner requirements, governance
Build automation	Maven, Gradle, MSBuild, Make, vendor-specific build tools	Language and compiler compatibility
Artifact management	JFrog Artifactory; Sonatype Nexus Repository	Versioned binaries, packages, dependencies
Infrastructure as code	Terraform; Ansible; native cloud templates	Repeatable infrastructure and configuration
Testing	JUnit, NUnit, pytest, Selenium, contract-test frameworks	Application stack and available test seams
Observability	Prometheus; Grafana; OpenTelemetry	Metrics, dashboards, traces, operational visibility

My default recommendation:

• If you already operate Jenkins successfully, retain it initially and improve the pipeline rather than combining a CI/CD migration with an application modernization project.
• If you're Microsoft-centric, especially with .NET and Windows build agents, evaluate Azure Pipelines or GitHub Actions with self-hosted Windows runners.
• If your code is already in GitLab, evaluate GitLab CI/CD before adding another orchestration platform.
• If your systems run on mainframes or proprietary platforms, preserve the required native build and deployment tools and integrate them with the central pipeline through controlled agents, scripts, APIs, or vendor-supported integrations.

Microsoft documents repeatable infrastructure deployments using GitHub Actions and infrastructure as code, while DORA's guidance emphasizes repeatable builds, automated testing, and deployment automation.learn.microsoft.com+2

4. Build your first working pipeline in 30–90 days

Treat this as an illustrative rollout plan; the actual timeline depends on system complexity, test availability, and deployment constraints.

Weeks 1–2: Establish a baseline

• Document the current build and release process.
• Identify a low-risk application or component as a pilot.
• Put build scripts, deployment scripts, and configuration templates under version control.
• Record current release frequency, lead time, and failure rate.

Weeks 3–4: Establish CI

• Trigger a build on every pull request.
• Automate compilation, static analysis, and a small set of reliable regression tests.
• Publish versioned artifacts and build logs.
• Make failures visible and assign ownership for fixing them.

Weeks 5–8: Add CD

• Automate deployment to a nonproduction environment.
• Add integration tests, smoke tests, and database validation.
• Introduce approvals, access controls, and rollback procedures.
• Perform a production deployment with an operator supervising the process.

Weeks 9–12: Expand and optimize

• Add security scanning and infrastructure automation.
• Reduce manual release steps and test bottlenecks.
• Document recovery procedures and operational ownership.
• Extend the proven pipeline to the next application.

This incremental approach is consistent with DORA's recommendations to start with a small deployment pipeline, build up automated testing, and improve deployment reliability over time.dora.dev+2

5. Example: a CI workflow for a legacy application

The following GitHub Actions example illustrates the structure. It assumes the repository contains a compatible .NET application and that the required SDK is available on the runner. Replace the commands with your actual build and test commands.

name: Legacy Application CI

on:
  pull_request:
  push:
    branches: [main]

permissions:
  contents: read

jobs:
  build-and-test:
    runs-on: windows-latest

    steps:
      - name: Checkout source
        uses: actions/checkout@v4

      - name: Set up .NET SDK
        uses: actions/setup-dotnet@v4
        with:
          dotnet-version: '8.0.x'

      - name: Restore dependencies
        run: dotnet restore LegacyApp.sln

      - name: Build
        run: dotnet build LegacyApp.sln --configuration Release --no-restore

      - name: Run tests
        run: dotnet test LegacyApp.sln --configuration Release --no-build

      - name: Publish deployable artifact
        run: dotnet publish src/LegacyApp/LegacyApp.csproj --configuration Release --output ./publish

      - name: Upload artifact
        uses: actions/upload-artifact@v4
        with:
          name: legacy-app-${{ github.sha }}
          path: ./publish/

This is a starting template, not a production-ready deployment workflow. Check that your legacy application's target framework, SDK, dependencies, and runner operating system are compatible. For older .NET Framework applications, for example, you may need a suitably configured Windows runner and a compatible build toolchain.

To extend this to CD:

1. Publish the package to a controlled artifact repository.
2. Download that exact package in a separate deployment workflow.
3. Deploy to staging and run smoke and integration tests.
4. Require the appropriate production approval.
5. Deploy with health checks and a documented recovery procedure.

For applications requiring access to private networks, licensed compilers, or proprietary tooling, self-hosted runners may be appropriate. Restrict their access to trusted workflows and sensitive environments, and isolate or reset them between jobs where possible.docs.github.com+1

6. Protect against the biggest risks

Legacy CI/CD succeeds when operational risk is explicitly designed into the pipeline.

• Insufficient test coverage: Start with critical business transactions and expected outputs. Increase coverage incrementally rather than waiting for perfect coverage.
• Database incompatibility: Use backward-compatible, staged schema changes where possible. Verify backup and restoration procedures.
• Secrets exposure: Use a secrets manager or protected pipeline secrets; separate build permissions from production deployment permissions.
• Uncontrolled deployments: Restrict production credentials, require approvals where warranted, and log every release.
• Unreliable rollback: Maintain known-good artifacts and rehearse recovery. Database changes and irreversible data transformations may require forward fixes or restoration rather than a simple binary rollback.
• Overengineering: Avoid introducing Kubernetes, microservices, or a new CI platform unless there is a concrete business or operational benefit.

Track deployment frequency, change lead time, change failure rate, and time to restore service. Pair those measures with build success, test reliability, and release duration so that faster delivery doesn't come at the expense of stability.dora.dev+2

7. Let's tailor the implementation to your systems

The right architecture depends heavily on your technology stack and hosting model. Tell me what your legacy environment looks like, and I can recommend a concrete toolchain, pipeline architecture, and implementation plan.

What technologies are you using?

Mainframe / COBOL

.NET Framework / Windows

Java monolith / application server

Mixed enterprise applications

Other (SAP, C/C++, older platforms, etc.)

Where do the applications run?

On-premises data center

Cloud

Hybrid environment

What CI/CD tooling do you have today?

Jenkins

Azure DevOps

GitHub Actions

GitLab CI/CD

Manual releases / no established pipeline

Other / multiple tools

What's your main goal?

Automate testing and releases

Modernize application architecture

Improve security and compliance

Reduce deployment risk and downtime

What's the biggest constraint? (Optional)

Limited automated tests

Complex database dependencies

Restricted network or proprietary tooling

Strict audit or change-control requirements

Poorly documented build process

[Build my CI/CD implementation plan]

For complex legacy systems, I would not pick a CI/CD platform purely on how modern its UI looks. The key capability is the ability to run self-hosted agents/runners with old toolchains, custom scripts, Windows/Linux infrastructure, on-prem dependencies, and controlled deployment stages.

My shortlist

Tool	Best fit for legacy	Why I’d consider it
Jenkins	⭐⭐⭐⭐⭐	Maximum flexibility and enormous plugin/integration ecosystem
Azure DevOps Pipelines	⭐⭐⭐⭐⭐	Excellent for Microsoft/.NET/Windows-heavy estates
GitLab CI/CD	⭐⭐⭐⭐½	Strong all-in-one platform with self-managed runners
Octopus Deploy + any CI tool	⭐⭐⭐⭐⭐ for CD	Particularly strong when deployment complexity is the problem
GitHub Actions	⭐⭐⭐⭐	Great if your source is already on GitHub, with self-hosted runners
Harness	⭐⭐⭐⭐	Strong enterprise release orchestration/governance, but potentially more platform than you need

1. Jenkins — best when the legacy environment is really weird

Jenkins remains one of my top choices when you have things like:

• ancient compilers/SDKs
• proprietary build tools
• mixed Windows and Linux servers
• shell/PowerShell/Ant/Maven/MSBuild/custom scripts
• unusual deployment procedures
• hardware or software that can't easily be containerized
• dozens of existing integrations

Jenkins Pipeline lets you express complex workflows as code, including parallel stages, loops, forks/joins, manual approvals and custom extensions.www.jenkins.io

The downside is operational overhead: you own the Jenkins platform, plugins, upgrades, agents, credentials, and security model. For a new greenfield system I'd often choose something simpler; for a 20-year-old enterprise estate, Jenkins's flexibility can be a feature rather than a liability.

Jenkins Pipeline documentation

2. Azure DevOps — particularly good for Windows/.NET legacy

If your estate contains .NET Framework, Visual Studio, MSBuild, IIS, Windows Services, SQL Server, PowerShell, or Azure, I'd put Azure Pipelines very high on the list.

The important feature is self-hosted agents. You can install them on your own Windows/Linux infrastructure and give them precisely the SDKs, compilers and dependencies that your legacy applications require. Microsoft explicitly notes that self-hosted agents provide control over dependent software and can retain machine-level caches/configuration between runs.github.com

That makes a pattern like this practical:

Git
 │
 ▼
Azure Pipeline
 │
 ├── Legacy Windows build agent
 │      ├── .NET Framework 4.x
 │      ├── MSBuild
 │      ├── proprietary SDK
 │      └── integration tests
 │
 ├── Linux build agent
 │      └── legacy Unix components
 │
 └── Deployment
        ├── IIS
        ├── Windows Services
        └── on-prem servers

If you're running Azure DevOps Server on-premises, self-hosted agents are required; Microsoft-hosted agents aren't available there.learn.microsoft.com

Azure Pipelines documentation

3. GitLab CI/CD — best modern all-rounder

GitLab is especially attractive if you're willing to standardize repositories, CI/CD, security and artifact management around one platform.

Its self-managed runners are useful for legacy estates because they can run inside your private network and can use Shell, Docker or Kubernetes executors.github.com+2

That means you can have dedicated runners such as:

legacy-windows
legacy-linux
mainframe-build
oracle-integration
docker-modern

and route jobs to the appropriate environment using runner tags.

One caution: self-managed runners are powerful execution environments, so security isolation matters. GitLab explicitly warns about the risk of non-ephemeral runners being shared across projects.docs.gitlab.com

GitLab CI/CD documentation

4. Octopus Deploy — my favorite addition when CD is the hard part

This is the one I'd seriously consider alongside, rather than necessarily instead of, Jenkins/GitLab/Azure DevOps.

Octopus Deploy specializes in deployment/release orchestration. It supports Windows/Linux servers, on-prem machines, Kubernetes and cloud targets, with environments, approvals, deployment ordering, variables, runbooks and progressive deployment patterns.octopus.com

It's particularly compelling for old Windows estates. Octopus has first-class deployment steps for Windows Services and IIS, including handling service lifecycle and IIS application pools.octopus.com

For example:

Jenkins / GitLab / Azure DevOps
             │
             │ build + test
             ▼
        Versioned artifact
             │
             ▼
       Octopus Deploy
             │
       ┌─────┼─────┐
       ▼     ▼     ▼
      DEV   QA    PROD
                   │
             approval gate
                   │
          ┌────────┴────────┐
          ▼                 ▼
       IIS servers      Windows Services

That separation is valuable: CI builds an immutable artifact; CD figures out how to safely get that artifact through your bizarre production environment.

5. GitHub Actions

If your organization is already standardized on GitHub, GitHub Actions is worth considering.

The important legacy-system feature is again self-hosted runners: you control their hardware, OS and installed software.docs.github.com

I'd choose it over Jenkins when:

• source is already predominantly GitHub
• you want minimal CI infrastructure
• most builds can run on standardized runners
• your legacy requirements aren't exceptionally unusual

I'd lean Jenkins/Azure DevOps/GitLab when the legacy environment is highly heterogeneous.

What I'd actually recommend

For a large, messy legacy estate, my preferred architectures would be:

Microsoft-heavy estate

Azure DevOps Pipelines + self-hosted Windows agents + Octopus Deploy

This is probably my #1 choice if you have lots of IIS, .NET Framework, Windows Services and SQL Server.

Heterogeneous enterprise estate

GitLab CI/CD + self-managed runners + Octopus Deploy

Good balance between modern DevOps practices and the ability to accommodate weird infrastructure.

Extremely heterogeneous / lots of existing automation

Jenkins + self-hosted agents + Octopus Deploy

Jenkins gives you the escape hatch when some 15-year-old build system requires a bizarre combination of environment variables, proprietary tools and PowerShell.

Already deeply invested in GitHub

GitHub Actions + self-hosted runners + Octopus Deploy

Avoid introducing another CI platform unless there's a real reason.

One important architectural principle

I wouldn't start by trying to modernize the legacy applications themselves.

Instead, modernize the delivery mechanism around them:

Phase 1: Put existing builds under source control and automate them.

Phase 2: Create reproducible build agents with pinned toolchains.

Phase 3: Produce versioned artifacts.

Phase 4: Automate deployment to dev/test.

Phase 5: Add integration/regression testing.

Phase 6: Add approvals, production deployment and rollback.

Phase 7: Gradually replace individual legacy components with modern ones.

That lets you get CI/CD benefits without making “rewrite the legacy system” a prerequisite.

If you tell me whether your legacy estate is primarily Windows/.NET, Java, mainframe, C/C++, or a mixed environment, I can narrow this down to a concrete toolchain and show you what the pipeline architecture should look like.

Yes. Highly complex legacy systems need a different CI/CD strategy from modern applications built from scratch. The most effective approach is usually to introduce automation incrementally, establish confidence in existing behavior, and reduce deployment risk before attempting major architectural changes.

The key is that you don't need to modernize the entire system before adopting DevOps. You can build a reliable delivery pipeline around the system as it exists today, then improve it in stages. This aligns with guidance from DORA on continuous integration and from Martin Fowler on deployment pipelines.dora.dev+3

1. The most effective strategies

1. Start with a baseline pipeline, not a full rewrite

Automate the existing build, dependency resolution, packaging, and deployment process first. Reproduce the current production environment as closely as practical, including runtime versions, configuration, and external dependencies.

Why it works: It reduces manual errors and creates repeatability without requiring risky architectural changes upfront. Containerization or virtual machines can help where compatible with the legacy platform.cloud.google.com+3

2. Build a safety net with characterization tests

Legacy systems often have undocumented behavior and hidden dependencies. Before changing code, write tests that capture what the system actually does today, including unusual business rules and edge cases.

Prioritize:

• Critical end-to-end business workflows.
• Regression tests around frequently changed modules.
• API and database contract tests.
• Tests for high-risk calculations and integrations.

Why it works: You gain evidence that changes preserve existing behavior, even when the original design or documentation is incomplete.www.martinfowler.com+3

3. Use a staged deployment pipeline

Don't run every expensive test on every commit. Organize the pipeline into stages that provide progressively stronger confidence.

• Stage 1: Compile, lint, scan, and run fast unit tests.
• Stage 2: Run regression and integration tests.
• Stage 3: Test compatibility, performance, security, and database changes.
• Stage 4: Deploy to staging and perform smoke or acceptance tests.
• Stage 5: Release to production with appropriate approval and monitoring.

Why it works: Developers receive fast feedback, while more expensive tests still protect production.www.martinfowler.com+2

4. Decouple components gradually

Avoid breaking a large monolith into microservices simply to make CI/CD easier. Instead, identify boundaries where components can be isolated, tested, and released more independently.

Useful techniques include:

• Strangler pattern: Gradually replace parts of the legacy application with new implementations.
• Branch by abstraction: Introduce an interface around a difficult-to-replace component, then switch implementations incrementally.
• Contract testing: Verify that dependent systems continue to communicate correctly.

Why it works: It limits the blast radius of changes and creates opportunities for independent delivery.dora.dev+4

5. Make releases reversible

Complex legacy applications may have tightly coupled databases, shared infrastructure, and stateful integrations. A code rollback alone may not restore a working system.

Use feature flags where feasible, canary or phased releases where supported, backward-compatible database changes, health checks, and documented recovery procedures. Monitor errors and business outcomes after each release.

Why it works: Failures become easier to detect, contain, and recover from.www.martinfowler.com+2

2. Adapt the strategy to the type of legacy system

Not every legacy architecture needs the same CI/CD solution.

These are practical applications of the staged delivery and modernization principles described by Martin Fowler and Google Cloud.www.martinfowler.com+2

3. A practical implementation roadmap

For a highly complex enterprise system, I'd recommend the following sequence.

Phase 1 — Assess and stabilize

Weeks 1–4 · Illustrative timeline

• Map dependencies, build steps, release procedures, and production risks.
• Identify the most business-critical workflows.
• Establish a reproducible build and capture baseline delivery metrics.

Phase 2 — Establish automated testing

Weeks 3–8

• Add characterization tests for the most critical workflows.
• Automate build, unit, and selected integration tests.
• Make failures visible and establish a policy for fixing broken builds.

Phase 3 — Automate delivery

Weeks 6–12

• Create versioned, immutable build artifacts.
• Automate staging deployments and smoke tests.
• Introduce approval gates, rollback procedures, and release monitoring.

Phase 4 — Optimize incrementally

Ongoing

• Reduce test execution time and flaky failures.
• Decouple high-change, high-risk modules.
• Expand automated deployment and rollout strategies as confidence grows.

The timeline is illustrative rather than a guarantee. A heavily regulated mainframe environment or a system with scarce test environments could require substantially longer.

4. How to measure whether it's working

Use a small set of metrics to guide improvement rather than measuring success by how many pipeline steps have been automated.

The first four align with the commonly used DORA software delivery performance measures. Interpret them in context: for a mainframe or tightly regulated system, safe and repeatable delivery may be a more appropriate initial objective than frequent production deployments.

5. Common mistakes to avoid

• Rewriting everything before automating anything. This delays benefits and adds migration risk.
• Making every test mandatory on every commit. Slow feedback encourages developers to bypass the pipeline.
• Treating a successful build as proof of production readiness. Integration, data compatibility, operational behavior, and recovery still matter.
• Automating a fragile manual process without simplifying it. First document and standardize the process.
• Introducing microservices too early. Distributed systems introduce additional networking, deployment, observability, and data consistency challenges.
• Automating production releases without a recovery strategy. Delivery speed without adequate safeguards can amplify incidents.

DORA's guidance emphasizes short feedback loops, reliable automated tests, and frequent integration, while deployment-pipeline practices support progressively stronger verification before release.dora.dev+2

My recommendation

For a highly complex legacy system, I'd prioritize repeatable builds → characterization tests → staged CI/CD → reversible releases → gradual architectural decoupling.

That sequence gives you measurable improvements without requiring a risky, all-at-once modernization.

To make this more specific to your environment: what kind of legacy system are you working with?

1. Technology platform

Mainframe / COBOL

.NET / Java enterprise application

Database-centric system

Mixed technologies / other

2. Architecture

Large monolith

Tightly coupled distributed systems

Multiple interconnected legacy applications

3. Biggest current obstacle

Testing and regression risk

Build and deployment automation

Database and dependency coupling

Release approvals and compliance

[Tailor the CI/CD strategy]

Implementing Continuous Integration and Continuous Delivery (CI/CD) for complex, highly coupled legacy systems requires an evolutionary approach rather than a disruptive "big bang" rewrite . Because legacy environments often suffer from tight coupling, fragile dependencies, and a lack of automated testing, DevOps strategies must focus on risk mitigation, incremental feedback, and building a "trust layer".cisin.com+2

Key DevOps strategies for complex legacy systems include:

1. Establish a Single Source of Truth (Version Control)
   • Migrate all legacy artifacts, configurations, infrastructure scripts, and source code (even older languages like COBOL or proprietary formats) into a modern version control system like Git.
   • Implement a "thin slice" build—the simplest possible automated compilation that verifies the legacy code builds successfully in an automated fashion.harness.io+1
2. Build a Trust Layer with Characterization Tests
   • Legacy systems are often undocumented, meaning "correct" behavior is simply "what it currently does."
   • Write characterization tests (or approval tests) to capture existing, real-world behaviors and inputs/outputs before refactoring or touching the code. This ensures your CI pipeline catches regressions immediately.cisin.com
3. Adopt the Strangler Fig Pattern & API Wrappers
   • Avoid trying to pipeline the entire monolith at once. Instead, wrap legacy functional blocks with modern APIs or place an API Gateway in front of the system.
   • Carve out specific capabilities into new microservices, routing traffic via the gateway. This lets you build modern, lightning-fast CI/CD pipelines for new components while the legacy core remains stable.medium.com+1
4. Implement Decoupling via Event Queues
   • Break synchronous, tightly-coupled dependencies inside or around the legacy system by introducing message queues or event brokers (e.g., Kafka, RabbitMQ). This isolates components so they can eventually be tested and deployed independently.medium.com
5. Manage Shared Databases with "Expand and Contract" Patterns
   • Legacy monoliths frequently rely on a single, massive shared database.
   • Implement zero-downtime database migration strategies by avoiding destructive schema changes (like dropping columns outright). Use the expand-and-contract pattern alongside feature flags to keep schema modifications backward-compatible.circleci.com
6. Introduce Environment Parity via Infrastructure as Code (IaC)
   • Spin up reproducible, containerized or virtualized environments that closely mimic production for testing. Even if the legacy application runs on specialized or older infrastructure, automating environment provisioning eliminates "it works on my machine" deployment failures.entrans.ai+1

If you'd like to dive deeper, let me know:

• What technology stack or language your legacy system uses (e.g., Java, .NET, mainframe/COBOL)
• The biggest bottleneck you face right now (slow builds, manual testing, or deployment fear)

I can give you a tailored roadmap for your specific architecture.