Step‑by‑Step Guide to Transfer Ownership and Preserve Settings for a Google Apps Script Project

When a teammate leaves, a client takes over, or you sell a solution, the biggest worry is losing the automation that powers your business. The direct answer is: transfer the Drive file ownership, update the web‑app deployment, copy or re‑authorize all triggers, and hand over a concise configuration document. Follow the steps below to keep the script running without interruption.

Prerequisites Before You Start

• Both the current owner and the new owner must have a Google Workspace or Gmail account.
• The script is saved as a .gs project in Google Drive (either a standalone script or bound to a Sheet).
• You have Editor access to the script and any linked Google Sheets, Docs, or Slides.
• Make a backup copy of the script (File → Make a copy) and of any data sources.
• Know the type of triggers used (time‑driven, on‑edit, on‑form‑submit, etc.).

1. Transfer Ownership of the Script File

Ownership determines who can change deployment settings and who can delete the project. The transfer is done through Google Drive:

1. Open Google Drive and locate the script file (it appears as Google Apps Script).
2. Select the file, click the Share button, and add the new owner’s email with Editor permission if they are not already listed.
3. In the sharing dialog, click the dropdown next to the new user’s name and choose Make owner. Confirm the change.
4. The previous owner will receive an email asking to confirm the transfer. After acceptance, the new owner appears as Owner and the former owner becomes Editor.
5. Verify ownership by opening the script (Extensions → Apps Script) and checking the top‑right corner – it should display the new owner’s name.

If the script is bound to a Google Sheet, repeat the same steps for the Sheet file, because the Sheet’s owner controls the bound script’s access to the spreadsheet.

2. Review and Re‑configure Web App Deployments

A web app deployment creates a public URL that runs the script under a specific user context. Changing ownership does not automatically update the deployment, so you must verify two things:

• Who can access the web app? (Anyone, Anyone with Google account, or Only internal users.)
• Which user’s authority does the script run under? (Me – the owner, or the user who accesses the URL.)

Steps to adjust the deployment:

1. In the Apps Script editor, click Deploy → Manage deployments.
2. Select the active deployment and click the three‑dot menu → Edit.
3. Under Execute as, confirm that “Me (owner)” is still selected if the script needs to access data the new owner controls.
4. Under Who has access, choose the appropriate option. If you change from “Anyone” to a more restricted setting, inform any external users of the new URL (the URL stays the same).
5. Save changes. The deployment version number increments, but the URL remains unchanged, preserving any integrations that rely on it.

If you prefer to create a fresh deployment for the new owner, click New deployment, set the same options, and copy the new URL to all places where the old URL was used.

3. Manage Triggers and Permissions

Triggers run the script automatically. They are tied to the user who created them, not to the script file. After a transfer, existing triggers will continue to run under the former owner’s account, which can cause permission errors.

Identify Existing Triggers

1. Open the script editor and choose Triggers (clock icon on the left).
2. Make a list of each trigger: type (time‑driven, on‑edit, on‑form‑submit), function name, and schedule.

Re‑create Triggers Under the New Owner

1. Log out of the old owner’s account and sign in as the new owner.
2. Open the same script (now owned by the new user) and go to Triggers again.
3. Click Add Trigger for each entry you recorded, matching the original settings.
4. When the trigger is saved, Google will prompt the new owner to authorize the required scopes (e.g., read/write Sheets, send email). Complete the authorization.

Delete the Old Owner’s Triggers

While still signed in as the old owner, return to the Triggers page and delete any remaining entries. This prevents duplicate runs and eliminates unnecessary quota usage.

4. Capture Configuration, Logs, and Documentation

Handing over a script is more than moving files – it’s about preserving knowledge.

• Export the manifest (appsscript.json). In the editor, click View → Show manifest file. Copy its content into a text file and share it with the new owner.
• Download execution logs. Open Executions (left‑hand menu) and export recent logs as CSV for reference.
• Create a short README. Include:
  • Project purpose and key workflows.
  • List of required Google services (Sheets, Gmail, Drive, etc.).
  • Credentials or API keys used (if any) and where they are stored.
  • Contact information for the original developer for future questions.

5. Handover Checklist

• ✅ Verify both parties have Google accounts.
• ✅ Make a backup copy of the script and all linked files.
• ✅ Transfer Drive ownership of the script (and bound Sheet, if applicable).
• ✅ Review web‑app deployment settings – execute as, access level, URL.
• ✅ List all existing triggers.
• ✅ Re‑create triggers under the new owner’s account.
• ✅ Delete the old owner’s triggers.
• ✅ Export appsscript.json and recent execution logs.
• ✅ Write a concise README with purpose, services, and credentials.
• ✅ Test the web app and scheduled triggers with the new owner’s account.
• ✅ Communicate any external users about possible URL changes.

Realistic Example: Sales‑Order Automation Script

Acme Co. built a script that pulls new rows from a Google Form‑linked Sheet, creates an invoice PDF, emails the customer, and logs the transaction in a second Sheet. The original developer, Ahmed, is leaving the company and needs to hand the project to Sara.

Using the steps above, Sara:

1. Receives edit access to the three Sheets and the script.
2. Ahmed makes Sara the owner of the script file and the three Sheets.
3. Sara opens the script, checks the single web‑app deployment, confirms it runs as “Me (owner)”, and leaves the access setting as “Anyone with the link”.
4. She records two time‑driven triggers (run at 9 am and 5 pm) and one on‑form‑submit trigger.
5. Signed in as Sara, she recreates the three triggers, authorizes the required scopes, and then Ahmed deletes his copies.
6. Sara exports the manifest, saves the last 30 days of execution logs, and writes a README that notes the PDF template lives in a shared Drive folder.
7. She runs a test order; the invoice is generated, emailed, and the log updates without error.

The handover is complete, and Acme Co. can continue processing orders without a service interruption.

Common Mistakes and How to Fix Them

• Skipping trigger recreation. Result: scheduled jobs stop, leading to missed orders. Fix by following the trigger section carefully.
• Leaving the web‑app set to run as the old owner. Result: the script loses access to the new owner’s Drive files. Change the “Execute as” option to the new owner.
• Forgetting to share linked files. Result: script throws “Permission denied” errors. Ensure every Sheet, Doc, or Drive folder used by the script is also transferred.
• Not updating external URLs. Result: partners still call an old URL that may be disabled later. Communicate any new deployment URLs promptly.

FAQs

Do I need a Google Workspace account to own a script?

No. A regular Gmail account can own and run Apps Script projects, but some advanced services (e.g., domain‑wide delegation) require Workspace.

Can I transfer ownership of a script that is part of a Google Workspace Add‑on?

Add‑ons are published under a developer account. Ownership transfer is not applicable; you would need to publish a new version under the new developer’s account.

What happens to the script’s quota after transfer?

Quotas are tied to the user who executes the script. After you change the “Execute as” setting, the new owner’s daily quota applies.

Next Steps

Once the handover checklist is complete, monitor the script for a few days to ensure no hidden permission errors appear. If you encounter unexpected failures, review the execution logs and verify that all linked resources belong to the new owner.

Need a ready‑made automation to start with? View the Apps Script ecommerce source‑code package. Have a custom workflow in mind? Ask about deployment or custom workflow support.