> You are reading the Docusign Developer Documentation. For clean Markdown of any page, append .md to the page URL.
>
> Documentation indexes by section:
> - APIs and SDKs: https://docusign.docs.buildwithfern.com/docs/llms.txt
> - Platform 101: https://docusign.docs.buildwithfern.com/platform/llms.txt
> - Extension Apps: https://docusign.docs.buildwithfern.com/extension-apps/llms.txt
> - Docusign CLI: https://docusign.docs.buildwithfern.com/docusign-cli/llms.txt
>
> Authentication (OAuth, JWT Grant, M2M): https://docusign.docs.buildwithfern.com/platform/auth
> Webhooks and Connect: https://docusign.docs.buildwithfern.com/platform/webhooks
>
> OpenAPI specifications: https://docusign.docs.buildwithfern.com/openapi.json
> MCP server: https://docusign.docs.buildwithfern.com/_mcp/server

# Deploy agreement customizations

> Learn how to deploy your validated Agreement Manager customizations to a production account using the Docusign CLI. Covers common deployment scenarios and step-by-step instructions.

After you have [configured](/docusign-cli/configure-agreement-types-and-fields/create-package) and [tested](/docusign-cli/test-agreement-customizations) your Agreement Manager customizations in the developer environment, you can deploy them to a production account to make them available to your organization. Deploying to production applies your validated package, including custom fields, custom agreement types, and field mappings, to Agreement Manager in the target account.

This page describes the common deployment scenarios and the steps required to deploy a package to production.

> **Note**
>
> After you deploy an updated package to an environment where agreements have already been ingested, you must  [reprocess](/docusign-cli/reprocess-agreements) to apply the configuration changes to previously ingested agreements. A reprocess updates agreement type classifications and extracted field data to reflect the definitions in the newly deployed package.

For a walkthrough of the deployment process, see this video:

## Deployment scenarios

The steps required to deploy your customizations depend on your situation. The following scenarios are the most common.

#### First-time deployment of Agreement Manager customizations to production

This scenario is an initial deployment of Agreement Manager customizations to a production account. The typical workflow involves configuring and testing your customizations in the developer environment, then authenticating to the production account and uploading the validated package.

