Continuous delivery transformations are hard enough in many areas already: changing people's behavior, changing policies, architecting things differently - all these things are difficult on their own.
Having a toolchain that prohibits you from achieving your pipelines in a way that fully supports CI/CD is something you can try to avoid off the bat.
The simple rule is:
Don't select your toolchain before you've designed the pipeline you wish to have
Don't decide you're going to use a specific tool for the new way of working before you've done at least the following:
- Choose a project in your organization that exemplifies an "average" project (if there are many types choose two or three).
- Do a value stream mapping of that project from conception to cash - from the point of an idea, to that getting into a backlog, to that code ending up in production. Then Time the value stream and see how long each step takes.
- Once you have a value stream, design a conceptual pipeline that tries to automate as much of the value stream as possible (some things will not be able to be automated without the change of organizational policies)
Now that you have conceptual pipeline (or several), you can start deciding which tools fit best for the actions you would like to pull off in the pipeline.
What you'll find is that some tools will not lend themselves easily into the pipeline work, and some tools will fit in just right.
Remember: the pipeline drives the tool selection. Not the other way around.
You should not let the tool dictate how your pipeline works because you're trying to change the way the organization works, not map the organization to a tool that might hider your progress.