How do organisations decide whether to import existing CI/CD resources before rebuilding them?

Importing versus rebuilding CI/CD: what the decision is really about

The choice is not simply technical. It is about whether the organisation can bring an existing delivery system under repeatable control without breaking production flow. Importing makes sense when the pipeline already has business value, known dependencies, and enough internal consistency to be represented safely as code. Rebuilding is a stronger option when the current estate is so fragmented, undocumented, or exception-heavy that modelling it would lock bad patterns into a new baseline.

For security and governance teams, the key question is whether the current state can be captured faithfully enough to improve oversight without creating a false sense of standardisation. That matters because CI/CD systems often contain credentials, deployment permissions, release automation, and service connections that affect both availability and trust. The OWASP Non-Human Identity Top 10 is relevant here because CI/CD resources frequently include machine identities and secrets that should be governed, not simply recreated by habit. In practice, many teams discover that the real problem is not the pipeline definition itself, but the undocumented access paths and inherited exceptions embedded in it.

How organisations judge whether import is safe enough

Import is usually the better first move when the existing CI/CD environment is already delivering software, because it preserves continuity while making the estate visible to governance. The organisation should ask whether the resource can be brought into a managed state without forcing a redesign of unrelated components. If the answer is yes, import allows policy, ownership, and review to move into code while the live system keeps running.

That judgement depends on three practical checks. First, the current resource must be sufficiently stable: names, relationships, and permissions should be discoverable rather than improvised. Second, the team must understand what the resource actually controls, especially where it touches build runners, deployment targets, secrets, or non-human identities. Third, the import process must not overwrite live behaviour with an incomplete template. A partial model is often worse than no model because it can hide exceptions behind a false baseline.

• If the pipeline is already supporting production releases, favour import unless there is evidence of severe drift or unsafe sprawl.
• If ownership, permissions, and dependencies are unclear, pause and inventory before importing.
• If the current setup contains one-off manual edits that cannot be represented cleanly, treat that as a sign the rebuild path may be cheaper in the long run.

Rebuilding becomes defensible when the existing pipeline is structurally inconsistent, duplicated across teams, or built from patterns that cannot be standardised without removing core functionality. In those cases, import may preserve technical debt instead of controlling it. The boundary is not whether the old system is imperfect, but whether its behaviour is explainable well enough to be made governable. Where that boundary is crossed, import stops being a control exercise and becomes an archival one.

The OWASP Non-Human Identity Top 10 also helps frame the choice because CI/CD often depends on machine-to-machine trust that is easy to inherit but hard to reconstruct safely. If the organisation cannot trace which automation identity can deploy, sign, or fetch secrets, rebuilding may be the only way to re-establish a clean trust model. The guidance breaks down when the environment has already accumulated so many unmanaged exceptions that import would only formalise ambiguity.

Where import breaks down and what practitioners should watch

Tighter control over CI/CD often increases short-term operational overhead, because the team has to reconcile live behaviour with declared state before the first successful import.

That trade-off matters most in edge cases. Blue-green or multi-environment delivery setups can look tidy on paper while hiding different permissions, secret scopes, or release approvals in each lane. Hybrid estates are another common exception: part of the pipeline may be standardised, while another part is tied to legacy deployment tooling that resists clean modelling. In those situations, the right answer is rarely total import or total rebuild. A staged approach may be safer, but only if the organisation is clear about which elements are being governed first and which are intentionally left out.

Practitioners should also be careful not to confuse import with endorsement. Bringing an existing resource under code does not make it well designed; it only makes it observable and repeatable. If the imported state includes weak permission boundaries, stale secrets, or uncontrolled service accounts, those issues remain and may become more visible once governance improves. The decision should therefore turn on whether the team is trying to preserve a working delivery path while adding control, or whether it needs a clean break from an inheritance model that cannot be trusted.

When uncertainty is high, the most useful criterion is whether the organisation can explain the live resource to an auditor or operator without relying on tribal knowledge. If not, rebuild may be the clearer governance choice.

Practitioner Guidance

What to prioritise: Start with the resources that are both production-critical and reasonably stable, because those are the best candidates for import without disrupting delivery.

Decision rule: If the current CI/CD resource can be described accurately, linked to an owner, and mapped to its real dependencies, import it; if not, treat the drift as a redesign signal rather than a tooling problem.

What to verify: Confirm that the imported state matches live permissions, secret references, deployment targets, and approval paths before you trust the new declaration. The most common failure is a clean-looking configuration that does not reflect the real operating state.

Common mistake: Teams often import too early to satisfy governance deadlines and end up preserving brittle patterns they intended to retire. That turns infrastructure as code into infrastructure as documentation.

Practitioner takeaway: The best decision is the one that improves control without pretending the existing pipeline is simpler than it really is.

Related resources from NHI Mgmt Group

• How do organisations decide whether to import existing cache resources or recreate them under Terraform?
• How do organisations decide whether to scan Rust code in the CI pipeline or only before release?
• How can organisations decide whether to automate identity workflows before replacing existing IGA tools?
• How can organisations tell whether CI/CD policy publishing is under control?