Also it makes sense to phase deprecation. Start by no longer issuing new API keys. If your API has a messages or comments field in the return object, you can add a notice that it's deprecated with a link to the new API to discourage new development.
The biggest thing (IMO) is to make the transition process painless. If there's functionality that v1 has that v2 doesn't, users who like that functionality will cling to v1. If there's an endpoint in v1 with no clear equivalent in v2, that's gonna slow adoption unless there's a clear transition process documented somewhere.
From a client perspective, everything is running well, you decide to change and it will cost them $X and Y (time) to match it. If there is not great value to the customer to change, then they might seek out a competitor.
Can you not make a compatibility library that lets them use the old interface on the new API?
Can you not run both systems, just not allow new customers on the old API?