CI/CD Pipeline Recovery

Define the evidence needed before making a legacy decision

When a business takes over a legacy web application, one of the first operational questions is: how does code actually get from a developer's machine to the live system? The mechanism that automates that journey is the CI/CD pipeline — Continuous Integration and Continuous Deployment (or Delivery). In a well-maintained system, every code change triggers automated builds, tests and deployments. In a legacy takeover, that pipeline is often broken, undocumented, tied to the previous supplier's accounts, or simply absent.

CI/CD pipeline recovery means finding out what automation exists, determining whether it still works, gaining control of it, and either repairing it or building a replacement that lets your team deploy changes safely. Without a functioning pipeline, every update becomes a manual process carried out by someone who must remember undocumented steps — a significant operational risk for any business-critical system.

The pipeline itself is not the source code. You might have full access to the repository but no ability to run the build or deploy to staging and production environments. Conversely, you might find a working pipeline but no understanding of what it does, what it tests, or where it deploys to. Both situations need resolution before you can make changes to the application with any confidence.

Why the pipeline matters more during a takeover

During normal development, a team evolves its pipeline incrementally. During a takeover, you inherit the end result without the context. A pipeline that appears to run successfully might be skipping tests, deploying to the wrong environment, or relying on credentials that will expire. The recovery process is not just about getting something to run — it is about verifying that what runs is trustworthy.

Establishing what exists

The first step is to identify the pipeline tooling. Common platforms include Jenkins, GitLab CI, GitHub Actions, Bitbucket Pipelines, CircleCI and Azure DevOps. The configuration is usually stored in the repository itself (as a file such as .gitlab-ci.yml or Jenkinsfile) or within the platform's own interface. Check both places.

If the pipeline is configured inside the platform rather than in code, and you do not have administrative access to that platform, you have a gap that needs addressing before recovery can begin. This is an access problem, not a technical one, and it should be raised early in the takeover process.

Mapping the pipeline stages

Once you can see the configuration, map out what actually happens at each stage:

• Build: Does it compile code, install dependencies and produce an artefact (such as a Docker image or a deployable package)?
• Test: Does it run automated tests? What type — unit tests, integration tests, end-to-end tests? Are any test stages commented out or skipped?
• Staging deployment: Is there an intermediate environment that mirrors production?
• Production deployment: How does the release reach live users? Is it automatic or does it require manual approval?
• Post-deployment checks: Does the pipeline verify that the application is actually healthy after deployment, or does it assume success?

Document each stage with the inputs, outputs and any external services it depends on. This document becomes the baseline for deciding what to repair and what to replace.

Checking environment and secret configuration

Pipelines rely on environment variables and secrets — database credentials, API keys, deployment tokens and encryption keys. These are typically stored in the pipeline platform's secret management, not in the code. During a takeover, you need to confirm two things: that the secrets are accessible to your team, and that they are still valid. Expired credentials will cause the pipeline to fail in ways that look like technical problems but are actually access problems.

Be aware that some secrets may be shared with other systems. Rotating a database password used by the pipeline, for example, may also require updating the application's runtime configuration. Treat secret rotation as a coordinated activity, not an isolated pipeline task.

Deciding between repair and replacement

Not every legacy pipeline is worth recovering. The practical decision rests on a few factors:

• Comprehensibility: Can someone on your team understand what the pipeline does without the original author? If the configuration is convoluted or poorly structured, replacement may be faster than reverse-engineering.
• Platform lock-in: If the pipeline lives on a platform you do not intend to keep using, migrating to your preferred tooling sooner avoids accumulated technical debt.
• Test coverage: A pipeline that only builds and deploys without testing provides limited value. Building a replacement that includes proper test stages may be more useful than fixing a minimal pipeline.
• Urgency: If you need to make a critical change to the application quickly, the fastest path may be a documented manual process while a proper pipeline is built in parallel.

When manual deployment is the interim answer

There is no rule that says you must have a fully automated pipeline from day one of a takeover. A clearly written, step-by-step manual deployment guide — tested by someone who did not write it — is a perfectly acceptable interim measure. The risk comes from undocumented manual processes, not from manual processes themselves. If you choose this route, set a clear timeframe for when the automated pipeline will be operational.

Assuming a green build means a safe deployment

A pipeline that passes all its stages is only as reliable as the checks within those stages. If the test suite has been neglected and most tests are skipped or always pass regardless of code changes, a green build provides false confidence. Review what the pipeline actually validates, not just whether it completes without errors.

Overlooking non-production environments

Some legacy systems deploy directly to production with no staging step. Others have a staging environment that has not been updated in months and no longer resembles production. During recovery, verify that each environment is correctly configured, that data in non-production environments is suitably anonymised or synthetic, and that the pipeline deploys to the correct targets.

Confusing pipeline access with server access

Having credentials to log into the production server does not mean you can deploy through the pipeline. These are separate access paths with separate credentials and permissions. A common mistake is assuming that server access makes the pipeline unnecessary, which leads to ad-hoc deployments that bypass any testing or approval steps the pipeline enforces.

Ignoring the build artefact

Understand what the pipeline produces and where it stores the result. If the pipeline builds a Docker image, where is that image pushed? If it produces a compiled package, where is that stored? If the artefact repository is on the previous supplier's infrastructure and you lose access to it, the pipeline becomes useless even if everything else is working. Ensure you control or have a clear migration path for the artefact storage.

Not testing the rollback path

Recovery is not complete until you have verified that you can revert a deployment. Check whether the pipeline supports rollback, how it selects the previous version, and whether that process has been tested. If the pipeline does not handle rollbacks, document how they should be performed manually and ensure the necessary previous artefacts are retained.

Key checks to carry out

• Can your team log into the pipeline platform with administrative access?
• Is the pipeline configuration stored in version control, or only in the platform's interface?
• Do all secrets and environment variables have valid, non-expired values?
• Does the test suite run to completion, and do the tests appear meaningful?
• Are staging and production environments correctly defined and distinct?
• Can you trace a deployment from code commit to live release and understand each step?
• Is the artefact storage under your control?
• Has a rollback been tested, or at minimum documented?
• Is there a manual deployment fallback that someone unfamiliar with the system could follow?

Limitations of pipeline recovery

Pipeline recovery cannot fix underlying application problems. If the codebase has no automated tests, the pipeline cannot create them — it can only run what exists. If the application's architecture makes deployment inherently risky (for example, a monolith where a small change requires redeploying the entire system), the pipeline can manage the process but cannot eliminate the architectural risk. Recovery addresses the deployment mechanism; it does not redesign the application.

Turn the assessment into a controlled next step

Security review of the pipeline itself is a separate concern. A recovered pipeline may have been configured with permissive settings, exposed secrets in logs, or lacked audit logging. Once the pipeline is operational, treat its security posture as a matter for specialist review rather than assuming the previous configuration was adequate.