make sure the new service works before forcing everyone onto it, ideally be able to run both old and new in parallel while proving the new service works as intended; after cutting over to new service leave the old service up in read only mode until such time as everyone is comfortable turning it off. backups.
if one or more of the new services needs to be up in order to ship (planned / emergency patch) releases, think through if it is acceptable to not be able to ship releases for some time & plan accordingly.
I've seen migrations happen properly for version control and CI, with everything being completely moved off the old systems.
If your current pipeline has lots of integration (e.g. notifications from version control to issue trackers, build processes that update wikis, etc) all of that stuff will need to be discovered, deleted or ported.
larger enterprise orgs (500+ engineers, say) always seem to be migrating between these services. If you switch companies you'll find people migrating from A to B when your last team just did a B to A migration.