See [Use case 1: First-time customization](/docusign-cli/use-cases#use-case-1-first-time-customization) for the full sequence of steps, including installation, configuration, testing, and production deployment.

#### Modify existing Agreement Manager customizations in production

In this scenario, you update an existing Agreement Manager configuration in production to add new custom fields, introduce new agreement types, update AI extraction descriptions, or extend existing field mappings. The recommended approach is to retrieve the current production configuration, make your changes locally, validate them in the developer environment, deploy the updated package back to production, and reprocess on production to apply the configuration updates to previously ingested agreements.

This workflow ensures that changes are fully validated before affecting live agreements. See [Use case 2: Bulk modify a production configuration](/docusign-cli/use-cases#use-case-2-bulk-modify-a-production-configuration) for the full sequence of steps.

#### Copy Agreement Manager customizations from one production account to another

This scenario replicates an existing Agreement Manager configuration from one production account to another. This is useful for deploying a proven configuration to additional accounts for other customers or business units. Because the configuration has already been validated, no additional testing is required in most cases.

You retrieve the configuration from the source account, then authenticate to the target account and upload the package directly. If agreements have already been ingested in the target account, initiate a reprocess to apply the customizations to existing agreements. See [Use case 3: Move a configuration between accounts](/docusign-cli/use-cases#use-case-3-move-a-configuration-between-accounts) for the full sequence of steps.

## Deployment prerequisites

Before deploying to production, make sure that the following prerequisites are met:

* You have a Docusign production account with the permissions required to configure Agreement Manager.
* Your Agreement Manager package has been tested in the developer environment and the AI extraction accuracy meets your requirements. See [Test agreement customizations](/docusign-cli/test-agreement-customizations) for details.
* Your workspace contains the validated `agreement-manager-manifest.json` file and any required training documents at `{workspaceName}/{projectName}/agreement-manager/files/train/`. See [Create a package](/docusign-cli/configure-agreement-types-and-fields/create-package) for details about these components.

## Deploy a tested package to production

Use the following procedure to deploy your Agreement Manager package to a production account.

1. **Authenticate to the production account.** Run the following command to connect the CLI to your production Agreement Manager account: \
   `$ ds auth login -e production` \
   Complete the browser-based login flow when prompted. See [Authenticate](/docusign-cli/authenticate) for details on the command options.
2. **Upload the package to production.** Run the `upload` command to deploy your Agreement Manager package to the production account: \
   `$ ds agm upload` \
   After the upload, your custom fields, custom agreement types, and field mappings are created or updated in the production account, and AI extraction is enabled for any types and fields where `customExtractionEnabled` is set to `true` in the manifest. See [Upload a package](/docusign-cli/configure-agreement-types-and-fields/upload-package) for details on what happens after the upload and how to resolve validation errors.
3. **Verify the deployment.** Run the `get catalog` command to confirm that your fields, agreement types, and mappings were created successfully in the production account: \
   `$ ds agm get catalog` \
   Review the generated `custom-catalog.json` file to confirm that all expected custom fields and agreement types are present with the correct configuration. See [Retrieve standard and custom catalogs](/docusign-cli/configure-agreement-types-and-fields/retrieve-standard-and-custom-catalogs) for details on the catalog output.
4. **Reprocess previously ingested agreements.** Run the `reprocess` command to apply the latest customizations to existing agreements, reclassifying them and re-extracting data based on updated definitions: \
   `$ ds agm reprocess [options]` \
   See [Reprocess agreements](/docusign-cli/reprocess-agreements) for details about the command options and common reprocessing scenarios.

## Frequently asked questions

### Do I need to retest in production after deploying?

Testing in production is optional but recommended as a sanity check, particularly for first-time deployments. If you choose to run a test in production, follow the same process described in [Test agreement customizations](/docusign-cli/test-agreement-customizations) using a representative set of production agreements.

### What happens if a custom field or agreement type already exists in the production account?

If a custom field or agreement type defined in your manifest already exists in the production account, the CLI updates the existing configuration rather than creating a duplicate. It overwrites properties such as the AI definition, category, extraction settings, and training examples with the values in your manifest.

### Is it safe to run the upload command more than once?

Yes. The `upload` command is safe to run multiple times. If the manifest has not changed since the last upload, the CLI does not make any changes. If updates are present, the CLI applies them to the existing configuration in the production account.

### Can I deploy a package from one production account to multiple accounts?

Yes. To deploy the same package to additional production accounts, [authenticate](/docusign-cli/authenticate) to each target account using `ds auth login -e production` and run `ds agm upload` for each one. After each deployment, run `ds agm get catalog` to verify that the configuration was applied correctly. See [Use case 3: Move a configuration between accounts](/docusign-cli/use-cases#use-case-3-move-a-configuration-between-accounts) for the full account portability workflow.

### Can I remove custom fields or agreement types from a production account using the upload command?

No. Once a custom field or custom agreement type has been created in an account, the CLI cannot remove it. Only additions and updates to existing configurations are supported.

### Does Docusign re-extract data automatically for existing agreements when I deploy an updated configuration?

No. If you deploy an updated package to an environment where agreements have already been ingested, you must [reprocess](/docusign-cli/reprocess-agreements) to update agreement type classifications and re-extract field data based on the definitions in the newly deployed package.

## Next steps

* After deploying your customizations to production, use the [bulk ingestion](/docusign-cli/bulk-ingest-agreements) process to upload large volumes of agreements.
* If you deploy customizations to an environment where agreements have already been ingested, initiate a [reprocess](/docusign-cli/reprocess-agreements) to apply the customizations to existing agreements.
* Explore the [AI tools](/docusign-cli/ai-tools) available to help you build and manage your Agreement Manager configuration more efficiently.