Six Myths That Keep Old Delivery Pipelines Unmaintained

Organisations that invest in transformation tend to measure progress by what they launched: a new pipeline, a new platform, a new set of practices. Far fewer ask what became of last year’s launches. In consulting work this gap shows up repeatedly, and it is sustained by a handful of comfortable beliefs. Here are six of them, with the reasoning for why each one deserves to be retired. The common thread is that upkeep of existing delivery assets is not a lesser activity than building new ones. It is what keeps the earlier investment worth having.

Myth one: if nothing has broken, the system is healthy

An absence of incidents tells you only that nobody has noticed a problem. Certificates approach expiry quietly, base images fall behind on security fixes, and scheduled jobs begin to fail in ways that no alert covers. Health is something you demonstrate through inspection, not something you infer from silence. A short, regular review of what runs in production, who owns it and when it was last exercised produces far more reliable assurance than a clean incident log.

Myth two: modernisation means replacing the old with the new

Replacement is sometimes right, but it is often a way of avoiding the harder work of understanding the current estate. A rebuilt pipeline inherits the same unclear requirements, and it adds a migration to the list of risks. The engagement structure described in this outline of a consulting engagement from assessment to enablement starts with assessment for a reason: you cannot responsibly change what you have not examined. In many cases targeted repair, such as updating dependencies and removing dead stages, captures the bulk of the gain with far less upheaval.

A useful exercise is to pick one pipeline at random and trace its last meaningful change. If the answer is measured in years, you have found a candidate for review. The point is not blame; most teams have simply been busy with the next deadline, and the older asset never asked for attention until it failed.

Myth three: security work belongs at the start of the pipeline only

Teams often invest in scanning when a pipeline is first created and then leave the configuration untouched. Rules go out of date, exceptions accumulate, and credentials created for a pilot remain valid long after the pilot ended. Treat the security posture of an existing pipeline as something with a shelf life. The discussion of integrating security checks into delivery pipelines is a useful baseline, and a periodic comparison between that baseline and your live configuration will show where exceptions have quietly become the norm.

Consultants are well placed to run this kind of review because they arrive without loyalty to past decisions. A fresh pair of eyes asks why a stage exists, who reads its output, and what would happen if it vanished. Those questions are uncomfortable but cheap, and they expose the assets that persist only out of habit.

Myth four: documentation is a deliverable, not a dependency

Handover documents are produced at the end of a project and then treated as complete. In practice they are among the first assets to decay, because the systems they describe keep changing. Pages reference dashboards that were renamed, runbooks point to consoles that moved, and diagrams show services that were decommissioned. Stale documentation is worse than none, because it carries authority it no longer deserves. Give each key document an owner and a review interval, and prune it when the subject changes.

Links inside those documents deserve particular attention. A platform such as URLSnow, which manages published links and probes each address automatically, reporting the ones that no longer answer, can take over the tedious part of this review. A consultant can then spend time on whether the content is still correct rather than on clicking every address.

Myth five: automated tests protect themselves

A test suite is code, and code needs maintenance. Tests become flaky, get skipped to meet a deadline, or continue to assert behaviour that the product no longer has. Over time the pipeline turns green for reasons unrelated to quality. Review which tests are skipped, which have not failed in a long time, and which cover features that no longer exist. For orientation on what a healthy suite contributes, the piece on how automated testing shapes quality and delivery speed sets out the expected benefits, which is exactly what you should check your own suite still delivers.

Healthy suites also have owners. Assign each major test area to a person or a team, and make skipping a test a visible decision with an expiry date rather than a permanent shrug.

Myth six: retiring a system is riskier than keeping it

Keeping feels safe because nothing changes. Yet every retained system carries cost: patching, access control, monitoring, licences and the cognitive load of remembering it exists. Unused systems often hold the oldest software and the broadest permissions. A planned retirement, with notice to consumers, a trial period of switched-off operation and a verified backup, is usually lower risk than an indefinite stay. The unplanned alternative arrives when the system fails or is breached, and then retirement happens at the worst possible moment.

Whatever the size of the estate, start small. One service, one pipeline and one document set is enough to learn how long a review takes and what it tends to uncover. Scale the routine only after the first round has produced concrete repairs, because evidence of value is what keeps leadership supportive.

What to do instead

Replace the myths with a modest, repeatable routine. Maintain an inventory of delivery assets with owners. At fixed intervals, put three questions to each one: whether it functions today, whether anyone still depends on it, and whether its pointers lead somewhere correct. Record the decision, assign the repair or the retirement, and report the results to leadership in the same way you would report a launch. This turns upkeep into a visible contribution, rather than an invisible chore.

Clients who adopt this habit typically find that new initiatives proceed more smoothly, because they are not built over a foundation of unknown condition. For a consultant, the benefit is credibility: recommendations rest on observed facts about the current estate rather than assumptions. For an in-house team, the benefit is fewer surprises. Either way, the discipline is inexpensive relative to the cost of a failure that everybody could have predicted.

Kabir Malhotra