Vendor lock-in: what a technical audit should check besides the code

My investor readiness and due diligence service page has a line: “A separate question is how self-contained the product is; behind the interface there is sometimes somebody else’s service on a subscription.” This article unpacks it: how to check vendor lock-in before a deal. In a deal, the code moves with the repository. Everything else the product runs on sits in accounts with vendors: apps in the App Store and Google Play, the cloud, the payment account, the domain, the keys to AI models. Each of those accounts has an owner, and each vendor has its own rules: whether the account can be handed over, how long that takes, and what gets lost on the way.

I do not publish client stories. Everything below about vendors’ rules comes from their own published documents, checked on 27 September 2026, with links at the end. The rules change, so reread them before a deal. The overall order of a technical review is covered in Technology due diligence for investors; this piece is only about vendors. I do not give legal opinions: I show where a vendor’s terms talk about assignment and change of ownership; what that means for a specific deal is a lawyer’s call.

The code moves, the product does not

A technical audit usually starts with the code: architecture, quality, licences, commit history. That is necessary, but the code moves to the buyer in one operation: the repository is transferred and the buyer has it. Vendor accounts do not work that way. The app in the store, the customers’ subscriptions in the payment system, the domain, the cloud account with its databases and backups: each moves by its own procedure and on its own timeline, and some of the data does not move at all.

On the service page I describe a typical week after the term sheet is signed: “On Wednesday it turns out that the contractor who wrote the payment module closed his company two years ago, and the services sit in the founders’ personal accounts.” The second half of that sentence is what this article is about. A founder’s personal account is not just untidiness. Personal and organisation accounts follow different rules, and sometimes a personal account cannot be handed over at all; the apps can only be moved out of it into a new one.

Two examples. On Google Play, a personal account that monetises apps currently cannot change owner directly: it takes a new account and a transfer of the apps. At Apple, only a founder or co-founder of the company can convert an individual developer account into an organisation account, with a D-U-N-S number and possibly documents. Google also suggests using a separate Google account for the developer account rather than a personal one: if Gmail and Google Payments run on the same account, sharing its password opens those too.

The account register: where the review starts

The list of materials I prepare for a review includes “a register of access and account owners”. How quickly a company can put one together tells you a lot before anyone reads the code.

Build the register from documents, not from the team’s memory. The service page puts it this way: “Technical due diligence does not start with architecture. It starts with the repository history, the provider invoices and the contractor agreements, because that is where the gaps against the pitch deck show up fastest.” Invoices show what the company actually pays for and from whose card, not what the team remembers.

For each vendor the register needs answers to eight questions:

• who the account belongs to: a company or a person, and in which country;
• who holds the top role: Account Holder at Apple, owner on Google Play, root at AWS, Owner at Stripe and GitHub;
• where the second factor lives: on whose phone or key;
• whose card pays the bill;
• which mailbox receives the vendor’s notices;
• what is inside: apps, databases, domains, customer subscriptions, keys;
• whether the account can be transferred and what is lost when it is;
• how long the transfer takes and whether that can be shortened.

The last two questions take the most work, and the rest of the article goes through them vendor by vendor. But first the mailbox, because it is the most underrated item.

The mailbox that receives the warnings

Vendors warn about important changes by email, and the email goes to a specific address. In Firebase, notices about billing, legal changes and feature deprecations are, by default, often received only by the project owners. The “essential contacts” setting fixes that, but somebody has to set it.

The OpenAI services agreement has a clause worth reading twice. Notice of a material reduction in functionality goes to the account email, and a notice to that address is deemed given when sent. From receipt of the notice the customer has five business days to exercise the right to terminate (the right does not apply to beta features). If the account email is the mailbox of someone who left long ago, the window closes and nobody notices. Anthropic’s general rule is the opposite: a notice takes effect only on receipt. Changes to its terms, though, still take effect 30 days after posting, whether or not anyone read the email.

Hence a simple rule: vendor notices should go to a shared company address that more than one person reads. There is a trap in that rule, though, in .com, .net and other generic domains, where changing the owner’s email by itself starts a change of ownership. More on that below.

App Store: the app transfers, the sales history does not

Apple can transfer an app from one developer account to another. The app stays in the store, ratings and reviews are kept, users keep getting updates. But the procedure is stricter than it looks:

