From the CI/CD perspective, I don't think it makes much difference whether it is legacy or brand new (if by legacy, you mean systems that do not have automated test as it is provocatively defined in Michael Feather's book "Working Effectively with Legacy Code") codebase. The same principles still apply - you need to achieve certain level of maturity in various levels of your software delivery as I explained in the other thread here: https://coderanch.com/t/741354/engineering/Pipeline-Code-Practices-CI-CD.
The first priority when dealing with such a system is usually to create an automated build process if one does not exist. Then maybe the next priority would be to create an automated functional functional test scuffolding around it. Creating automated tests will be easier if documentation or the team members are still available (might not be the case). This activity could be hard as from the business perspective, you're spending time on what seems like "low-value activity" - if the legacy system is already in production and working "fine". Once these smoke tests are in place, you can begin with layered approach to your automated tests. The first layer being very simple and fast-running tests for problems that prevent you from doing useful testing and development on whatever functionality you are working on. The second layer tests the critical functionality for a particular feature. This can sometimes be harder that it sounds. Systems designed to be testable tend to be more modular and easier to test thant those that are not. However, this should not divert you from the goal. It is important to remember, that you should only write automated tests where they will deliver value - the vast majority of regression bugs are caused by altering framework code, so if you are only adding features that do not require changes to the underlying framweork, there is little value writing a comprehensive scuffolding (however, the exception to this is when your sofware has to run in a number of different environments - in this case automated tests combined with automated deployment to production-like environments deliver a gread deal of value since you can simply point your scripts at the environments to be tested and save yourself a lot of effort on manualt testing).
Stepankha Yuliannia, PhD.
So I left, I came home, and I ate some pie. And then I read this tiny ad: