The enterprise program is for internal distribution only, not a premium company account
The Apple Developer Enterprise Program is built for organizations that need to distribute apps to their own employees. Apps signed under it cannot go on the App Store and should not be installed by the public or by customers. Many buyers search for an enterprise account hoping to skip App Store review for outside users, which is exactly the use the program terms disallow, and it puts both the account and its certificates at risk. Ask first whether every user of the app is an employee of the account's own legal entity. If not, you need an organization account under the standard program. Eligibility and fees follow whatever Apple's current pages say.
Handover means the Account Holder changes, not that you get an extra Admin
An Admin or App Manager role lets you manage certificates, members and apps, but agreements, renewal and legal responsibility stay with the Account Holder entity. Receiving only a login is not a real handover: the Apple ID's two-factor phone number and email remain with the seller, and if they change or reclaim them you lose access. Before ordering, confirm that the entity name matches the D-U-N-S record, that the seller can change the Account Holder through Apple's own process, and who will own the verification phone and email in the end. What documents Apple requires is set by Apple at the time. If the seller cannot explain this, treat the account as not transferable.
Whether existing certificates keep working depends on who holds the private key
Apple's portal stores the certificate, but the private key lives in the keychain of the Mac that generated the CSR, usually backed up as a .p12 file. If that file does not come with the account, you can only create a new certificate. That is fine on its own, but revoking the old one will stop every internal app signed with it from launching on installed devices. So ask whether internal apps are in use today. If they are, request a signing inventory: certificate type and expiry, Bundle IDs, provisioning profile expiry, and whether the .p12 is included. Distribution certificates are capped per account, and the exact limit is whatever the portal shows.
The device list is not what enterprise handover hinges on
A common assumption needs correcting: In-House provisioning profiles are not tied to device UDIDs, so internal distribution does not require a registered device list. Device lists mainly appear with development and testing profiles. What you actually need handed over is the Bundle IDs, profiles, the internal download page or MDM setup, and a clear picture of how employees currently install the apps. If the portal does show registered devices, check whether they include the previous owner's staff personal phones, and have the seller clear or explain them rather than inheriting them as is.
When to stop or switch plans
Walk away or change plans if the intended use is outside distribution or customer installs, if the seller cannot prove the account entity or complete an Account Holder change, if live internal apps exist but the private key and distribution method are unavailable, or if the account has had warnings or certificate revocations and the seller will not share the history. Also pin down the renewal date. Once membership lapses or the certificate expires, internal apps stop running, so who pays, and with which payment method, belongs in the handover schedule.
FAQ
What happens to installed internal apps if the enterprise account is not renewed?
Apps signed with an expired certificate or under a lapsed membership will generally stop launching on devices. Exact behavior depends on Apple's current rules, so agree on the renewal date and payer during handover.
Do I need the enterprise program, or is a standard organization account enough?
If anyone outside your employees will use the app, or you need the App Store or TestFlight, use an organization account under the standard program. The enterprise program only fits purely internal distribution.