• only the Account Holder can initiate or accept a transfer, one on each side, and an account has exactly one Account Holder;
• the recipient has 60 days to accept, after which the transfer expires;
• an app with no version ever released on the App Store cannot be transferred, and neither can an app that is in review or waiting for release;
• sales and payment history does not move: the recipient sees only transactions after the transfer, and the seller loses access to the app’s analytics;
• TestFlight builds and Xcode Cloud data are removed before the transfer; the beta audience and build history do not carry over;
• the Apple Pay merchant ID does not transfer: payments keep working while the old certificates are valid, and by the first update the recipient needs its own;
• provisioning profiles are created again in the recipient’s account.

Sign in with Apple deserves its own paragraph. If the app uses it, the seller generates a transfer identifier for each user, and the recipient has 60 days after accepting to exchange them for its own. Miss that window and Apple’s technote TN3159 describes the only way out: transfer the app back to the original team, prepare the migration again and transfer once more. Separately from Sign in with Apple: shared keychain access works only until the first update; the keychain group is recreated under the recipient’s Team ID, and after the update users sign in once again.

The agreement with Apple does not move by itself either when the contracting party changes, as in an asset sale or a merger. The Apple Developer Program License Agreement says it may not be assigned by operation of law, merger or any other means without Apple’s express prior written consent. The request is made from the account, under Membership.

From my own practice: in the article on my store publishing pipeline I wrote that “a single expired certificate affects every provisioning profile that references it, across all apps.” Distribution certificates belong to the team, not to a person. After a transfer the provisioning profiles are created again in the recipient’s account, and the recipient sets up its own push and Apple Pay keys and certificates as the old ones expire or the first update ships. It belongs in the plan as work, not as a formality.

Google Play: orders and reports stay with the seller

Google Play has two different procedures: transferring a single app to another account, and changing the owner of the whole account.

For an app transfer, the source account files the request, the recipient approves it, then Google support reviews it, with an answer promised within two business days. You will need the registration fee transaction IDs of both accounts; search the mailbox for “developer registration fee”. Users, statistics, reviews, subscriptions, and the registered package name with its Android developer verification keys move with the app. A Play App Signing key stays with the app; a key the seller holds themselves has to be handed over separately. What does not move:

• orders placed before the transfer: they can be refunded only from the source account or through the API;
• reports: bulk exports, estimated sales, earnings and payouts. Google suggests downloading any you will need later;
• testing groups and promotions;
• links to other services: Firebase has to be relinked, ad SDKs updated.

Changing the owner of the whole account works differently. Only the current owner can start it, the new owner goes through identity verification, and every change includes a mandatory seven-day waiting period. If the owner is unavailable, the change cannot be done self-service, only through support. Since 27 May 2026 Google has explicitly banned handing over an account by sharing the login and password. At the same time Google names an acquisition as a legitimate reason for a transfer: only the unofficial routes are banned.

The Google Play Developer Distribution Agreement has a sentence worth showing to a lawyer: “If You experience a change of control, Google may, at its discretion, elect to immediately terminate this Agreement.” How often Google actually uses it I do not know, but the clause is there.

One more question from this section: where the signing key lives. Under Google’s rules, since 30 September 2026 packages not registered under Android developer verification are removed from Play. Eligible apps on Play App Signing are registered automatically, though in some cases the package has to be registered manually or requested. If the developer keeps the signing key themselves and has lost it, the package cannot be registered. “Where is the key, and who holds a copy” is a mandatory line in the register.

Firebase: without an organisation the project belongs to people

A Firebase project is a Google Cloud project: access control, billing and deletion are shared. There is no “transfer project” button; the buyer is added as an owner. If the project was created outside a Google Cloud organisation, it belongs to people, not to the company. If the personal account of the only owner is suspended, the project is suspended with it, which is why Google recommends more than one owner.

I check two details separately. Service account keys do not expire by default: a JSON key issued to the former team works until someone revokes it. And the project Owner role does not grant the right to change payment details: the billing account is managed separately and may have a different owner.

iOS push notifications through Firebase need an APNs key issued in the Apple account and uploaded to Firebase. One product feature rests on two accounts with two vendors, and a transfer has to move them in step.

AWS: consent given in advance, with conditions

The AWS Customer Agreement says the customer may not assign the agreement without AWS’s prior written consent. AWS itself may assign it without the customer’s consent in a merger, acquisition or sale of all or substantially all of its assets, or to an affiliate. The rights are not symmetrical.

In practice AWS publishes separate account assignment requirements, and in them gives consent in advance if all 11 conditions are met. Among them: no outstanding balance, charges at the moment of transfer fall on both parties, Enterprise Support is removed, AWS Artifact agreements are terminated and accepted again, and the transfer is not used to arbitrage or avoid pricing commitments to AWS (which AWS decides at its sole discretion). The exceptions are government entities, isolated regions and AWS India. Technically the transfer is a change of the root email and password. For a standalone account the root email can be changed only in the console and only as root. For an account in AWS Organizations the organisation’s management account can change it centrally, and under centralised root management such an account may have no root password at all. AWS advises removing or replacing the root MFA device before the handover, otherwise the new owner may be unable to sign in.

If the account sits in AWS Organizations, there is more. Since 19 November 2025 an account can move directly to another organisation. Organisation-level reports do not move with it, account and OU tags and SCPs have to be recreated in the new organisation, and Reserved Instances and Savings Plans leave together with the account. The key point for a buyer: the OrganizationAccountAccessRole is not deleted when an account leaves an organisation. The former owner keeps access until someone deletes the role by hand.

Two more small things with consequences. AWS promotional credits cannot be transferred; they can only be shared within one organisation. And if a Route 53 domain was moved to the buyer’s account while the DNS hosted zone stayed with the seller, the site keeps working, but traffic is controlled by whoever holds the zone. The documentation explicitly requires moving the zone or creating a new one.

Google Cloud and Microsoft

Under the Google Cloud terms, assignment without written consent is allowed only to an affiliate; there is no exception for the sale of a business. After a change of control the customer must notify Google in writing within 30 days. If the company signed a separate offline agreement, the online terms do not apply, and that agreement is what you read.

Moving a project into the buyer’s organisation, as Google’s documentation puts it, “is not a data transfer”: data and services stay in place with no downtime, and only the project’s parent changes. But the project stays linked to its original billing account, meaning the seller’s, until it is relinked separately. Inherited roles are lost, and moving a project from an organisation back to “no organisation” is possible only through Google Cloud support.

Under the standard Microsoft Customer Agreement (March 2023 edition), assignment to an affiliate is possible with written notice; any other assignment needs written approval. Microsoft has other contract forms too, and those need reading separately. And a line that matters to the seller: assignment does not relieve the assigning party of its obligations under the agreement.

GitHub: the repository moves, not all packages do

A repository transfer looks like the simplest part of a deal. But webhooks, secrets and deploy keys stay attached to the repository, which means they pass to the buyer along with whatever access the seller once configured. They need to be reissued. The original owner is also added as a collaborator on the transferred repository automatically and has to be removed.

What does not move, or breaks:

• Container registry, npm, NuGet and RubyGems packages stay with the old owner, and the link to the repository breaks;
• GitHub Pages are not redirected to the new address;
• GitHub Apps and OAuth Apps are transferred separately, in developer settings;
• an invitation to transfer a repository to a personal account expires after one day.

Under GitHub’s terms an organisation must have at least one owner, and that owner is a person’s personal account. A shared “company” login is not something the terms provide for, and it cannot be handed over as an asset. GitHub’s business customers work under a separate customer agreement, so check which contract the target’s organisation runs under and who its owners are.

I have a system of my own that is deliberately built on GitHub: server inventory and telemetry with GitHub as the backend. In the article about it I wrote down the limits: “The system is bound to GitHub’s availability and product decisions” and “Actions minutes and API rate limits are generous for tens of servers and punishing for thousands.” A note like that is exactly what a reviewer wants to see: the dependency is named and weighed.

Stripe: customers are copied, subscriptions are not

If the buyer is in the same country as the seller, the Stripe account can be kept: you contact support first, then change the bank account, legal name, tax ID and owner email. The owner role can pass to an account administrator.

If the buyer is in another country, it gets harder. A Stripe account’s country cannot be changed. First the buyer is made owner of the old account; then it opens a new account in its own country and asks support to copy the data. Only customers and their payment methods are copied. Payments, invoices, subscriptions, coupons, events and logs are not: Stripe itself calls this a copy, not a migration. Subscriptions are recreated, and Stripe advises keeping the old account open, because the history stays only there.

Under the Stripe agreement, assignment needs consent that may not be unreasonably withheld, and in a merger, acquisition or sale of all or substantially all of the business the customer may assign the agreement to the successor without consent, provided it gives Stripe prompt written notice and the successor agrees in writing to assume all obligations and meets Stripe’s procedural requirements. But another clause matters more for a deal. An actual or likely change of control gives Stripe the right to change the payout schedule, delay payouts, create a reserve and suspend payment processing. Stripe must be notified promptly, of an expected change of control as well as a completed one. The payment provider should hear about the deal before closing, not from the news.

