Why Did We Start by Trying to Replace the Tools Customers Already Use?

A while back I wrote we built all the connectors, so why do we recommend migrating?. The argument was that managing everything from issues through code, builds, and deployment in one structure lets you handle relationships, permissions, and execution more consistently. That advantage still stands. But I want to add one criterion to how that post judged the adoption path: where do you start?

Can integration really not carry relationships and permissions across?

Some of it, it can. The earlier post leaned hard on the limits of pulling reference relationships and permissions through an integration. If that read as "integration cannot handle those relationships in principle," it was too broad a claim. Preserving external identifiers, managing explicit links, checking permissions, and using execution APIs solve part of it. The real question is under which conditions, and how accurately, those relationships can be kept.

That distinction matters when you think about how a customer decides. From the vendor's seat, unifying the model inside one platform is the natural thing. The customer already runs tools, and around those tools they have accumulated processes and lines of responsibility. The benefit of a unified structure and the cost of moving into it have to be calculated together.

Why do customers not start from replacing tools?

Because the problem they want solved is often smaller than a tool replacement. Take an organization already running Jira, GitLab, and Jenkins. If what they struggle with is matching the scope of changes against verification results right before a release, the first question is whether solving that requires replacing both issue tracking and repositories. If connecting the necessary relationships in the existing environment gets them there, that path deserves consideration, and it is a path we support.

On the other hand, an organization standing up a new development environment, or one that wants to replace tools because of their operating burden, is a good fit for adopting the platform's native capabilities together. The requirement to install on an internal network and the requirement to move repositories are also separate things. Where the software runs does not by itself decide how many tools get replaced.

What should determine the scope of adoption?

The outcome the customer wants, and the smallest change that produces it. If the goal is gathering evidence for releases, which systems do we need to read, and what from them? If execution should be connected too, which permissions does that take? What evidence cannot be obtained from the current environment at all? Those three questions do far more to set the scope than "which tools should we replace?"

If you choose integration, what engineering does it take?

Everything that comes after a successful demo. Events can arrive late or go missing. Token permissions change. Source data gets deleted. An integration is only operable once it handles deduplication, re-collection, status checks, and permission changes. Most of what we learned building connectors lives in this list.

Linking the right target matters too. Seeing the same branch name or issue number does not prove two records are evidence for the same change. Which revision of which repository, which build produced the artifact, what was verified against that artifact: those links have to be explicit. Preserving the identifiers and evidence the source system provides is the design rule here.

How should missing data be shown?

As missing. If a scan result could not be read because the external system was unreachable, that does not mean the scan passed. If the latest state could not be confirmed, show it together with the time it was last confirmed. Traceability is not finished by drawing more connecting lines. It is finished when what was verified and what was not are shown as different things.

Putting Change at the center of CollabOps follows from this question. Whether the evidence for a change came from our native features or from the customer's existing tools, it should be possible to understand, on one screen, which decision that evidence supports. Wherever the evidence originates, Change is the unit that binds it.

None of this means recommending integration to everyone. There are conditions where migration is better, and conditions where keeping existing tools is better. The one thing I want to change is a habit: treating the structure the vendor is used to as the customer's starting point.

So when adoption comes up, the first questions are these. What is the hardest judgment you have to make right now? What would have to change for that judgment to change? When we can answer that starting from the environment the customer already has, "integrated" stops being a word and becomes something worth paying for.