How to export your data from Dropbox Sign before you leave
If a renewal, a price change, a data residency requirement or a plan to self-host Documenso or DocuSeal is pushing you off Dropbox Sign, the first task is getting your signed agreements out. Completed documents and audit trails can be pulled out through documented paths, but drafts, account settings and some templates generally need to be rebuilt by hand in the new platform. Treat the export as a records project, not a single download: it needs an inventory, a file naming scheme, a place to store the files and a sign-off that every agreement you must keep has been captured.
Start by listing every team signature request through the Dropbox Sign API, since that is the only route that reaches the full set rather than what someone happens to open in the web app. Confirm the current endpoints, response fields, file formats (such as merged PDF or ZIP downloads), pagination behavior and rate limits in Dropbox Sign's own API documentation before you schedule the work, because these details change and a large account can take longer to pull than a small one. Record the request ID, signer names, status, completion date and the template used for each item in a manifest, so you can check later that every file arrived and matches its source.
Keep the non-editable audit trail with each completed document as a separate record. Dropbox Sign states that a non-editable audit trail is affixed to every signature request, so download it alongside the signed file and store the two together under the same identifier. Before you delete anything in the old account, ask legal and compliance which retention periods apply, since some categories of record fall outside the federal electronic signature statute and may have their own rules. Then confirm with your records owner that the exported set is complete and readable outside Dropbox Sign.
Which Dropbox Sign data can be exported and how
This table lists each data type to pull before leaving Dropbox Sign, the export method, the format you receive and what to confirm for your plan. Read it as a checklist and check each row against your retention and rate limit terms. The main takeaway is that the audit trail is part of each completed record, so verify it is captured for every request before you rely on any export.
| Data type | Export method | Format | Limits to confirm |
|---|---|---|---|
| Completed signature requests | Download each completed request individually | Merged PDF per request | Per-request download limits and how long completed requests remain available on your plan |
| Bulk download of team requests | Bulk download of team requests as one archive | ZIP archive of completed requests | Whether the archive covers all team requests and any size or count caps |
| Signature request metadata | Listing requests through the API, page by page | API response data you save in your own structure | Pagination behavior, rate limits and the retention window for request records |
| Audit trails | Retain the audit trail for each signature request as part of the record | Non-editable audit trail affixed to each request | Whether the trail is inside the merged PDF or downloadable as a separate file |
| In-progress requests | Export or complete open requests before cancellation or account closure | Depends on the method used for each request | Whether unsigned or partially signed requests can be exported and for how long |
What does not export cleanly and how to work around it
Completed agreements and audit trails are the easy part of a Dropbox Sign exit. The harder items are the configuration around them: templates, roles, branding, integrations and people. Each card below names a gap, the workaround we would use, and what to confirm with Dropbox Sign before you rely on it.
Template layouts and field placement
Templates in Dropbox Sign hold field positions, default values and merge fields that are not part of the signed PDF. A download of completed requests gives you the finished document, not the editable template that produced it. Plan to rebuild each template in the target platform from the original source PDFs, then check field placement against a completed sample from the old account. Confirm with Dropbox Sign whether template definitions can be exported in any form before you decide to rebuild everything by hand.
Recipient roles and routing rules
Signing order, signer role names and conditional routing live in the request or template setup. They are rarely visible in the exported PDF, so a reviewer cannot recover them from the document alone. Record every template's roles, order and any branching in a spreadsheet before you migrate, with one row per role and a column for the target field. Test one routed agreement end to end in the new platform to confirm that the same person signs in the same order.
Branding and email settings
Company logo, sender name, reply-to address, email subject and body text, and custom signing messages are account settings rather than document content. They will not carry across automatically. Capture screenshots and copy of each message template, then configure the sending domain, SMTP credentials and branding in the target platform. Check that signing emails still reach recipients from your domain, since deliverability problems are often found late.
Integrations and API callbacks
Any system that creates signature requests or receives Dropbox Sign callbacks depends on API keys, callback URLs, event handling and embedded signing settings. These belong to your code and infrastructure, so they must be inventoried and rebuilt. Map each callback event your application handles to the equivalent webhook in the target platform, and run both systems in parallel for a short test period. Confirm the current event names and any retry behavior with Dropbox Sign documentation before you cut over.
User accounts and team membership
Team members, their roles, group ownership and shared template access are administered inside the Dropbox Sign account. Exports of agreements do not reliably carry who owned or could see each request, so that history needs to be recorded separately. Export the member list with roles from the admin console, then recreate users, teams and permissions in the target platform. Map any signer who appears in a completed agreement to a person your organization can still identify.
Items not listed as exportable
Some account data, such as usage history, deleted items, in-progress requests, attachments added after signing and certain metadata, may not appear in any documented export. Treat these as unknown until confirmed. Ask Dropbox Sign support in writing which data categories are exportable, in what format and within what window, and keep the answer with your migration file. Where a category cannot be exported, decide whether you need it as a record and archive it while you still have access.
Does an exported agreement keep its legal weight after the move?
An export is only as useful as the evidence it preserves. A PDF of a signed agreement without its audit trail shows what was signed, but not who signed it, when, from where, or whether the document changed afterward. Under the US ESIGN Act, a signature, contract or record relating to a transaction in or affecting interstate or foreign commerce may not be denied legal effect, validity or enforceability solely because it is in electronic form (15 U.S.C. 7001(a)). That principle protects the agreement, but a court or counterparty will still ask you to prove how it was executed. Dropbox Sign states that a non-editable audit trail is affixed to every signature request, so the export should carry that trail with each document rather than as a separate file that can drift from it.
The ESIGN Act also has exceptions. It does not apply to records governed by laws on wills, codicils and testamentary trusts, state family law such as adoption and divorce, most of the Uniform Commercial Code, or court orders and official court documents, among other exceptions (15 U.S.C. 7003). Before you migrate, sort your agreements into those that fall under these categories and those that do not. Records in the excluded categories may need paper originals or a different execution method, regardless of which platform hosts them. Confirm this classification with counsel rather than assuming the export settles it.
For agreements governed by EU law, the signature level matters. The European Commission describes simple, advanced (AdES) and qualified (QES) electronic signatures under eIDAS as distinct levels, and an advanced signature must let the signatory keep control and make later changes detectable. A qualified signature depends on a qualified certificate issued by a qualified trust service provider listed in a national Trusted List. Ask Dropbox Sign which level each EU envelope used, and keep any certificate evidence with its document. Open-source platforms can verify and store signatures, but whether a given level is achieved depends on the certificate and provider you use. Ask legal counsel to review the exported set, and do not delete the source account until counsel has signed off on completeness and on the retention of audit evidence.
The export sequence and how to verify each stage
This sequence moves every completed agreement, its audit trail and its request metadata out of Dropbox Sign into a labeled archive that you can check against an inventory before any cutover. Each stage ends with a verification you can record, so gaps show up before the Dropbox Sign account is closed.
Inventory the account and team
Before you pull anything, record which Dropbox Sign account, team and member accounts hold signature requests, templates and API keys that your systems use. Ask the account owner to confirm the team structure and any shared templates, and note which integrations send requests or receive callbacks. The output is a written inventory listing each account, team, template and integration with an owner. You know this step is done when the account owner has signed off on the list and no member account is unaccounted for.
Freeze new sends for a defined window
Agree a cutoff window with the business owners of each workflow and stop new signature requests from being sent for that period, including sends from code through the API. Pause or note any integration that creates requests automatically. The output is a documented cutoff time, which keeps the export set fixed while you work. You know this step is done when every integration owner confirms in writing that sending has stopped, and the cutoff time is recorded in the inventory.
List all signature requests through the API
Use the Dropbox Sign API with your team's credentials to list signature requests, following the pagination on each page until no further pages remain. Save the raw responses, not a hand-typed copy. The output is a complete listing with each request ID, title, status, creation date and recipient count. You know this step is done when the total count of listed requests matches the count your team exports from the web console for the same period, and any difference is explained.
Download each completed request as a merged PDF or ZIP
For each request with a completed status, download the merged PDF of the signed document or use the bulk ZIP download where it fits your volume. Name each file with its request ID so it can be matched back to the listing. Requests that are still out for signature need a separate decision about whether to finish them in Dropbox Sign or cancel them, and the decision should be recorded. The output is a folder of signed files keyed by request ID. You know this step is done when every completed request ID has exactly one file and no file exists without a matching ID.
Retrieve the audit trail for each request
Download the audit trail for each request separately. Dropbox Sign describes the audit trail as non-editable and affixed to every signature request, so keep it as a record alongside the signed PDF rather than trying to rebuild it in the new platform. The output is one audit trail file per request ID. You know this step is done when each audit trail opens, lists the request ID and shows every signer from the request listing. Spot-check a sample of audit trails against the web console to confirm the content matches.
Store files with a manifest
Place the signed PDFs, audit trails and the raw API listing into a single archive structure on storage you control, and write a manifest file that lists each file path, its request ID and a cryptographic hash such as SHA-256. Keep the manifest format simple, such as a CSV, so a reviewer can read it without special tools. Restrict access to the archive to the people who need it. The output is the archive and its manifest. You know this step is done when the manifest contains one row per file and the archive is stored in a location with access controls and backup.
Check counts and hashes against the listing
Compare the manifest against the original API listing. Confirm that the number of request IDs, PDFs and audit trails match, that every hash recomputes to the value in the manifest on a second read, and that page counts on a sample of signed PDFs match the page counts shown in Dropbox Sign. Open a sample of files by hand to confirm they show the signature and the signer names. The output is a signed-off verification record. You know this step is done when every mismatch is resolved or documented with an owner and reason, and a second person has reviewed the record.
How the export differs for team accounts and individual users
In a team account, the export is usually run by an administrator who can see signature requests sent by every member. Before starting, confirm that the credentials you plan to use return requests from all members, because a key tied to one member may only list that person's requests. Ask Dropbox Sign to confirm how team-wide listing works through the API and whether requests on shared templates appear in the same listing.
- Admin scope: Confirm that the API key belongs to a team administrator and returns requests across all members, not only the key owner.
- Member inventory: Record each member and the count of requests they hold before the export so you can reconcile totals afterward.
- Shared templates: Export template definitions separately, since they may be owned by individual users and will not appear in a request listing.
- Departed members: Check whether requests from members who have left the team are still returned, and export them before removing seats.
- Key handling: Limit the API key to the export job, store it in a secrets manager and rotate it once the archive is verified.
Check that the number of exported requests matches the team's listing in the web console for the same date range.
An individual account holds the requests that its owner created, so the account holder runs the export and no administrator can pull other records. The main risk is assuming that the account contains everything the person ever signed. Confirm whether the API key is generated from account settings and whether it lists requests where the user was only a signer, because those may belong to the sender's account.
- Owner runs it: The account holder exports their own requests and downloads the completed files and audit trails.
- Signer-only records: Documents you signed but did not send may sit in the sender's account, so ask the sender to export them.
- Drafts and cancelled items: Confirm whether drafts and cancelled requests are returned and decide with the business owner whether they count as records.
- Personal key handling: Keep a personal API key out of shared scripts, tickets and chat logs, and revoke it after the export.
- Handover: If the person is leaving, export before the account is closed and agree in writing who keeps the archive.
Ask Dropbox Sign to confirm what happens to requests in the account after a downgrade or closure, and how long they remain downloadable.
When agreements carry retention duties, the export becomes a records action, so legal or compliance should approve its scope before anyone runs it. Electronic form alone does not settle every record. The ESIGN Act excludes, among other records, wills, codicils and testamentary trusts, certain state family law matters, most of the Uniform Commercial Code, and court orders and official court documents, so those may need handling outside the general signing workflow.
- Retention map: Match each agreement type to its retention requirement with counsel before choosing what to export.
- Excluded records: Identify agreements that fall under the ESIGN Act exceptions, since they may need paper or separate handling.
- Audit trail integrity: Store each non-editable audit trail with its PDF and record a checksum at download so later changes are detectable.
- Chain of custody: Log who ran the export, when, with which key and where each file was stored.
- EU qualified signatures: If any agreement relied on a qualified electronic signature, keep the certificate evidence, because its validity depends on a qualified certificate from a trust service provider listed in the national Trusted List.
Ask counsel to approve the retention map in writing, and ask Dropbox Sign how long it keeps requests after a subscription ends.
What to plan before the Dropbox Sign contract ends
The export itself is the mechanical part. The decisions around it decide whether you lose records or access at the wrong moment. Each card below is a decision or check to settle with finance, legal and the signing teams before the Dropbox Sign subscription lapses.
Notice period and renewal date
Read your Dropbox Sign order form or subscription terms and note the renewal date, the notice period and whether cancellation must be in writing. Confirm whether seats or API usage are billed separately, since the API is priced apart from web plans. Set your internal deadline a comfortable margin before the notice date so an export problem does not force a renewal. Ask the account owner to confirm who can submit the cancellation.
Retention window after cancellation
Ask Dropbox Sign in writing how long completed signature requests, audit trails and files remain retrievable after cancellation, and whether access ends immediately or after a grace period. Do not assume the web interface will remain available for downloads. Treat the vendor's answer as the hard deadline for your final export, and schedule a re-export check just before that date.
Parallel-run period
Keep Dropbox Sign and the new platform live at the same time for a defined period. During this window, signers can complete requests in either system and you can compare outputs side by side. Agree the length of this period with the business owners of the agreements, because contracts with long signing cycles may still be open when cancellation takes effect.
Cutover date for new sends
Choose a single date after which all new signature requests go to the new platform. Update templates, integrations and webhook or API callbacks to point at it before that date. Ask integration owners to list every system that sends requests from code, so no application continues to call Dropbox Sign after cutover.
Archive sign-off owners
Name the people who approve the archive: a records owner who confirms completeness, a legal reviewer who confirms the audit trails and signed PDFs are usable as records, and a security owner who confirms storage location and access controls. Their sign-off should be recorded before any cancellation. Confirm what your retention policy requires for each contract type.
Legal review before cancellation
Do not cancel until the archive passes verification and legal review. Verification means every expected request is present, each PDF opens, and each audit trail matches its agreement. Legal review confirms that the exported records meet your evidence needs. Certain record types, such as wills or court documents, fall outside the federal ESIGN Act, so check them under the rules that apply to your jurisdiction.
Questions buyers ask before exporting Dropbox Sign data
How much effort does a full Dropbox Sign export take?
The effort depends mostly on how many completed signature requests, templates and users sit in the account, and on how much of the history must be retrieved as audit trails. A small team with a few hundred agreements can script one pass through the API and check the results by hand. A large organization with many users, years of history and several templates needs an inventory first, then batched downloads, file naming rules and a reconciliation step that matches every request ID to a stored PDF and audit trail. Ask your current Dropbox Sign administrator to export a count of requests by status and by year before anyone estimates the work.
Can our own staff run the export without a partner?
Yes, in many cases, if someone on the team can call a REST API, handle pagination and rate limits, write files to storage and verify checksums. The work is mostly scripting and data checking, not signature cryptography. Staff need to understand the Dropbox Sign API documentation, basic scripting (for example, Python or Node.js), and how to store and index files so they can be found years later. Plan for a test run on a small batch, a full run, and a sample review by someone who knows the business records. Confirm the exact endpoints and response fields against Dropbox Sign's current API documentation before you write any code.
What does the export need from our side?
You need an account with administrator rights, or a user who can see all team signature requests, and an API key with read access. You also need a named legal owner who decides which agreements must be kept, which are safe to archive and how long records must be retained. Storage must be ready before the export starts: encrypted, access-controlled and sized for the PDFs and audit trails, which are often larger than the agreements themselves. Confirm with your legal and records teams whether any agreement types fall under exceptions to the ESIGN Act, such as wills or court documents, because those may need separate handling.
Will signatures stay valid after we leave Dropbox Sign?
Exported PDFs remain the record of what was signed, and the non-editable audit trail that Dropbox Sign attaches to each request is the evidence that supports it. Under 15 U.S.C. 7001(a), an electronic signature may not be denied legal effect solely because it is electronic, but validity still depends on the facts of each transaction, the consent of the parties and the records you keep. Store the audit trail with its PDF, keep the request IDs and timestamps, and record which platform produced the record. For EU agreements, the eIDAS level matters: a simple signature cannot be upgraded by moving files, so ask your legal team whether advanced or qualified signatures were used. Confirm the approach with counsel before you decommission the old account.
Who pays for each part of the export?
Your organization pays for internal staff time, storage for the exported files and any backup copies, and the license or hosting of the target platform. A partner, if used, is paid under a written, fixed-scope agreement for the work you specify, such as inventory, scripting, verification and documentation. The Dropbox Sign subscription may continue for a notice period or until the export is complete, so check your contract terms. Ask any vendor or partner for a quote that lists each component separately, with what is one-time (migration scripts, initial load) and what recurs (storage, hosting, license renewals, support).
Should we hire a partner, and what should the scope cover?
A partner is worth considering when volume is high, audit records must be proven complete, or internal staff are already committed. DeployOpen plans, implements, integrates, documents and supports self-hosted open-source platforms in your own infrastructure, and most engagements are fixed-scope with deliverables agreed in writing before work starts. DeployOpen does not issue audit reports or certifications. A written scope should name the request count and date range covered, the inventory method, the file and naming structure, the audit trail handling, the verification method (such as checksums and sampling), the storage location, the handover documents and any items excluded, such as template rebuilding in the target platform. Ask for acceptance criteria for each deliverable.
How do we confirm the export is complete?
Reconcile counts before and after the download. Compare the number of requests returned by the API for each status and date range with the number of PDFs and audit trails in storage, and log any request that failed or returned an error. Use checksums to confirm files were not corrupted in transfer, and sample a set of agreements for a human review against the original. Keep the export log, the script version and the reconciliation report as records of how the data was moved. Confirm with the Dropbox Sign documentation which fields and files are available for each request type, since some items may only be retrievable in certain formats.
How DeployOpen scopes and delivers a Dropbox Sign data export
DeployOpen treats the export as a written, fixed-scope piece of work: we agree which Dropbox Sign requests, templates and audit trails must leave the account, then build and verify a repeatable extraction that writes everything to storage you control. The result is a documented archive your team can check before any cutover to a self-hosted signing platform.
How we scope
- Inventory the team accounts, signature requests and templates that must be exported before any download begins
- Confirm which completed agreements, expired or declined requests and audit trails count as records to keep
- Agree the storage location, file naming, retention rules and who receives the final archive in writing
- Identify any ESIGN Act exceptions, such as wills or court documents, that need separate handling by your legal team
How we build
- Write API-based extraction scripts that page through all team signature requests rather than relying on manual downloads
- Download each completed request as a merged PDF or ZIP and record its identifier alongside the file
- Store non-editable audit trails as separate records linked to their agreement so they stay readable without the source system
- Test the extraction on a sample set and reconcile file counts against the Dropbox Sign request list before a full run
How we hand over
- Deliver the archive with an index file mapping each request identifier, signer list, dates and file hashes
- Provide a written runbook describing how the scripts were run, what they exclude and how to rerun them
- Document any requests that failed to export, with the reason and the agreed manual follow-up
- Walk your IT and compliance owners through the archive so they can confirm completeness before the account closes
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts
- Ongoing support, upgrades and continuous testing of the migrated environment are available as a retainer
- Ask for a written quote based on the agreed scope, covering the scripts, testing, documentation and handover items
- Confirm with your own compliance or legal advisers which exported records must be retained and for how long