Domains: 60 days after a change of owner

One of the checks on the service page is “whether domains and marks sit with the legal entity rather than the founder”. If a domain is registered to the founder, it has to be re-registered, and for generic domains such as .com and .net the ICANN Transfer Policy applies.

Under the current version, a change of registrant is any change of name or organisation that is not a typo fix, and any change of email. Replacing the founder’s personal email with a company address already starts the procedure. After a change of registrant there is a 60-day lock on moving the domain to another registrar. You can opt out only if the registrar offers it, and only before the change-of-registrant request. The lock does not stop you changing name servers or hosting.

In June 2026 the ICANN Board adopted the recommendations of the review of this policy, but no effective date has been set, and as of 27 September 2026 the version with the 60-day lock is in force. If there is a dispute over the domain, such as a UDRP case, the registrar must deny the change of registrant. Country-code domains such as .ru or .ae follow their own rules, which I do not cover here.

AI APIs: keys, limits and credits are tied to the organisation

This is the newest part of the register and the most underrated one. Products increasingly depend on language model APIs, and these accounts have their own mechanics:

• Keys. OpenAI’s agreement forbids buying, selling or transferring API keys to third parties. At Anthropic, a key created for a workspace stays bound to it and cannot be moved to another, and a personal key stops working when the person is removed from the organisation. For anything shared, Anthropic recommends service account keys.
• Limits. Both vendors tie limits to the organisation’s history: at OpenAI the tier rises automatically with paid spend, at Anthropic with usage history and account standing. If the product moves into a new organisation on the buyer’s side, that organisation has no history. At Anthropic the standard tiers carry a monthly spend cap, and once it is reached the API returns 429 errors until the start of the next month, unless a higher limit is granted sooner.
• Special terms. At OpenAI, Zero Data Retention is available only after the organisation receives prior approval; the approved organisation then turns it on for itself or for individual projects. A new organisation has to get that approval again.
• Credits. Neither OpenAI nor Anthropic allows credits to be transferred, and purchased credits expire after a year.

The contracts differ too. At OpenAI, either party may assign the agreement to a successor to all or substantially all of its business with at least 30 days’ written notice. At Anthropic, the customer may assign only with Anthropic’s prior written consent; the exception for a sale of the business exists only for Anthropic.

In my mobile publishing pipeline, store locale drafts are generated through the Anthropic API when ANTHROPIC_API_KEY is configured. It is a small feature, but it is still its own line in the register: whose key it is, personal or service account, and in which organisation.

Vendor decisions nobody asks you about

The risk does not end with transferring accounts. Even if everything is registered correctly, the vendor can change the terms on its own, and the question is how much time the product gets:

• Anthropic commits to at least 60 days’ notice before retiring a publicly released model, and recent timelines sit close to that minimum: the retirement of Claude Opus 4.1 was announced on 5 June 2026 and it was switched off in the Claude API on 5 August;
• OpenAI commits to at least six months for generally available models unless safety or compliance require a faster timeline, and may retire previews on as little as two weeks’ notice. It also retires whole products: the Assistants API was announced for shutdown on 26 August 2025 and switched off exactly a year later, and the Videos API was announced on 24 March 2026 and switched off on 24 September, with no replacement;
• new prices at OpenAI take effect 14 days after they are posted; at Anthropic after 30 days, or earlier if the customer has received notice;
• in Azure, existing-customer status for a model is determined per subscription, and a new subscription does not inherit it even in the same tenant: if the buyer moves the product into its own subscription, the old model may be unavailable;
• Firebase Dynamic Links began shutting down on 25 August 2025, and every link stopped working, including links on custom domains.

I have my own example of such a decision, only in a device rather than the cloud. The 2026 firmware for the Klipsch Flexus soundbar, as I took apart, “bolted a write-authentication layer onto an otherwise unchanged API”. After the update, writing most settings without a signature stopped working; only volume and mute still write unsigned. The manufacturer asked nobody, and did not have to.

For an audit this comes down to one question: is it written down what the product does if the vendor retires a model, raises the price or shuts a feature? Not “is there a dependency”, because there almost always is, but “is there a plan for it”.

Contracts: assignment and change of control

