How does an online escrow service protect the buyer and seller of an app, and what happens if the inspection period lapses?
An escrow service such as Escrow.com holds the buyer's money through an agreed inspection period and treats a buyer that neither accepts nor rejects as having accepted, so the money goes to the seller when the period ends.
Escrow.com's inspection periods run from 1 to 30 calendar days, are agreed at the start, and should allow enough time for required authentication or appraisal. The period starts when the buyer marks receipt or Escrow.com verifies or receives confirmation of delivery, which is why the handover checklist matters before anything is marked received. A reminder before release is not guaranteed.
Escrow.com's instructions require the buyer to return rejected property before receiving a refund, and failure to return it within the specified period causes payment to the seller.
Unless the parties agree otherwise in the transaction, the buyer pays Escrow.com's fees, which are nonrefundable once paid. The buyer's agreed share is automatically added to the purchase price. On cancellation or return, however, the buyer bears the entire escrow fee, which is deducted from the refund regardless of an earlier split. Consequently, a contractual split alone does not change that deduction; reimbursement by the seller would be needed to restore the seller's agreed share to the buyer.
Escrow does not check title: Escrow.com assumes no responsibility for the condition of ownership or the sufficiency of the documents that convey it.
Sources for this answer
Escrow.com's General Escrow Instructions require the buyer to accept or reject during the inspection period and treat a buyer who does neither as having accepted.
During the Buyer Inspection Period, Buyer shall either: (1) select the "Accept" button on the Escrow.com website, and follow all further instructions accordingly to complete acceptance of the goods; or (2) select the "Reject" button and follow any further instructions to complete the rejection of the goods. Should the Buyer fail to select either the "Accept" or "Reject" buttons, and/or follow all further instructions, then Buyer shall be deemed to be satisfied with the quality of the goods/domain(s), and to have accepted the goods/domain(s).
See § 4; accessed October 3, 2026
Escrow.com's support guidance states that if the buyer takes no action within the inspection period, Escrow.com releases the funds to the seller when the period ends.
If the Buyer does not take any action within the Inspection Period, at the end of the agreed-upon Inspection Period, Escrow.com will release the funds to the Seller.
See End of Inspection Period; accessed October 3, 2026
Escrow.com's support guidance states that inspection periods run from 1 to 30 calendar days, are agreed at the start of the transaction, and should leave enough time for any authentication or appraisal.
Inspection Periods are 1 - 30 calendar days and must be agreed upon by all parties at the initiation of the transaction. Buyers and Sellers should ascertain the Inspection Period provides adequate time for any authentication and/or appraisal process required to complete the transaction.
See How long is the Inspection Period?; accessed October 3, 2026
Escrow.com's support guidance states that the inspection period begins when the buyer marks the item received or when Escrow.com verifies or receives confirmation of delivery.
The Inspection Period begins when the Buyer marks the merchandise or service as “Received” or when Escrow.com verifies or receives confirmation that the merchandise, domain, or service has been delivered.
See Start of Inspection Period; accessed October 3, 2026
Escrow.com's support guidance states that a 24-hour notice before release when the buyer has not participated is decided case by case and is not guaranteed.
In some cases, Escrow.com may send a 24-hour notice if the Inspection Period is started and ended without the Buyer's participation. This is evaluated on a case-by-case basis and isn't guaranteed to happen every time.
See 24 Hour Notice; accessed October 3, 2026
Escrow.com's General Escrow Instructions require rejected property to be returned to the seller before funds are returned to the buyer, and pay the seller if the buyer does not return it in time.
Buyer is aware that regardless of the reason for rejection, Escrowed Property must be returned to the Seller in order for funds to be returned to the Buyer. Shipping costs for returned Escrowed Property must be arranged and completed within ten (10) days of Buyer's rejection. Failure of Buyer to return the Escrowed Property within the specified time period will cause Escrow.com to automatically pay the Seller the purchase price.
See § 5; accessed October 3, 2026
Escrow.com's Terms of Use make the buyer pay its service fees and third-party service fees unless the users agree otherwise in the transaction, and state that paid fees are nonrefundable.
16. Fees. Unless otherwise agreed upon by each User in the Transaction, Buyer agrees to pay the fees for the Services that are disclosed on the Site at the time the completed Transaction Escrow Instructions are agreed to by all such Users, as well as any other fees, including, without limitation, third party service fees (e.g., shipping, appraisal, inspection, registration - domain or otherwise, etc.). Once paid, Escrow.com fees are nonrefundable.
See § 16; accessed October 3, 2026
Escrow.com's fee page states that a buyer who agreed to pay all or part of the fee has it added to the purchase price automatically.
If you've agreed to pay all or some of the fee, it's automatically added to the purchase price of the merchandise, vehicle or domain name.
See Buyer guidelines; accessed October 3, 2026
Escrow.com's General Escrow Instructions make the buyer responsible for the entire escrow fee if the transaction is cancelled or the merchandise is returned.
The buyer is responsible for 100% of the escrow fee in the event the transaction is cancelled or the merchandise is returned.
See § 5; accessed October 3, 2026
Escrow.com's General Escrow Instructions deduct the entire escrow fee from a buyer's refund on cancellation regardless of any earlier fee split between the buyer and seller.
Buyer hereby agrees that the entire escrow fee shall be deducted from his/her/its refund regardless of any other previous arrangement for allocation of the escrow fee that may have been made between Buyer and Seller (and Broker when applicable).
See § 8; accessed October 3, 2026
Escrow.com's General Escrow Instructions state that its escrow services include no warranty and that it assumes no responsibility for the legality of the transaction, the condition of ownership or the sufficiency of the instruments conveying ownership.
The Buyer and Seller (and Broker when applicable) understand that the above escrow services DO NOT include any representation of warranty, either expressed or implied by Escrow.com, and that Escrow.com assumes no responsibility for the legality of the transaction, condition of the ownership, sufficiency of instruments conveying ownership, or agreements therefore.
See § 22; accessed October 3, 2026
Is a marketplace's standard purchase agreement enough, or should it be negotiated?
A marketplace's standard purchase agreement may come without any assurance that it fits a particular deal, so whether it is enough depends on whether its terms cover that deal's price structure, assets and risks.
TrustMRR's terms, for example, describe its document templates as a convenience only and disclaim any representation about their legal sufficiency or appropriateness for a specific situation.
The standard agreement is also where the buyer's protection sits, because the platform stays outside it; TrustMRR's terms say it is not the buyer or seller and not a party to any acquisition agreement between users. TrustMRR's terms also state that the acquisition agreement and asset transfer remain between the buyer and seller, and that transferring the startup's assets is solely the responsibility of the buyer and seller. Protection against inaccurate revenue figures, missing assets or failed transfers therefore comes from the purchase agreement's own terms, because the platform does not guarantee either party, the assets or the outcome; the questions on revenue figures, recovery for inaccurate representations and handover describe those terms.
A price paid partly after closing is one sign that the default needs more; TrustMRR's FAQ says the platform supports only a single lump-sum payment through escrow and that other payment arrangements are handled outside it. A deal that needs a holdback, deferred payment, earnout or seller note therefore needs its own terms, discussed under deferred payment and earnouts, and a route the platform's terms permit, which for TrustMRR means written approval before completing a transaction outside its standard escrow.
A general asset description is another sign; TrustMRR's FAQ says escrow needs verifiable asset details and that missing or vague asset details can lead to rejection of the agreement. An itemized asset schedule serves the escrow review, because TrustMRR creates the escrow transaction from the APA's asset details, and also gives the buyer a fixed list against which delivery is later checked.
Assets that need third-party consent or a migration in several steps, customer obligations that straddle closing and a seller restraint on competing are other signs, covered under consents, account migration, customer obligations and seller non-competes. Whether a particular platform form already covers them is a question for the text of the revision the parties will sign, because it is the executed document that may create binding obligations according to its terms.
Sources for this answer
TrustMRR's terms state that its document templates are provided as a convenience only, without representations about legal sufficiency, enforceability or appropriateness for a specific situation.
TrustMRR provides document templates as a convenience only. We make no representations or warranties about the legal sufficiency, enforceability, or appropriateness of these documents for your specific situation.
See § 11.1; accessed September 29, 2026
TrustMRR's terms state that the acquisition agreement and asset transfer remain between the buyer and seller.
TrustMRR brokers and facilitates startup acquisition opportunities, but the acquisition agreement and asset transfer remain between the buyer and seller.
See § 10.7; accessed September 29, 2026
TrustMRR's terms state that transferring a startup's assets is solely the responsibility of the buyer and seller.
The transfer of startup assets (including but not limited to source code, domains, customer data, intellectual property, accounts, and any other assets) is solely the responsibility of the buyer and seller.
See § 11.4; accessed September 29, 2026
TrustMRR's FAQ says the platform supports only a single lump-sum payment through escrow and that custom payment arrangements are handled outside it.
TrustMRR only supports a single lump-sum payment through escrow. Structures like paying 50% upfront and the rest after 60 days, earnouts tied to future revenue, or seller financing are not available on the platform. If you need a custom payment arrangement, you would have to handle it outside of TrustMRR.
See Deals, Legal Docs, and Payments; accessed September 29, 2026
TrustMRR's FAQ says escrow needs verifiable asset details and that missing or vague asset details can lead to rejection.
Escrow needs verifiable asset details. If you’re transferring public assets (domains, social accounts, repos, etc.), include their URLs in the APA. Missing or vague asset details can lead to rejection.
See Deals, Legal Docs, and Payments; accessed September 29, 2026
TrustMRR's terms state that it is not the buyer or seller and not a party to any acquisition agreement between users.
We are not the buyer or seller and are not a party to any acquisition agreement between users.
See § 10.1; accessed September 30, 2026
TrustMRR's terms state that it does not guarantee either party, the assets or the outcome.
TrustMRR does not guarantee either party, the assets, or the outcome.
See § 10.7; accessed September 30, 2026
TrustMRR's terms require users whose transaction does not suit its standard escrow to contact support and obtain written approval before completing the transaction outside the platform.
If, for any reason, our standard escrow service is not suitable for your transaction (e.g., you need to use a bank escrow, attorney escrow, or complete the transaction directly), you must: - Contact TrustMRR customer support before completing the transaction outside our platform - Obtain written approval from TrustMRR to proceed with an alternative payment method - Pay the TrustMRR platform fee as outlined in our fee structure, which will be invoiced separately - Provide proof of transaction completion to TrustMRR customer support upon request
See § 10.5; accessed September 30, 2026
TrustMRR's FAQ says it creates the Escrow.com transaction with the agreed price, the parties' Escrow.com emails and the APA asset details.
TrustMRR creates the transaction with the agreed purchase price, buyer and seller Escrow.com emails, and APA asset details.
See Deals, Legal Docs, and Payments; accessed September 29, 2026
TrustMRR's terms state that an executed document may create legally binding obligations according to its terms.
An executed document may create legally binding obligations according to its terms.
See § 11.1; accessed September 30, 2026
How can a buyer check an app's subscription revenue against the app-store reports?
A buyer can compare the seller's revenue figures with Apple's monthly financial reports and Google Play's monthly earnings reports, which report proceeds, sales or transactions for the reporting period.
Apple generates financial reports on its fiscal calendar for periods containing purchases or refunds. Google Play's earnings reports contain the prior month's transactions and are typically available by the fifth of the following month.
Apple limits financial-report downloads to the Account Holder, Admin and Finance roles and retains reports for ten years. After transfer, the buyer receives Apple sales and payment information only for later transactions, while Google Play's existing earnings reports do not transfer. Consequently, the historical reports need to come from the seller rather than from the buyer's post-transfer reporting access.
Apple's Partner Share means proceeds per unit after applicable taxes and Apple's commission. Its Title field uses the app name for downloads but the Product ID for in-app purchases, so filtering only by the app name can miss those purchase rows. Google Play does not recommend estimated sales reports for accounting because they omit withholding taxes and chargebacks.
One filed marketplace-brokered agreement contained a seller warranty that the revenue and other details given to the broker were truthful and accurate, so price or trial history given to the broker as part of those details could fall within that warranty (see how the agreement defines revenue figures and the seller's dashboard figures).
Sources for this answer
Apple states that its financial reports show monthly proceeds and final unit sales by country or region and order type, generated once a month on Apple's fiscal calendar.
Financial reports show your monthly proceeds, as well as final unit sales by country or region and order type. They’re automatically generated once a month, based on Apple’s fiscal calendar, and are only generated if there are purchases or refunds during that fiscal period.
See Download financial reports; accessed October 3, 2026
Google Play states that its earnings report shows payouts and transactions, is generated monthly and is typically available by the fifth of the following month.
You can use the earnings report to understand your payout and transactions. Each line in the report represents a type of transaction, such as when you charge a customer money or pay Google a fee, along with the original and converted amounts. Earnings reports contain transactions from the prior month. You'll receive the payout several weeks after the earnings report becomes available. The earnings report is generated once per month, and is typically available by the fifth of the following month.
See Earnings; accessed October 3, 2026
Apple limits downloading financial reports to the Account Holder, Admin and Finance roles.
Required role: Account Holder, Admin, or Finance.
See Download financial reports; accessed October 3, 2026
Apple states that financial reports for the previous fiscal month are available by the first Friday of the current fiscal month and remain available for ten years.
Financial reports for the previous fiscal month's earnings are available by the first Friday of the current fiscal month. You can sign up to receive email notifications as soon as your financial reports are available each month. Learn more. Financial reports remain available for a period of ten years from the reporting date.
See Download financial reports; accessed October 3, 2026
Apple states that after a transfer the transferor keeps access to sales and payment information from before the transfer and the recipient receives that information only for transactions after it.
If you transfer your app, you’ll continue to have access to information for payments and sales that occurred prior to the transfer. However, after the transfer, you won’t have access to information regarding sales and payments that take place afterward. The recipient of the transferred app will only receive payment and sales information for transactions that occurred after the transfer.
See Data for Sales and Trends and Payments and Financial Reports; accessed October 3, 2026
Google Play states that bulk export, payout and earnings reports do not transfer with an app and suggests downloading any reports needed later.
Your bulk export reports, payout reports, and earnings reports won't transfer with the app, so you may want to download any reports you'll need later. New versions of these reports will be created once the app transfers to a new account.
See Get your app ready to transfer; accessed October 3, 2026
Apple's financial report field reference defines Partner Share as the proceeds per unit, being the customer price minus applicable taxes and Apple's commission.
The proceeds you receive per unit. This is the Customer Price minus applicable taxes and Apple’s commission, per Schedule 2 of your Paid Apps Agreement.
See Partner Share; accessed October 3, 2026
Apple's financial report field reference states that the Title field shows the app's name for downloads but the Product ID for In-App Purchases.
The name of the content being purchased. For downloads, the field will populate the name of the app as set in App Store Connect. For In-App Purchases, the field will populate the Product ID as set in App Store Connect.
See Title; accessed October 3, 2026
Google Play states that its estimated sales report is not recommended for accounting and can differ from earnings because it does not account for withholding taxes or chargebacks.
You can use this report for analytics or trend analysis, but it's not recommended for accounting. Instead, see the Earnings report. You may notice differences between this report and your earnings for a number of reasons. For example, the estimated sales report doesn't take into account withholding taxes or chargebacks.
See Estimated sales; accessed October 3, 2026
The Jeffs Brands agreement had the seller warrant that it truthfully and accurately provided the broker details of the asset's revenue, profit, expenses, pageviews and work required, and qualified its litigation warranty by the seller's knowledge.
(e) Seller has truthfully and accurately provided details relating to the Asset to Broker including, but not limited to, details regarding revenue, profit, expenses, pageviews, work required per week, creation date, and use of a private blog network, if any; (f) There are no bankruptcy or reorganization proceedings currently filed against Seller that would impede its ability to complete this Agreement; and, (g) To the best of the Seller’s knowledge, there is no lawsuit or pending charge against the Asset.
See ¶12(e)–(g)
How is a buyer protected if the seller does not disclose a drop in traffic or revenue?
A buyer's contractual protection against an undisclosed drop in traffic or revenue rests mainly on the purchase agreement's representations about the figures the seller supplied, because marketplaces such as Acquire.com and Flippa leave checking those figures to the buyer.
Acquire.com states that it performs no due diligence and is not responsible for a seller's truthfulness about a listing's existence, quality, accuracy or completeness. Flippa makes the buyer responsible for investigating the asset and listing information, including financial statements and liabilities.
One filed marketplace-brokered agreement contained a seller warranty that the revenue, profit, expense and pageview details given to the broker were truthful and accurate. The same agreement waived performance-related contingencies after inspection and acknowledged that earnings and traffic could decline. That waiver reaches any discrepancies, fluctuations or changes in performance, not only disclosed declines, but it opens with “Except as otherwise provided by this Agreement”, which is the wording that leaves room for a claim under the seller's separate accuracy warranty.
In ABRY Partners V, L.P. v. F & W Acquisition LLC, the Delaware Court of Chancery held that a damages cap could not limit remedies for the seller's intentional misrepresentation of a fact embodied in the contract. California Civil Code section 1668 makes contractual exemptions from responsibility for a party's own fraud contrary to public policy.
This guide does not survey state-law duties to disclose where the contract is silent, and the seller's side of the same issue is in pricing changes before listing.
Sources for this answer
The Jeffs Brands agreement had the seller warrant that it truthfully and accurately provided the broker details of the asset's revenue, profit, expenses, pageviews and work required, and qualified its litigation warranty by the seller's knowledge.
(e) Seller has truthfully and accurately provided details relating to the Asset to Broker including, but not limited to, details regarding revenue, profit, expenses, pageviews, work required per week, creation date, and use of a private blog network, if any; (f) There are no bankruptcy or reorganization proceedings currently filed against Seller that would impede its ability to complete this Agreement; and, (g) To the best of the Seller’s knowledge, there is no lawsuit or pending charge against the Asset.
See ¶12(e)–(g)
Acquire.com's terms state that it performs no due diligence on buyers or sellers and is not responsible for a seller's truthfulness about the existence, quality, accuracy or completeness of a listing.
8. Acquire.com performs no technical, legal, financial, or any other kind of due diligence on buyers or sellers in the Acquire.com Marketplace and makes no representations, warranties, and guarantees regarding such buyers or sellers of any kind. Acquire.com cannot guarantee whether a business listed on the Acquire.com Marketplace is suitable for a potential buyer, or whether any businesses listed on the Acquire.com Marketplace will meet the performance expectations of a buyer. Acquire.com is not responsible for a seller’s truthfulness regarding the existence, quality, accuracy, or completeness of any listing on the Acquire.com Marketplace.
See Services, item 8; accessed October 3, 2026
Flippa's terms make the buyer solely responsible for examining and investigating an asset and the information in its listing, including liabilities, financial statements and tax returns.
You accept sole responsibility for examining and investigating an asset and all information in a listing. This includes, but is not limited to, associated liabilities, financial statements, tax returns and any other facts or information which may impact your decision to purchase that listed asset and the price you are willing to pay.
See Buyer due diligence; accessed October 3, 2026
The Jeffs Brands agreement had the buyer buy the assets as is and, once the inspection period expired, waive contingencies for changes in revenue, traffic and other performance metrics.
(15) No Contingencies. Except as otherwise provided by this Agreement, Buyer had the opportunity to fully inspect the Assets, is satisfied with its inspection, and desires to purchase the Assets. Buyer agrees to buy the Assets “as is.” Upon expiration of the Inspection Period, Buyer hereby waives any and all contingencies in connection with its purchase of the Assets, including any discrepancies, fluctuations, or changes in the performance of the Asset and specifically its gross revenue, net revenue, expenses, traffic, and other metrics of performance, including any discrepancies, fluctuations, or changes in the performance of the Asset during the Migration Process.
See ¶15
The Jeffs Brands agreement stated that earnings and traffic may decline and that the buyer assumes all risk in the purchase.
(18) Broker Disclaimer. Except as otherwise provided by this Agreement, all sales are final and there are no refunds. Earnings and traffic may decline due to Google updates, increased competition, mismanagement by the Buyer, or other factors. The Parties agree that Broker makes no guarantees or warranties, written or implied, of the future performance of the Assets. Buyer specifically agrees and acknowledges that it assumes all risk in this purchase.
See ¶18
The Delaware Court of Chancery held that public policy does not permit a contract to limit a buyer to a capped damages claim when the seller intentionally misrepresented a fact embodied in the contract.
For these reasons, when a seller intentionally misrepresents a fact embodied in a contract — that is, when a seller lies — public policy will not permit a contractual provision to limit the remedy of the buyer to a capped damage claim. Rather, the buyer is free to press a claim for rescission or for full compensatory damages.
See ABRY Partners V, L.P. v. F & W Acquisition LLC, 891 A.2d 1032 (Del. Ch. 2006).
California Civil Code § 1668 makes contracts whose object is to exempt anyone from responsibility for that person's own fraud against the policy of the law.
All contracts which have for their object, directly or indirectly, to exempt any one from responsibility for his own fraud, or willful injury to the person or property of another, or violation of law, whether willful or negligent, are against the policy of the law.
See Cal. Civ. Code § 1668.
How can a buyer confirm the app runs without the seller's accounts and services?
A buyer can confirm that the app runs without the seller by building and running the delivered code in accounts the buyer controls, since Apple leaves the hand-over of code and build assets to the seller and Google's site-move guidance tests a copy on the new host.
Apple makes the transferor responsible for delivering the code and build assets directly to the recipient and explaining capabilities or App Store configuration needed for future updates. Google's site-move guidance calls for uploading a copy to the new hosting provider and thoroughly testing every aspect of how users interact with it.
The transfer also involves account-specific setup: Apple requires new provisioning profiles in the recipient's developer account, associated with the transferred app's identifier and distribution certificate. Google Play calls for updates to account settings and apps for integrated services such as Firebase and Google Analytics. Vercel requires project integrations to be added again after transfer.
A repository transfer alone does not demonstrate that every dependency has moved: GitHub keeps existing webhooks, services, secrets and deploy keys associated with the repository. That persistence means a successful repository transfer does not itself establish who controls the services behind its existing credentials, which the inventory of keys and services records.
Sources for this answer
Apple states that the transferor is responsible for exchanging the code set and build assets directly with the recipient and for telling the recipient about capabilities and App Store configuration added to the app.
The transferor is responsible for exchanging the actual code set and building assets directly with the recipient. Be sure to inform the recipient about any capabilities or App Store configuration added to the app, such as keychain sharing, Game Center, or push notifications, so these are maintained in future updates.
See What happens during and after an app transfer; accessed October 3, 2026
Google suggests uploading a copy of the site to the new hosting provider and verifying it by thoroughly testing all aspects of how users interact with the site.
First, upload a copy of your site to your new hosting provider. What a "copy of your website" means depends entirely on your old content management platform; it may be actual HTML files that you replicate on your new hosting platform, or a database export that you have to import in the new location. Once you do that, verify that it works as expected by thoroughly testing all aspects of how your users interact with your site.
See Copy and test your new site; accessed October 3, 2026
Apple requires new provisioning profiles to be created in the recipient's developer account after an app transfer.
Note: After an app transfer, you must create new provisioning profiles in the recipient's Apple Developer account. Ensure you associate these profiles with the transferred app's App ID and distribution certificate.
See Note; accessed October 3, 2026
Google Play tells developers to update account settings and apps for integrated services such as Google Analytics, Firebase and Google Play game services when an app transfers.
If your app uses any integrated services, including Google Analytics, Firebase, and Google Play game services, make sure to update your account settings and apps.
See Additional requirements for select apps; accessed October 3, 2026
Vercel states that integrations associated with a project must be added again after the transfer.
Integrations: Those associated with your project must be added again after the transfer is complete.
See What is not transferred?; accessed October 3, 2026
GitHub states that a transferred repository keeps its issues, pull requests, wiki, stars and watchers, and that its webhooks, services, secrets and deploy keys remain associated after the transfer.
When you transfer a repository, its issues, pull requests, wiki, stars, and watchers are also transferred. If the transferred repository contains webhooks, services, secrets, or deploy keys, they will remain associated after the transfer is complete.
See What's transferred with a repository?; accessed October 3, 2026
Should a buyer review the live app or the code repository?
A buyer's review can cover both the live app and the delivered repository, because the app users run transfers with its store listing while the seller hands over the code and build assets separately.
Apple states that the transferred app retains its reviews, ratings and bundle identifier, and users continue receiving updates. The seller separately supplies the code and build assets and explains capabilities or configuration needed for future updates.
When accepting an Apple transfer, the recipient reviews the previous owner's privacy disclosures; missing or deleted disclosures must be completed before a new version is submitted. Google Play states that advertising software development kit integrations in the app's package files need updating after transfer so advertising traffic is credited to the correct account.
Updates can also change existing behavior: Apple states that keychain sharing continues only until the app is updated and requires rebuilding the keychain for updates.
One filed marketplace-brokered agreement required the seller to maintain the asset as it was leading up to sale and avoid actions outside normal business practices throughout migration. A term of that kind reaches a code change made outside normal business practices during the migration. A change made before signing turns instead on what the seller disclosed and represented, the seller's side of which is in the cleaned-up code question.
Sources for this answer
Apple states that an app can be transferred while it stays available on the App Store and that it keeps its reviews, ratings and bundle ID, with users continuing to receive updates.
You can transfer your app while keeping it available for download on the App Store. During and after the transfer, the app retains its reviews and ratings, and users continue to receive updates. When an app is transferred it maintains its Bundle ID, which can’t be changed once a build has been uploaded for the app.
See Overview; accessed October 3, 2026
Apple states that the transferor is responsible for exchanging the code set and build assets directly with the recipient and for telling the recipient about capabilities and App Store configuration added to the app.
The transferor is responsible for exchanging the actual code set and building assets directly with the recipient. Be sure to inform the recipient about any capabilities or App Store configuration added to the app, such as keychain sharing, Game Center, or push notifications, so these are maintained in future updates.
See What happens during and after an app transfer; accessed October 3, 2026
Apple has the recipient review the previous owner's app privacy disclosures when accepting a transfer and complete the App privacy section before submitting a new version if they are deleted or were never given.
In the App privacy section, if the previous owner already disclosed what data the app collects and how it may be used, review the privacy details they entered by clicking View Existing Details. If you choose to delete the existing responses or if the previous owner of the app didn’t disclose what data the app collects and how it may be used, complete the App privacy section before submitting a new app version.
See Accept an app transfer, step 6; accessed October 3, 2026
Google Play states that after an app transfers, all ad SDK integrations in the app's APK files need updating so ad traffic is credited to the correct account.
Ad SDK integrations (including AdMob): Once your apps have been transferred to your target account, to make sure ad traffic is credited to the correct account, all ad SDK integrations will need to be updated in your apps' APK files.
See Additional requirements for select apps; accessed October 3, 2026
Apple states that keychain sharing in a transferred app keeps working only until the app is updated.
Keychain sharing continues to work only until the app is updated. Therefore, you must rebuild the keychain when submitting updates.
See Apps using keychain sharing; accessed October 3, 2026
The Jeffs Brands agreement required the seller to maintain the asset as it was leading up to the sale and to take no actions outside normal business practices through the migration.
(a) Seller agrees to maintain the Asset, as it was leading up to sale, through the Completed Migration to the best of its ability. This includes, but is not limited to, maintaining third party links on its website and other websites and any marketing, advertising, or other referral source, if applicable. Seller shall take no active action to remove any third-party links; (b) Seller agrees to maintain accurate and up-to-date Asset records that it compiles throughout its normal course of business through the Completed Migration, and deliver any and all Asset records to Buyer prior to the Completed Migration; and, (c) Seller agrees not to take any actions in relation to the Asset outside of normal business practices throughout the Migration Process.
See ¶13(a)–(c)
What should the inventory of keys, secrets and services list, and when are keys replaced?
The inventory can list each key, secret and connected service with where it lives and who controls it, and credentials the seller can still reach can be replaced once the transfer completes, as Apple requires for an app's shared secret.
GitHub keeps webhooks, services, secrets and deploy keys associated with a transferred repository. Apple also transfers configured app webhooks unless the transferor deletes them first.
Apple Pay transactions continue while the original certificates remain valid, but the recipient needs a new merchant identifier for the first update. Apple's push-notification certificates remain valid until expiry, after which the recipient team must generate a new certificate.
For auto-renewable subscriptions, Apple requires the recipient to obtain the existing app-specific shared secret before acceptance and generate a new one after transfer so outsiders no longer have access. Google Play suggests that both owners consider the security of the upload and app-signing keys when transferring an app using Play App Signing.
Removing a person from a GitHub organization does not prevent repository access through a deploy key whose private key that person still holds. Amazon Web Services does not automatically delete an access role created for the old organization's management account when a member account leaves. Consequently, transfer and membership removal alone do not establish exclusive buyer control over retained credentials and access roles.
Sources for this answer
GitHub states that a transferred repository keeps its issues, pull requests, wiki, stars and watchers, and that its webhooks, services, secrets and deploy keys remain associated after the transfer.
When you transfer a repository, its issues, pull requests, wiki, stars, and watchers are also transferred. If the transferred repository contains webhooks, services, secrets, or deploy keys, they will remain associated after the transfer is complete.
See What's transferred with a repository?; accessed October 3, 2026
Apple states that an Apple Pay merchant ID does not transfer with an app, that transactions keep working while the original certificates are valid, and that the recipient needs a new merchant ID for its first update.
If you transfer an app that uses Apple Pay, the merchant ID isn't transferred along with the app. Transactions continue to be successful as long as the original certificates are valid. However, when you submit an update, a new merchant ID must be created on the recipient’s account.
See Apps using Apple Pay; accessed October 3, 2026
Apple states that webhooks configured for an app transfer to the recipient unless the transferor deletes them first.
If you have webhooks configured for your app, they will transfer to the recipient. If you don’t want webhook events delivered to your web server after the transfer, delete the webhooks before you transfer the app.
See Apps using webhooks; accessed October 3, 2026
Apple states that push-notification certificates remain valid until they expire, after which the recipient team must generate a new certificate to keep signing pushes.
The recipients APNs certificates remain valid until their expiration date. After that, the recipient team must generate a new APNs certificate to continue signing pushes.
See Apps using push notifications; accessed October 3, 2026
Apple requires the recipient of an app with auto-renewable subscriptions to obtain the app-specific shared secret before accepting and to generate a new one once the transfer is complete.
Before you accept an app transfer for an app that offers auto-renewable subscriptions, obtain the app-specific shared secret from the initiator, so that you can update your servers to use the code to verify auto-renewable subscriptions. Once the app transfer is complete, generate an app-specific shared secret so that users outside of your organization no longer have access to it.
See Apps using auto-renewable subscriptions; accessed October 3, 2026
Google Play suggests that both the original owner and the target account consider the security of the upload key and the app signing key when an app using Play App Signing transfers.
For apps using Play App Signing, both the original owner and target account may wish to consider the security of both the upload key and the app signing key.
See Additional requirements for select apps; accessed October 3, 2026
GitHub warns that anyone with the private key for a repository's deploy key can read from or write to the repository even after being removed from the organization.
When someone adds a deploy key to a repository, any user who has the private key can read from or write to the repository (depending on the key settings), even if they're later removed from the organization.
See Warning; accessed October 3, 2026
AWS states that an IAM role created for access by the management account is not automatically deleted when a member account is removed.
When you remove a member account from the organization, any IAM role that was created to enable access by the organization's management account isn't automatically deleted.
See Considerations; accessed October 3, 2026
How should the escrow inspection period line up with the handover checklist?
The agreed inspection period needs enough time for the planned handover checks because the parties fix it when the Escrow.com transaction starts and Escrow.com permits extensions only at its discretion.
Escrow.com's periods run from 1 to 30 calendar days and should allow adequate time for required authentication or appraisal. The clock starts when the buyer marks receipt or Escrow.com verifies or receives confirmation of delivery, so an early receipt acknowledgment can start inspection before other checks are finished.
Platform processing can consume part of that time: Apple states that an accepted transfer can take up to two business days to complete. Google Play states that its support team reviews and replies to transfer requests within two business days, following the target developer's review and approval.
One filed marketplace-brokered agreement instead measured its fourteen-day inspection period from completed migration. That agreement allowed the buyer to request termination only for a substantial deviation, defined as inspection-period revenue below half the prorated average monthly revenue.
Escrow.com releases funds to the seller if the buyer takes no action before inspection ends. A jointly requested extension remains discretionary, and changes to transaction instructions require every party, including Escrow.com, which reserves the right to reject them.
Sources for this answer
Escrow.com's support guidance states that inspection periods run from 1 to 30 calendar days, are agreed at the start of the transaction, and should leave enough time for any authentication or appraisal.
Inspection Periods are 1 - 30 calendar days and must be agreed upon by all parties at the initiation of the transaction. Buyers and Sellers should ascertain the Inspection Period provides adequate time for any authentication and/or appraisal process required to complete the transaction.
See How long is the Inspection Period?; accessed October 3, 2026
Escrow.com's General Escrow Instructions let Escrow.com, at its discretion, extend an inspection period the parties jointly want extended, and otherwise do not allow the inspection periods to be modified.
Should the Escrow.com site or our services be unavailable, or if Buyer and Seller (and Broker when applicable) jointly desire to extend the Buyer Inspection Period or the Seller Inspection Period, then Escrow.com may, but shall not be obligated to, extend such times as set forth in the Transaction Escrow Instructions at Escrow.com’s sole and absolute discretion, and Escrow.com will provide prompt email notification of any extension to all parties. With the exception of Escrow.com extensions, the Buyer Inspection Period and the Seller Inspection Period as set forth in these Instructions and the Transaction Escrow Instructions shall not be modified.
See § 12; accessed October 3, 2026
Escrow.com's support guidance states that the inspection period begins when the buyer marks the item received or when Escrow.com verifies or receives confirmation of delivery.
The Inspection Period begins when the Buyer marks the merchandise or service as “Received” or when Escrow.com verifies or receives confirmation that the merchandise, domain, or service has been delivered.
See Start of Inspection Period; accessed October 3, 2026
Apple states that an accepted app transfer can take up to two business days to complete, during which the app status is Processing App Transfer.
It can take up to two business days for the app transfer to complete, during which the app status is Processing App Transfer.
See Accept an app transfer; accessed October 3, 2026
Google Play states that a transfer request goes to the target developer for review and approval and that its support team replies to transfer requests within two business days.
This request will then be received by the target developer for review and approval. Finally, our support team reviews and replies to transfer requests within 2 business days.
See Submit your transfer request; accessed October 3, 2026
The Jeffs Brands agreement gave the buyer fourteen days from the completed migration to inspect the assets, during which the buyer was to operate them as close as possible to the seller's operation.
(8) Inspection Period. Buyer shall have a period of fourteen (14) days from the Completed Migration to fully inspect the Assets (“Inspection Period”) upon the following terms and conditions: (a) During the Inspection Period, Buyer shall operate the Assets in a manner as close as possible to Seller’s operation and shall not make any material changes, including addition of new expenses, without Seller’s prior written consent.
See ¶8
The Jeffs Brands agreement let the buyer request termination during inspection only for a substantial deviation, defined as inspection-period revenue below half of the prorated average monthly revenue.
(b) Buyer may request termination of this Agreement if, consistent with this Agreement, the Buyer believes a Substantial Deviation exists; (c) A “Substantial Deviation” exists when the Inspection Period Revenue is less than fifty percent (50%) of the prorated Average Monthly Revenue. If the Inspection Period Revenue is fifty percent (50%) or more of the prorated Average Monthly Revenue, Buyer shall have no right to request to terminate this Agreement;
See ¶8(b)–(c)
Escrow.com's support guidance states that if the buyer takes no action within the inspection period, Escrow.com releases the funds to the seller when the period ends.
If the Buyer does not take any action within the Inspection Period, at the end of the agreed-upon Inspection Period, Escrow.com will release the funds to the Seller.
See End of Inspection Period; accessed October 3, 2026
Escrow.com's General Escrow Instructions require every party, including Escrow.com, to execute any change to the agreed transaction terms, and reserve Escrow.com's right to reject such a change.
Should it become necessary to add a supplemental instruction(s), or to make any addition to, deletion from, or alteration to the Transaction Detail Screens, all parties (Buyer, Seller, Escrow.com and Broker when applicable) must execute (by digital signature or by a method mutually agreed upon by both parties) any supplemental instruction, addition, deletion or alteration thereto (collectively the "Supplemental Escrow Instruction(s)). Escrow.com reserves the right to reject any Supplemental Escrow Instructions and to terminate the Transaction as provided herein.
See § 1; accessed October 3, 2026
What must be ready before an Apple app can transfer?
An Apple app transfer in App Store Connect requires the recipient Account Holder's Apple Account and the recipient account's Team ID, so the buyer's developer account has to exist before the transfer can be requested.
Account enrollment and any organization verification belong early in the closing plan rather than at the moment of transfer, because an organization enrolling in Apple's developer program needs an Apple Account with two-factor authentication turned on, and, unless it is a government entity, a D-U-N-S Number that Apple uses to verify the organization's identity, legal entity status and address.
Apple's transfer criteria then apply to both accounts and to the app; neither account can be in a pending or changing state, and both parties must have accepted the latest paid and free agreements; the app must also have at least one version released to the App Store. An app that is currently available for pre-order cannot be transferred, so a pre-order or a pending membership change is a concrete closing dependency, not a reason to exchange account passwords.
The recipient's acceptance and then the completed transfer are the evidence to record: after the transfer is initiated the app keeps a Pending App Transfer status until the recipient accepts it or the request expires after 60 days, and an accepted transfer can take up to two business days to complete. The app leaves the transferor's account on transfer, so Apple advises the transferor to back up all information about the app first.
The seller's side of each transfer, including the App Store steps, is in Selling an App Business.
Sources for this answer
Apple's transfer steps require the transferor to enter the recipient Account Holder's Apple Account and the account's Team ID before continuing an app transfer request.
Enter the Apple Account for the recipient’s Account Holder and Team ID for the account, and click Continue.
See Transfer steps, step 5; accessed September 16, 2026
Apple requires an organization enrolling in the Apple Developer Program to use an Apple Account with two-factor authentication turned on.
If you’re enrolling your organization, you’ll need an Apple Account with two-factor authentication turned on.
See Enrolling your organization; accessed September 29, 2026
Apple requires an enrolling organization other than a government entity to have a D-U-N-S Number so Apple can verify its identity, legal entity status and address.
Your organization (excluding government entities) must have a D-U-N-S Number so that we can verify your organization’s identity, legal entity status, and address.
See Enrolling your organization, D-U-N-S Number; accessed September 29, 2026
Apple requires that neither account in an app transfer be in a pending or changing state and that both parties have accepted the latest paid and free agreements.
Before initiating an app transfer, ensure that both the transferor's and recipient's accounts are not in a pending or changing state. Additionally, both parties must have accepted the latest version of their paid and free agreements.
See Account criteria; accessed September 29, 2026
Apple requires a transferable app to have at least one version released to the App Store.
The app must have at least one version that was released to the App Store.
See App criteria; accessed September 29, 2026
Apple requires that a transferable app not currently be available for pre-order in any country or region.
The app can’t currently be available for pre-order in any countries or regions.
See App criteria; accessed September 29, 2026
Apple states that an initiated app transfer stays pending until the recipient accepts it or it expires after 60 days.
After you initiate the transfer, the app stays in its previous status, with the Pending App Transfer status added, until the recipient accepts it or the transfer expires after 60 days.
See Initiate an app transfer; accessed September 30, 2026
Apple advises the transferor to back up all information about the app because the app is removed from its account after transfer.
Because an app is removed from your account after an app transfer, you should back up all information about the app for your records.
See Note; accessed September 30, 2026
Apple states that an accepted app transfer can take up to two business days to complete, during which the app status is Processing App Transfer.
It can take up to two business days for the app transfer to complete, during which the app status is Processing App Transfer.
See Accept an app transfer; accessed October 3, 2026
How is the domain name transferred at closing?
A domain transfer at closing can be constrained by ICANN's transfer rules, including the general rule that a domain cannot move to a new registrar within 60 days after a change to the registrant's contact information, although some registrars may offer an opt-out, which ICANN says registrars need not provide.
The asset schedule lists each domain by exact name, registered holder, registrar and expiry date, because each registration is a contract between the registrant and a particular registrar and, for a generic top-level domain such as .com, the registrar sends its expiration notices to the registered name holder.
The handover plan can say whether the closing needs a change of registrant, a transfer between registrars or both, because ICANN's transfer rules address a transfer from one registrar to another and a transfer from one registrant to another as separate moves. Only the registered name holder, the administrative contact or a person expressly authorized by either of them can start a transfer, and a transfer between registrars requires an authorization code, also called an AuthInfo or transfer code. For a move between registrars, the process starts with the registrar that will receive the name, which must confirm the registrant's intent on ICANN's standardized form. Because registrants manage their domain settings through their registrar, the plan can also record evidence that the buyer controls the registrar account, including renewal and account recovery.
Registrar administration and hosting are separate steps; in a hosting move, traffic moves when the domain's DNS settings are changed to point to the new hosting infrastructure. Completion is recorded against the scheduled domain in the buyer's registrar account rather than inferred from the public website staying online, because the registration is maintained under the registrant's contract with its registrar.
Sources for this answer
ICANN explains that a domain generally cannot move to a new registrar within 60 days after a contact-information change, that registrars may but need not offer an opt-out, and that registrants should ask their registrar.
The first rule is that you generally cannot transfer a domain name to a new registrar within 60 days of making a change to your contact information. While some registrars may provide an option to opt-out of this 60-day “lock period” this rule is in place for your protection (to prevent unauthorized transfers) and the registrar does not have to offer this option. Contact your registrar to find out if they offer this option.
See Item 1; accessed September 16, 2026
ICANN states that a registrant enters into a contract with a registrar when a domain name is registered.
Upon registration of a domain name, a registrant enters into a contract with a registrar.
See What is a Registrant?; accessed September 29, 2026
ICANN's Expired Registration Recovery Policy requires registrars to notify the registered name holder of a gTLD registration's expiration at least twice before it expires.
Prior to the expiration of any gTLD registration, registrars must notify the registered name holder of the expiration at least two times.
See § 2.1.1; accessed September 29, 2026
ICANN's registrant guidance addresses transfers from one registrar to another and from one registrant to another.
There are 2 important rules you should be aware of regarding whether and when a domain name can be transferred from one registrar to another and/or from one registrant to another.
See Item 1; accessed September 30, 2026
ICANN states that only the registered name holder, the administrative contact or a person explicitly authorized by either can initiate a transfer.
The second rule is that you can only initiate the transfer process if you are the registered name holder, administrative contact, or an individual explicitly authorized to act on behalf of either of those contacts.
See Item 1; accessed September 30, 2026
ICANN states that a transfer between registrars requires an AuthInfo code, also called an authorization or transfer code.
You’ll need something called the AuthInfo code (also called an Authorization Code, AuthInfo code, Auth-Info Code, or transfer code) to make the transfer.
See Item 4; accessed September 30, 2026
ICANN states that a transfer between registrars starts with the registrar that will receive the name, which must confirm the registrant's intent using the Standardized Form for Gaining Registrars.
To initiate the process to transfer your domain name from one ICANN-accredited registrar to another, you should first contact the registrar to which you wish to transfer the name. After you contact that registrar, it is required to confirm your intent to transfer your domain name using the Standardized Form for Gaining Registrars.
See Item 2; accessed September 30, 2026
ICANN states that registrants manage their domain name settings through their registrar after registration.
After registration, registrants manage their domain name settings through their registrar.
See What is a Registrant?; accessed September 30, 2026
ICANN states that the registrant's contract describes the terms on which the registrar registers and maintains the name.
The contract describes the terms under which the registrar agrees to register and maintain the requested name.
See What is a Registrant?; accessed September 30, 2026
Google describes changing the domain's DNS settings to point to the new hosting as the step that starts sending traffic to the new infrastructure.
Change the DNS settings of your domain name to point to the new hosting infrastructure. This step is the actual site move step that starts the process of sending your traffic to the new infrastructure.
See Overview; accessed September 29, 2026
In what order should control of the app's accounts move at closing?
The buyer's receiving accounts can be set up before any transfer and the seller's leftover access removed after it, because Google Play needs both accounts active before a transfer and GitHub keeps the old owner on as a collaborator afterward.
Google Play requires both developer accounts to be registered and active before a transfer request is submitted. Vercel requires a valid payment method on the receiving team before project transfer to avoid service interruption.
For a business sale, Stripe directs the existing owner to contact Stripe Support first to confirm the information that needs updating. Where the new owner is a new individual rather than an existing user, Stripe's process adds that person as a Super Administrator and transfers ownership after the invitation is accepted.
For a domain transaction, Escrow.com's instructions require the seller to provide the username, password or authorization code needed for access before funds are released, and the domain transfer question covers the registrar steps.
After a GitHub repository transfer, the original owner becomes a collaborator and existing collaborators remain. Removing a collaborator does not remove that person's local clones, and GitHub assigns the repository owner responsibility for ensuring former users delete confidential information or intellectual property.
Sources for this answer
Google Play requires both the original and the target developer accounts to be registered and active before a transfer request can be submitted.
Before you can submit a transfer request from your original account to a different account (known as your target account), both Google Play developer accounts need to be registered and active.
See Get your app ready to transfer; accessed October 3, 2026
GitHub states that the original owner of a transferred repository is added as a collaborator and that other collaborators remain.
The original owner of the repository is added as a collaborator on the transferred repository. Other collaborators to the transferred repository remain intact.
See Prerequisites for repository transfers; accessed October 3, 2026
Vercel requires a valid payment method on the target team before a project is transferred to it.
If the target Vercel team does not have a valid payment method, you must add one before transferring your project to avoid any interruption in service.
See Transfer steps; accessed October 3, 2026
Stripe tells an account owner transferring the account because of a business sale to contact Stripe Support first to confirm which information needs updating.
If you are the existing owner of a Stripe account and you want to transfer ownership of your account to someone else, such as in the case of selling your business or having been acquired, you will first need to reach out to Stripe Support to confirm which information updates need to be made.
See Support article; accessed October 3, 2026
Stripe's steps for transferring ownership to a new individual have the owner add the new user as a Super Administrator and, once the invitation is accepted, select Transfer ownership.
Transfer to a new individual Go to Team settings on the Dashboard . Click +New Member. Add the new user’s email address and set their role to Super Administrator. Click Save to send them an invitation to join the account. After the new user has accepted the invite, go back to Team settings. Click the overflow menu next to their name. From the popup, select Transfer ownership and follow the instructions.
See Transfer to a new individual; accessed October 3, 2026
Escrow.com's General Escrow Instructions require a seller of a domain name to give the buyer the username, password or authorization code needed to access the domain before funds are released.
Seller agrees to provide the username and password and/or authorization code, if any, necessary to access the Domain Name to Buyer prior to the release of funds.
See § 2; accessed October 3, 2026
GitHub states that the repository owner is responsible for ensuring that people who lose access delete confidential information and that a removed collaborator keeps any local clones.
You are responsible for ensuring that people who have lost access to a repository delete any confidential information or intellectual property. While forks of private repositories are deleted when a collaborator is removed, the person will still retain any local clones of your repository.
See Warning; accessed October 3, 2026
How and when do the business's online accounts migrate around closing?
The steps and timing of an account migration depend on each provider's transfer process and on which accounts the agreement requires to move before or after closing, as Vercel's rule that a project's transferor be an owner of the sending team and a member of the receiving team shows.
Provider rules can require the receiving account to be ready before a transfer starts; Vercel requires the receiving team to have a valid payment method before a project is transferred, and a GitHub repository transfer to another personal account lapses if the new owner does not accept it within one day.
Not every account has to move before closing; a purchase agreement can let some assets keep transferring after a defined migration milestone, as one filed purchase agreement expressly anticipated. Later deliveries can be made enforceable obligations of their own; the same agreement made either party's failure to complete the Migration Process a material breach. It also tied payment to the handover, releasing 92 percent of the price to the seller after its inspection period expired, with the broker retaining 8 percent as a portion of its commission.
Provider-specific prerequisites are covered under Apple apps, website and app projects and shared accounts.
Sources for this answer
Vercel requires the person transferring a project to be an owner of the team it leaves and a member of the team it joins.
You must be an owner of the team you're transferring from, and a member of the team you're transferring to.
See Transferring a project; accessed September 29, 2026
Vercel requires a valid payment method on the target team before a project is transferred to it.
If the target Vercel team does not have a valid payment method, you must add one before transferring your project to avoid any interruption in service.
See Transfer steps; accessed September 29, 2026
GitHub states that a repository transfer invitation to another personal account expires if the new owner does not accept it within one day.
If the new owner doesn't accept the transfer within one day, the invitation will expire.
See Prerequisites for repository transfers; accessed September 29, 2026
The Jeffs Brands agreement supports distinguishing its defined migration milestone from delivery of remaining assets.
It is possible that some portion of the Assets will continue to be transferred to Buyer after the Completed Migration.
See Migration Process, paragraph (b)
The Jeffs Brands agreement made either party's failure to complete the migration process a material breach.
(d) Either Party’s failure to complete the Migration Process after execution of this Agreement is a material breach of the Agreement; and, (e) The Parties agree to provide Broker all necessary information upon request to facilitate the Migration Process.
See Migration Process, paragraph (d)
The Jeffs Brands agreement had the broker release the purchase price, less the broker's retained commission, after the inspection period expired.
Within a commercially reasonable time after expiration of the Inspection Period, Broker will release ninety-two percent (92%) of the Purchase Price to Seller and Broker will retain the remaining eight percent (8%) as a portion of its Commission.
See Release of the Purchase Price, ¶9(a)
How should a website or app project migration be planned so the service keeps running?
A website or app migration plan can identify the actual hosting platform and include tests of the resulting service, because a platform's project transfer may leave work undone, as when Vercel requires a project's integrations to be added again after the transfer.
Before the switch, Google suggests uploading a copy of the site to the new host and testing all aspects of how users interact with it, which for an online business can include an ordinary customer journey, a payment or subscription test, required notifications, deployment access and recovery access.
For a hosting move that keeps the same web address, Google suggests lowering DNS time-to-live values at least a week before the move so the change propagates faster and shutting down the old hosting only once no one, including Google's crawler, is still using it. A closing plan that ends the seller's hosting on the closing date can conflict with that sequence, because Google's guide waits for traffic to the old provider to reach zero before shutdown, so the agreement can keep the old hosting available for a short, defined period after the switch.
Repository and domain settings move on their own terms; for a GitHub Pages site published from a private repository with a custom domain, GitHub suggests removing or updating the domain's DNS records before transferring the repository to avoid the risk of a domain takeover. The domain transfer is scheduled separately from the hosting move.
A project can also move through its provider's own transfer route, which carries the original project rather than a copy: Vercel, for example, transfers a project between teams with zero downtime and moves or copies the project's dependencies to the receiving team, a transferred GitHub repository keeps its issues and pull requests and stays associated with its secrets and deploy keys, and a Google Cloud project migration is not a data transfer, and the project's services and databases stay active without downtime. The closing record can show which route each project took, and the result is tested as described above.
Sources for this answer
Vercel states that integrations associated with a project must be added again after a project transfer is complete.
Integrations: Those associated with your project must be added again after the transfer is complete.
See What is not transferred? Integrations; accessed September 16, 2026
Google suggests lowering DNS TTL values at least a week before a hosting move so DNS caches refresh faster.
Consider lowering the TTL to a conservative low value (for example, a few hours) at least a week in advance of the move to refresh DNS caches faster.
See Lower the TTL value for your DNS records; accessed September 29, 2026
Google advises shutting down the old hosting only when all users, including Googlebot, are served by the new infrastructure and no one uses the old one.
Shut down the old hosting infrastructure when you're confident that all users, including Googlebot, are receiving content correctly from the new infrastructure and no one is using the old infrastructure.
See Overview; accessed September 29, 2026
GitHub suggests removing or updating DNS records for a private repository's GitHub Pages custom domain before transfer to avoid a domain takeover.
If you published a GitHub Pages site in a private repository and added a custom domain, before transferring the repository, you may want to remove or update your DNS records to avoid the risk of a domain takeover.
See Transferring a repository owned by your personal account; accessed September 29, 2026
Google suggests uploading a copy of the site to the new hosting provider and verifying it by thoroughly testing all aspects of how users interact with the site.
First, upload a copy of your site to your new hosting provider. What a "copy of your website" means depends entirely on your old content management platform; it may be actual HTML files that you replicate on your new hosting platform, or a database export that you have to import in the new location. Once you do that, verify that it works as expected by thoroughly testing all aspects of how your users interact with your site.
See Copy and test your new site; accessed September 29, 2026
Google's guide shuts down the old hosting once traffic to the old provider reaches zero.
Check the server logs on the old provider and, once the traffic to the old provider reaches zero, you can shut down your old hosting infrastructure.
See Shut down old hosting; accessed September 29, 2026
Vercel states that projects can be transferred between its teams with zero downtime and that the project's dependencies are moved or copied to the new team.
You can transfer projects between your Vercel teams with zero downtime and no workflow interruptions. You must be an owner of the team you're transferring from, and a member of the team you're transferring to. For example, you can transfer a project from your Hobby team to a Pro team, and vice versa if you're an owner on the Pro team. During the transfer, all of the project's dependencies will be moved or copied over to the new Vercel team namespace.
See Transferring a project; accessed October 3, 2026
GitHub states that a transferred repository keeps its issues, pull requests, wiki, stars and watchers, and that its webhooks, services, secrets and deploy keys remain associated after the transfer.
When you transfer a repository, its issues, pull requests, wiki, stars, and watchers are also transferred. If the transferred repository contains webhooks, services, secrets, or deploy keys, they will remain associated after the transfer is complete.
See What's transferred with a repository?; accessed October 3, 2026
Google Cloud states that a project migration is not a data transfer and that the project's services, databases and VM instances stay active without downtime.
A project migration is not a data transfer. Your services, databases, and virtual machine (VM) instances remain active and don't experience downtime.
See How migration works; accessed October 3, 2026