Context:
(1) My team owns a service for which we're rolling out a new version with a big revamp of all the public interfaces and a ton of breaking changes.
(2) This is a legacy system that is being refactored to resolve some severe issues that its consumer systems have been complaining about for a long time.
(3) This service has many consumers in our org across multiple teams that depend on it for a lot of critical functionality.
(4) We need to migrate all consumers to the new service. My team cannot parallely support both the versions and the legacy system has to be deprecated before the new service deployment.
Challenges:
(1) Originally, the plan was for my team to roll out the new service and migrate all of the consumers to the new service as well.
(2) Now, we've had a huge scope expansion in the refactoring itself due to which the project timeline has extended massively.
(3) My team feels that working on such a long timeline project is risky and prone to further scope expansion if new consumers start using the old legacy system in the meanwhile.
(4) Another challenge with this is that my team has no context or understanding of all the consumer systems.
Questions:
(1) What approach can I use to now change the plan and convince the managers/tech leads of the consumer teams to own the migration of their consumers code to the new service?
(2) In general, what approach would be ideal for such a large-scale migration - Centralized migration by the service provider team vs distributed migration by all the respective consumer teams?