Lawyers separate two cases. In an asset sale the contract has to move to another legal entity: that is assignment. In a share sale the legal entity stays the same and the party controlling it changes: that is a change of control. Vendors treat the two differently. Below is a short summary of the published terms, meant to tell a lawyer which clauses to read, not to replace the lawyer.

• AWS: assignment only with written consent, but advance consent to an account transfer is published separately, subject to conditions. No change-of-control clause.
• Google Cloud: without consent only to an affiliate that has agreed in writing to the terms, with notice, and no exception for a sale of the business; notify a change of control within 30 days.
• Microsoft (Customer Agreement): to an affiliate with notice, otherwise with written approval; assignment does not relieve the assigning party.
• GitHub: under the standard terms, no assignment without GitHub’s consent; under the customer agreement, to an affiliate with notice, otherwise with approval.
• Apple: not without express written consent, including in a merger.
• Google Play: a change of control does not need consent to assignment, but on a change of control Google may terminate immediately.
• Stripe: consent not to be unreasonably withheld; to a successor in a merger, acquisition or sale of substantially all assets without consent, but with notice and a written assumption of obligations; a change of control, including an anticipated one, must be notified promptly, and it gives Stripe the right to hold payouts.
• OpenAI: to a successor to all or substantially all of its assets or business without consent, with at least 30 days’ written notice.
• Anthropic: only with prior written consent.
• Cloudflare (self-serve subscription agreement) and Vercel (general terms): not without written consent, no exception for a sale of the business.
• Twilio: to a successor without consent, but both parties sign an assignment and assumption agreement, and it takes effect on the first day of the following month.

And a detail that is easy to miss. At Apple and AWS the sanctions representations cover not only the customer but also whoever owns or controls it (at Apple, directly or indirectly; at AWS, its banks as well). Who becomes the new controlling owner is not the company’s private business as far as the vendor is concerned.

Deadlines you cannot compress

All of the above adds up to a calendar. Build it before signing, because most of these periods do not shrink on request, and some are hard windows that must not be missed:

• App Store: the recipient has 60 days to accept a transfer, then up to two business days of processing, unless an export compliance review is needed (Apple gives no period for it);
• Sign in with Apple: 60 days after acceptance to exchange user identifiers;
• Google Play: up to two business days to review an app transfer; an account owner change takes at least seven days of waiting plus identity verification;
• a D-U-N-S number for a new entity: at Apple, up to five business days from Dun & Bradstreet plus up to two more to reach Apple; Google Play quotes up to 30 days;
• a domain in a generic TLD such as .com: a 60-day lock on moving to another registrar after a change of registrant, unless the registrar offered an opt-out before the request;
• OpenAI: at least 30 days’ notice of assignment;
• Google Cloud: notice of a change of control within 30 days after it;
• Stripe: most data copies to a new account complete within 72 hours;
• Twilio: an assignment takes effect on the first day of the following month.

Some of these run one after another rather than in parallel. Without a D-U-N-S number there is no organisation developer account, without the account there is nothing to accept, and in the App Store an app with no released version cannot be transferred at all.

My own accounts through a buyer’s eyes

The easiest way to show this is on my own setup. I run a self-hosted team messenger, and in the article about it I wrote: “There is no vendor lock-in because the data format is well-documented and the export tools work.” That is true of the data. But the messenger has mobile apps published on the App Store and Google Play, with their own Firebase configs. Looked at through a buyer’s eyes, the slowest part of the deal would be neither the server nor the database but those accounts: app transfers in two stores, the Firebase project, the APNs key, certificates that would have to be issued again.

A second example comes from this site’s own measurements. The service account key my scripts use to read Google Search Console was stored only in the working environment and got lost when that environment was moved. There was no copy anywhere. Google hands out the private part of a key once, at creation, so the old key cannot be recovered. Restoring access is easy because the project and the service account are mine: issue a new key. Had the project sat on the personal account of someone who had left, the way back would go through support. How this showed up in the numbers is covered in the article on metrics before dashboards.

The order of checks

1. A register built from invoices. Every vendor the company pays, plus the free accounts the product depends on: stores, domains, Firebase.
2. An owner for every line. Company or person, who holds the top role, where the second factor is, whose card, which mailbox gets the notices.
3. What moves and what does not. Sales history, orders, subscriptions in the payment system, packages, credits, rate-limit tier, special approvals.
4. A calendar of deadlines. Which procedures run in sequence and how long they take, up to the closing date.
5. Whom to tell about the deal. Where consent is needed, where notice before closing, where after. A lawyer decides this; my job is to point at the clauses.
6. The seller’s residual access. The AWS role, service account keys, secrets in the repository, anything that survives the transfer.
7. A plan for vendor decisions. What the product does if a model is retired, a price goes up or a feature is shut down.

