Publishing depends on three things, not on the login alone
Getting credentials only means you can open the console. Whether you can keep shipping depends on who holds the owner role, who holds the keys that sign or upload builds, and what policy state the account and app are in. If any one of the three is broken, the app may be visible in the console but impossible to update. Verify each separately instead of relying on a screenshot of install counts.
Whole-account handover and single-app transfer are different deals
In a whole-account handover, the app stays in the original account, so the package name and store listing do not change; the risk sits in account status and identity details. In an app transfer, Play Console moves one app into another developer account that must meet the platform's conditions; the risk sits in those conditions and in the signing setup. Exact limits are defined on Google's help pages at the time, so ask the seller which route applies. The package name cannot be changed once published, so re-releasing under a new one means a new app without the old ratings or installs.
Signing keys decide whether new versions keep the same app identity
With Play App Signing enabled, Google holds the app signing key and the seller holds only an upload key. If the upload key is lost or cannot be handed over, Play Console has a reset process, but it is a request with its own wait, not an instant switch. For older apps that never enabled Play App Signing, the keystore file and its passwords are the only credential, and without them you cannot update under the same signature. Ask three questions: is Play App Signing on, how will the upload key be delivered or reset, and are the keystore and passwords part of the handover.
Check account and app status yourself before paying
In Play Console, look at the policy status page for open violations or warnings, whether the app is published, suspended or removed, whether developer profile verification is complete, and whether the app meets the current target API level requirement. Apps that went unmaintained often fall behind on target API level, which can block updates or hide the app from some devices until you modernize it. Those requirements change yearly, so rely on the platform's current policy page. A transfer also does not erase history: if the account ever had a termination or serious violation, ask the seller to state it plainly.
Changing identity details can trigger re-verification
Developer name, contact person, email, payment profile and account type (personal or organization) are all tied to verification. After handover you will need to update the support email, privacy policy URL and contact details on the store listing, and you should do that through the platform's normal change flow with time reserved for extra verification requests. Personal and organization accounts are not interchangeable, so if you plan to publish under a company name, choose an organization account from the start. Hiding the original details or sidestepping verification is not acceptable and only makes the account less stable.
A pre-order checklist, and when to walk away
Confirm that the owner role can be fully handed over, that the app list and package names match what was described, whether Play App Signing is on and how the upload key is delivered or reset, that the policy page has no unresolved issues, that the target API level is current, and that profile verification is done. After delivery, do not push a production release first. Upload a build to the internal testing track to confirm signing and upload rights work, then move on. Pause or switch plans if the seller cannot explain how keys are handled, if the policy page shows unexplained violations, or if owner rights cannot be handed over fully. In those cases a clean account with a fresh app is often easier to control than a vague aged account with an app attached.