We should show how to do it the recommended way first. Maybe something like:

The TableAdminClient can now be imported directly from google.cloud.bigtable.admin. This is the new recommended approach:
from google.cloud.bigtable.admin import TableAdminClient
...
Access to the admin clients throughgoogle.cloud.bigtable.Client is also supported for backward compatibility:
...

What if user add new client with the future-proof import, in addition to existing client like the following?

i.e.

# User's existing codefrom google.cloud.bigtable import Clientclient = Client()instance_admin_client = client.instance_admin_client()# Added new code to try out the "correct way" of importing new client"from google.cloud.bigtable.admin import BigtableInstanceAdminClientinstance_admin_client_new = BigtableInstanceAdminClient()

I guess this technically would create two clients which we don't want?

Currently it is more like a quick-start guide, instead of the migration guide.

For migration, we should start from the code users have from legacy client and suggest what to do from there.

For example:
Path A (if you have time) - Add new import, remove old import, and convert all methods to new style, rebuild, test.
Path B (if you don't have time, but want to get new features) - Get new client via legacy client and use it.

And indicate the path B is only for backward compatible phase and will be eventually deprecated.

Yeah, I'd probably suggest removing this section for now, and we can just add to the breaking change section as we add PRs. We can re-visit other content to include at the end (and we have that other doc to discuss this on as well)

This bullet is a bit confusing. Is this referring to callingclient.instance_admin_client()?

It doesn't really say how this will impact people, or what they'd need to do