What I do not do

• I do not give legal opinions. From the service page: “I find that rights to the code were never assigned and show where; the contract is a lawyer’s job.” The same goes for vendor contracts.
• I do not hand over accounts by sharing a login and password outside the official procedure. Google Play has explicitly banned it since 27 May 2026, and the OpenAI agreement forbids sharing credentials between users. At AWS the procedure itself is a change of the root email and password, carried out under AWS’s published conditions.
• I do not treat a dependency as a defect in itself. The defect starts where nobody knows about it, it is not written down, and it sits in a person’s name.
• I do not invent client stories. Every example in this article comes from the vendors’ published rules or from my own systems.

Frequently asked questions

What does vendor lock-in mean in a technical audit?

Everything the product runs on outside its own code: app store accounts, the cloud, the payment account, domains, API keys. The audit checks who they are registered to, whether they can be transferred in a deal, what is lost when they are, and what happens if the vendor changes its terms.

Can we just hand over the account login and password?

Not as a substitute for the official procedure. Since 27 May 2026 Google Play explicitly bans handing over an account by sharing the login and password, and Apple, Stripe and GitHub have separate procedures for changing the owner. At AWS the transfer technically is a change of the root email and password, but the agreement only moves if AWS’s published conditions are met. A password simply handed over does not change the legal owner and leaves access with the previous one.

Does the sales history move when an app is transferred?

No. In the App Store the recipient sees only transactions after the transfer. On Google Play, orders placed before the transfer and the financial reports stay in the source account, and Google advises downloading the reports in advance.

How long does it take to transfer vendor accounts in a deal?

It depends on the vendor, and some periods run in sequence. In the App Store the recipient has 60 days to accept, a Google Play account owner change takes at least seven days, and after a change of registrant on a generic TLD such as .com there is usually a 60-day lock on moving to another registrar. Build the calendar before signing.

What happens to AI API keys after a deal?

If the product moves to the buyer’s organisation, the keys do not move with it: OpenAI forbids transferring them to third parties, Anthropic binds a key to its workspace, and a personal key stops working when the person is removed from the organisation. Limits depend on the organisation’s history, so a new organisation on the buyer’s side starts without one.

Do vendors need to be told about a change of company ownership?

Some do. Google Cloud requires notice within 30 days after a change of control, Stripe requires prompt notice of an expected change as well, and Google Play may terminate on a change of control. What exactly to do in a specific deal is for a lawyer to decide.

Does the seller keep access after the transfer?

They may. In AWS the organisation access role is not deleted when an account leaves the organisation, on GitHub the original owner is automatically added as a collaborator on the transferred repository, Google service account keys do not expire by default, and repository secrets and deploy keys move along with the repository. After closing, the role and the collaborator should be removed and the keys and secrets reissued.

Sources

• Apple: overview of app transfer and app transfer criteria.
• Apple TN3159: migrating Sign in with Apple users for an app transfer.
• Apple Developer Program License Agreement, sections 11.2, 14.3 and 14.8.
• Google Play: transfer apps and change the account owner.
• Android Developers Blog, 15 April 2026: the ban on unofficial transfers and the seven-day cool-down.
• Google Play Developer Distribution Agreement, sections 16.6 and 16.7.
• Google Play: package registration for developer verification.
• Firebase: basic roles and the Dynamic Links shutdown.
• Google Cloud: service account keys and project migration.
• Google Cloud terms, sections 14.3 and 14.4.
• AWS Customer Agreement and AWS account assignment requirements.
• AWS Organizations: account migration and transferring a domain between AWS accounts.
• GitHub: transferring a repository and package permissions.
• Stripe: transferring an account to a buyer in another country and services terms.
• ICANN Transfer Policy, 2024 version.
• OpenAI Services Agreement and deprecations.
• Anthropic Commercial Terms, tiers and rate limits and model deprecations.
• Microsoft Foundry: model retirements.

Need a consultation?

If you are preparing for a round or buying a company and want to know what the product runs on besides its code, book a call. We start with the account register and the calendar of deadlines. More on how the review works is on the service page.