Migrate from Dropbox Sign to Documenso: what the move involves
Moving from Dropbox Sign to Documenso is a data, template and integration project, and the signing certificate is the decision that shapes the rest. Most teams start this work because of a renewal, a licensing or pricing change, a data residency requirement or a wish to avoid lock-in. The platform team or IT team usually owns it, sometimes with an implementation partner for the hosting, integration or hardening work. Documenso is licensed under AGPL-3.0 and runs in your own infrastructure, so the organization owns the signing certificate, the outgoing email configuration and the backups. Nobody else holds those for you, which is the point of the move, but it also means each of them needs a named owner before cutover.
Effort and risk depend mostly on three things: how many completed agreements must stay retrievable, how many templates and recipient roles need rebuilding, and how many systems call the Dropbox Sign API today. No duration can be stated from the outside, so ask for a written scope that lists each of these counts from your own account. Risk concentrates in the places a signer or auditor would notice first: a missing audit trail for an old agreement, a template with the wrong signing order, or a webhook that still points at a retired endpoint. Run a parallel period in which new requests go to Documenso while historical records remain in Dropbox Sign until export is verified.
Before you start, confirm with your legal and compliance owners which agreement types they accept electronically and whether any fall outside the ESIGN Act exceptions, such as wills or court documents. Then decide which signing certificate model fits your risk profile, because Documenso needs one to digitally sign documents. Documenso's own signing guide documents a self-signed .p12 certificate generated with OpenSSL and signing through Google Cloud KMS. Choose the option with your security team, document the key custody, and plan certificate renewal before the first production send.
Which Dropbox Sign capabilities map to Documenso, and what needs rework
This table maps the Dropbox Sign capabilities a migration touches to their Documenso counterparts. Each row gives a status of Clean, Needs rework or Gap, plus what to confirm before cutover. The main takeaway is that sending and completed documents move with little change, while templates, team setup, integrations and the signing certificate need deliberate work.
| Dropbox Sign capability | Documenso counterpart | Status | What to confirm before cutover |
|---|---|---|---|
| Signature requests | Documents sent to one or more recipients for signing | Clean | Confirm signing order and reminder settings match how your teams work today |
| Templates | Reusable documents with fields and recipients, rebuilt in Documenso | Needs rework | Plan to rebuild and test each template, and check whether any import path exists in your Documenso version |
| Recipient roles and signing order | Recipients on documents and templates with assigned fields | Needs rework | Map each Dropbox Sign role to a Documenso recipient and test field assignment on every template |
| Audit trails | Completion record for each document, to be confirmed in your version | Gap | Archive exported Dropbox Sign audit trails as records and expect no like-for-like transfer; confirm what Documenso generates per document |
| Team management | Teams with members and shared documents, depending on plan or self-hosted license | Needs rework | Confirm user roles, team sharing and seat counting for your self-hosted deployment |
| API access | Documenso API for documents and recipients, with API access listed on its Teams plan for cloud | Needs rework | Inventory every endpoint and callback your code uses, then confirm API access for your self-hosted setup |
| Embedded signing | Embedded signing on Teams, with white-labeled embedded signing on Platform | Needs rework | Confirm whether you need white-labeling and test the signer flow on your own domain |
| Signing certificate | Operator-provided certificate, such as a self-signed .p12 file or Google Cloud KMS | Gap | Choose, document and rotate the certificate yourself, since the hosted service manages signing for you today |
What moves cleanly and what does not
Completed signed PDFs move cleanly, but the Dropbox Sign audit trail does not travel with them automatically. Export each completed agreement as a signed PDF and store it in your own archive under your retention rules. Dropbox Sign states that a non-editable audit trail is affixed to every signature request, so treat that trail as a Dropbox Sign record unless you export it as a separate artifact. Download each audit trail alongside its matching PDF, keep the pair together, and confirm with your records or legal team that this pairing meets your retention policy. Documenso's audit records cover only envelopes sent from your own Documenso instance, so plan to keep Dropbox Sign history in the archive, not in Documenso. Confirm the export options in Dropbox Sign's current help documentation before you close the account, since the available formats may change.
Templates and recipient roles have to be rebuilt in Documenso. No automatic conversion tool is part of this path, so plan a manual rebuild rather than an import. Start with an inventory: for each Dropbox Sign template, record its fields, signer roles, signing order, required fields, expiry and reminder settings, and the people who use it. Then recreate each one in Documenso, send a test envelope to a internal test mailbox, and compare the result with the original. Ask Documenso support or check its documentation whether any import path is planned, and do not assume one exists. Retire old templates only after the rebuilt versions have passed review by the business owners who use them.
Documenso needs a signing certificate before it can digitally sign documents, and Dropbox Sign handles this for its customers. When you run Documenso, your team becomes responsible for providing and managing that certificate. The Documenso signing guide documents options such as a self-signed .p12 certificate generated with OpenSSL and signing through Google Cloud KMS. Decide which option fits your risk model, store the private key under strict access controls, and set a renewal date before the certificate expires. Ask your legal counsel whether a self-signed certificate satisfies the evidentiary standard for each document type you sign, because the answer determines whether you need a different certificate source.
Which data and integrations to move, using documented export paths only
A migration to self-hosted Documenso touches four kinds of material: completed records, the setup that produces future requests, the events that notify your systems, and the code that calls the API. Each one has its own export path and its own rebuild step, so treat them as separate workstreams with separate checks.
Completed agreements and audit trails
Pull every completed request through the Dropbox Sign API, listing requests first and then downloading each file. Dropbox Sign states that a non-editable audit trail is affixed to every signature request, so keep that audit trail with each downloaded agreement as part of the record. Documenso's own history will not contain these older events, so the archive becomes your reference copy. Confirm the list and download endpoints, pagination and the file format for each one in the Dropbox Sign API documentation before you script anything.
Requests still in progress
Signature requests that are open at cutover need a decision before the switch. Either let them finish in Dropbox Sign, or cancel and resend them from Documenso so each signer gets a new link on the new system. Resending changes the signing record, so tell the counterparties and record the reason in your contract log. Check how many requests are open for each team and each sender, because a missed request is usually one that a sender forgot about.
Templates and recipient roles
Templates are rebuilt in Documenso, not imported as files, so each one needs its fields, signer roles and signing order recreated. Export the template definitions from Dropbox Sign so you have the field names and roles on record, then compare them with the Documenso template after you build it. Pay attention to merge fields and conditional logic, which may need a different structure in Documenso. Confirm the mapping for each field type in the Documenso documentation.
Users, teams and permissions
Document who can send, view and manage templates in Dropbox Sign, then recreate those roles in Documenso's team structure. Teams and seats affect both your access model and your cost, so confirm which Documenso plan or self-hosted license supports the number of users and admin roles you need. Remove dormant accounts from the export list so you do not carry them into the new system. Your identity provider should control sign-in, so check how Documenso connects to it before users are added.
Webhooks and callbacks
Any system that receives Dropbox Sign events, such as a completed request that updates a CRM or contract repository, needs an equivalent event path in Documenso. Inventory every callback URL, the events it listens for and the payload fields it reads. Then build the matching receiver and test it with a sample signature before cutover. Dropbox Sign callbacks and Documenso webhooks will not use identical event names or payloads, so confirm each mapping in the vendor documentation rather than assuming it carries over.
Code that calls the Dropbox Sign API
Scripts and applications that create requests, add signers or fetch status must move to Documenso's API and, where you embed signing in your product, its embedded signing features. The Documenso pricing page lists API access on its Teams plan and embedded signing on Teams, with white-labeled embedded signing on Platform. Verify the endpoints, authentication method and request fields against the Documenso API reference, and run the migrated code against a test instance before pointing it at production.
The migration sequence from inventory to decommission
This sequence moves signature requests, templates and integrations from Dropbox Sign to a self-hosted Documenso instance without losing records or interrupting signing. Each step ends with a written output that the next step depends on, so the old platform is retired only after the archive has been checked.
Inventory templates, integrations and retention needs
List every active template, signature request type, team member who sends requests, and each integration that calls the Dropbox Sign API or receives its callbacks. Record which documents must be kept, for how long, and under which internal or legal retention rules, since some record types fall outside the ESIGN Act. Your legal and records teams should confirm these rules. The output is a signed-off inventory with one owner per template and per integration.
Deploy a pilot Documenso instance
Deploy Documenso on your own infrastructure using Docker or Docker Compose with a PostgreSQL database, following the installation guide in the project repository. Pin the image version you have tested and place the instance behind your standard TLS, backup and access controls. Confirm that a test document can be uploaded, sent to a test signer and completed. The output is a pilot environment that your security team has reviewed and that can be restored from backup.
Rebuild templates and recipient roles
Recreate each template from the inventory in Documenso, placing fields and defining recipient roles, signing order and required fields to match the Dropbox Sign original. Test each template with internal reviewers by comparing the completed PDF against the source. Retire any template whose content has changed since the original and document the replacement. The output is a template catalog with a test record for each template.
Set up the signing certificate and email
Documenso needs a signing certificate to digitally sign completed documents. Choose the certificate option that your security and trust policy allows, such as a self-signed .p12 certificate generated with OpenSSL or signing through a key management service, as described in the project's signing documentation. Configure outgoing email with your sending domain, then verify that invitation, reminder and completion emails arrive and that the completed PDF validates. Ask your legal team whether a self-signed certificate meets the evidentiary standard for each document type. The output is a validated certificate and a working email flow.
Run both platforms in parallel
Keep Dropbox Sign active for existing requests while new requests for pilot templates go through Documenso. Compare the completed PDFs, audit trails and notification emails from both platforms for the same document types. Log any differences, such as field placement or certificate details, and resolve them before expanding scope. The output is a parallel-run log that lists each template, its result and the owner who approved it.
Cut over API callbacks to Documenso
Point the integrations from the inventory at Documenso's API, and replace Dropbox Sign callback handling with Documenso's webhook events. Test every integration against the pilot instance, including error handling for declined or expired documents. Switch production traffic one integration at a time, and keep the Dropbox Sign callback path ready for rollback until each integration has run cleanly. The output is a signed-off integration list showing which systems now call Documenso.
Archive, verify and decommission Dropbox Sign
Export all completed agreements and their audit trails from Dropbox Sign, store them in your own records system, and check a sample of archived files against the originals for completeness, readability and retained metadata. Once the archive has been verified and retention obligations are covered, end the Dropbox Sign subscription and revoke its API keys. Confirm with your records owner before deletion. The output is a verified archive, a written decommission record and revoked credentials.
What drives cost and duration, and how to keep each down
This table lists the main drivers of cost and effort when moving from Dropbox Sign to self-hosted Documenso, with what each one depends on and how to limit it. Read the one-time rows as the migration project and the recurring rows as the cost of running Documenso after cutover.
| Driver | Why it changes cost or effort | How to keep it down |
|---|---|---|
| Number of templates and recipient roles | Each Dropbox Sign template must be rebuilt with its fields, recipient roles and routing order in Documenso, so effort grows with template count and complexity. | Inventory templates first, retire unused ones, and consolidate near-duplicates before rebuilding. |
| Volume of integrations calling the API | Every system that sends requests or receives callbacks must move to Documenso's API and webhooks, and each integration needs its own testing. | List every integration from Dropbox Sign's API keys and callbacks, then migrate the highest-traffic flows first. |
| Archive and audit trail retention | Completed agreements and audit records must be exported and stored in a format your retention policy accepts, and storage grows with history. | Confirm retention periods with legal and records owners, export in bulk, and store archives in your own object storage. |
| Signing certificate choice | Documenso needs a signing certificate. A self-signed .p12 generated with OpenSSL is simpler to start with, while Google Cloud KMS adds cloud key management and its own billing. | Decide with your security and legal teams which certificate your evidence requirements call for, and document key custody and rotation before go-live. |
| Email delivery setup | Signers receive invitations and completion notices by email, so SMTP relay, sender domain authentication and deliverability testing add setup work. | Use your existing transactional mail service where possible and test with real recipients on each domain you send from. |
| Hosting and operations | Documenso runs on Docker, Kubernetes or manual installation with a PostgreSQL database, so infrastructure, backups, patching and monitoring recur after launch. | Reuse existing container platforms and database operations, and ask for a written runbook covering backup and upgrade steps. |
| Documenso plan or self-hosting license decision | Documenso's cloud tiers are priced monthly and its Enterprise plan has custom pricing for cloud or self-hosted setups. Teams and Platform tiers add API and embedded signing features the migration may need. | Map the features you actually use against the plan tiers on Documenso's pricing page, and ask for a written quote for any licensing you need. |
| One-time versus recurring costs | Template rebuilds, integration changes, certificate setup and testing are one-time. Hosting, licensing, certificate renewal and upgrades recur. | Ask each vendor or partner to split the written quote into one-time and recurring lines before approval. |
| Items to put in a written quote | A quote should follow from agreed scope, and unclear scope is the most common source of overruns. | Request scope covering template count, integration list, archive volume, certificate option, email setup and support period. |
What usually goes wrong in this migration
Most failed signature migrations break at the edges: archives, certificates, email and integrations, not the signing screens themselves. The cards below cover five places where teams lose evidence or stall cutover, with a prevention step for each.
Missing audit trail archives
Completed agreements are often exported without their audit trails, so the PDF survives but the record of who signed, when and from where does not. Dropbox Sign attaches a non-editable audit trail to every signature request, so treat that trail as a separate record. Export each request's audit trail alongside its merged PDF and store both under the same request ID. Before decommissioning Dropbox Sign, sample a set of archived agreements and confirm the trail opens and matches the signer list.
Signing certificate mismatch or expiry
Documenso needs a signing certificate to digitally sign documents, and that certificate becomes a dependency your team must operate. A self-signed .p12 generated with OpenSSL, or a key held in Google Cloud KMS, must be valid in production, trusted by the recipients' viewers and renewed before it expires. Document the certificate's validity dates, its issuer and its storage location before go-live, and test a signed document in at least two PDF readers. Ask your legal team whether a self-signed certificate meets the evidence standard for each agreement type.
Email deliverability failures
Documenso sends signing invitations, reminders and completion notices by email, so a misconfigured sending domain sends contracts to spam or drops them silently. Teams often test with their own mailbox and miss failures at external providers. Confirm SPF, DKIM and DMARC records for the sending domain before cutover, then send test requests to Gmail, Microsoft 365 and a few external addresses. Check bounce handling and make sure the reply-to address routes to a monitored mailbox.
Callbacks still pointing at Dropbox Sign
Systems that create requests or receive completion events through the Dropbox Sign API will keep calling the old service after the web app is switched off, and some failures will only show up at month end when a workflow stalls. Inventory every integration, including scripts, CRM connectors and HR tools, and map each Dropbox Sign callback to its Documenso equivalent. Run a cutover checklist that changes each endpoint and API key in one tracked change, then confirm a completion event reaches every downstream system.
Templates rebuilt with wrong recipient order
When templates are recreated by hand, recipient roles and signing order are the most common errors. A contract that routes to a countersigner before the approver, or marks a witness as a required signer, will still complete but may not match the agreement the business approved. Rebuild each template with its roles, order and required fields written down first, then send a test envelope for every template and compare the signer sequence against the original Dropbox Sign request.
How the move differs by team size and starting point
A small team on a Dropbox Sign web plan usually has a short list of templates, a modest number of active requests and no custom code calling the API. The move is mostly administrative. The order that works best is to export completed agreements first, then rebuild the few templates in Documenso, then switch the team to the new instance. Because the volume is small, the team can test each template by sending a real request to an internal tester before anyone relies on it.
- Export first: Download completed requests and their audit trails before cancelling anything, so no historical record depends on the old account remaining open.
- Rebuild a handful of templates: Recreate each template with its recipient roles and fields, and compare the result against a sample completed PDF.
- Set up the signing certificate once: Documenso needs a certificate to digitally sign documents, so decide which option the team will operate before sending the first live request.
- Configure email sending: Confirm that invitations and completion notices arrive from a domain the team controls and that they do not land in spam folders.
- Run a short parallel period: Send a few live requests through both systems to confirm signers see the expected flow.
Before cutover, check that every active request has either finished or been reissued, and confirm with the vendor which Documenso features your plan or self-hosted license includes.
A team with heavy API integration sends signature requests from its own applications, such as onboarding, procurement or document portals. For this group the work is mainly in the code, not the templates. Every call to the Dropbox Sign API, every callback that updates an internal record and every place that stores a request identifier must be mapped to Documenso's API and embedded signing model before the old integration is turned off. Plan the cutover by application, not by the calendar date of the platform change.
- Inventory every call: List each endpoint, template reference and callback the applications use, including scheduled jobs that poll for status.
- Map callbacks to Documenso's API: Confirm which event notifications Documenso supports and how your application verifies them, then build the receiving side in a test environment.
- Check plan requirements: Documenso's pricing page ties API access and embedded signing to its Teams and Platform plans, so confirm which tier or self-hosted license covers your usage.
- Migrate one application at a time: Run each integration against Documenso in staging, then move production traffic in a controlled window.
- Keep identifiers linked: Store the mapping between old request IDs and new document IDs so support staff can find historic records.
Confirm the API surface and webhook behavior against the Documenso documentation for the exact version you deploy, because endpoint names and event payloads change between releases.
A regulated organization, such as a bank, healthcare provider or public body, must keep signed records, audit evidence and proof of how signing worked for the full retention period. Here the sequence is driven by evidence, not convenience. Retention obligations, legal review and any records-management rules should be settled before the old account is closed, because a move that loses audit trails can create a compliance gap that is hard to repair. Some records, such as wills, certain family law documents and court filings, fall outside the ESIGN Act and may need separate handling under 15 U.S.C. 7003.
- Classify the archive: Sort completed agreements by retention class and identify any that fall under exclusions in the ESIGN Act.
- Preserve the Dropbox Sign audit trails: Store them as records in a system with its own retention controls, since they describe how each signature was collected.
- Document the signing certificate: Record who controls the certificate, where its private key is kept, how it is renewed, and whether a self-signed option or a cloud key service is acceptable to your policy and your auditors.
- Define the evidence trail for Documenso: Decide which logs, access records and configuration history must be retained to show the system's controls over time.
- Engage legal and the assessor early: Ask your counsel whether electronic signature requirements need a qualified trust provider for any document type, because an open-source platform does not itself supply qualified certificates.
Ask your legal and compliance teams to confirm each retention rule in writing before any record is deleted from the old service.
Questions buyers ask before moving from Dropbox Sign to Documenso
How much does it cost to move from Dropbox Sign to self-hosted Documenso?
The cost has two parts: the software and the work to run it. Documenso's code is licensed under AGPL-3.0, so the software itself has no license fee for self-hosting. Your recurring costs are the servers and PostgreSQL database, email sending, a signing certificate, and staff time to patch and back up the platform. One-time costs are the migration work: exporting requests, rebuilding templates and moving integrations. Ask any implementation partner for a fixed-scope written quote that lists each component separately, and compare it with your current Dropbox Sign spend, including separate API charges if you use them.
How long does a Documenso migration take?
The duration depends on how many templates you have, how many integrations call the Dropbox Sign API, how much history you must keep, and how many people must test. No timeline has been fixed for this migration. A practical approach is to deploy Documenso in a test environment first, rebuild a handful of high-volume templates, run a parallel pilot, and then cut over. Ask any partner for a written schedule tied to a defined scope, and ask your own team to inventory templates and integrations before agreeing on dates.
What does the internal team need to provide for the migration?
Your team needs someone who can own the infrastructure, someone who knows the signing workflows and templates, and an engineer who understands the Dropbox Sign API calls your applications make. Infrastructure work covers hosting, the PostgreSQL database, SMTP email, TLS and backups. Business work covers approving templates, recipient roles and retention rules. Engineering work covers replacing API callbacks and testing webhooks. Confirm these owners before work starts, because gaps in any of them usually cause the delays.
Can our team migrate from Dropbox Sign to Documenso without outside help?
A technically capable team can deploy Documenso using the documented Docker, Docker Compose, Kubernetes or manual installation paths, because Documenso publishes official images and the code is open for review. The harder parts are the signing certificate, email deliverability, template rebuilds and API cutover, which are easy to get wrong without a test plan. Decide based on your team's capacity and the number of workflows. DeployOpen can plan, implement and document the migration as a fixed-scope engagement if you prefer outside help.
What happens to past Dropbox Sign audit trails after migration?
Dropbox Sign states that a non-editable audit trail is affixed to every signature request. That audit trail stays with the Dropbox Sign account unless you export it, so Documenso will not import it automatically. Before you leave, export completed agreements and their audit trails through the Dropbox Sign API or the web interface, store them as records with checksums, and keep them for the period your retention policy requires. Confirm with your legal and compliance teams which records must be preserved and in what format.
Is a document signed in Documenso legally binding under the ESIGN Act?
Under the US ESIGN Act, an electronic signature or record in a transaction affecting interstate or foreign commerce may not be denied legal effect solely because it is electronic (15 U.S.C. 7001(a)). That rule does not extend to every record, since the Act excludes items such as wills, most family law matters, most of the Uniform Commercial Code, and court documents. Documenso's cloud pricing page lists the ESIGN Act and UETA among its compliance references, but enforceability depends on how your process records consent, identity and intent. Ask your counsel to review the workflows you plan to move.
What is a signing certificate and why does Documenso need one?
A signing certificate is the digital certificate that lets a platform apply a cryptographic digital signature to a finished PDF, so that tampering can be detected. Documenso needs one to digitally sign documents. Its documented options include a self-signed .p12 certificate generated with OpenSSL and signing through Google Cloud KMS. A self-signed certificate is simpler to set up but does not establish third-party trust, while a certificate from a trusted authority or a managed key service adds cost and governance work. Confirm with your security and legal teams which option meets your requirements before go-live.
How DeployOpen scopes and runs the migration
DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted Documenso inside your own infrastructure, whether that is your cloud account, a data center or an air-gapped network. For a move from Dropbox Sign, the work typically covers standing up the Documenso stack on a PostgreSQL database, configuring the signing certificate, setting up outbound email for signer invitations, archiving past requests and audit trails, rebuilding templates and recipient roles, and repointing integrations to Documenso's API. Most engagements are fixed-scope, so the systems, data sets, templates and integrations in scope are agreed in writing before work starts, and ongoing support, upgrades and continuous testing are available as a separate retainer.
Before a quote is written, ask for a scope document that lists each Dropbox Sign template, each integration and callback, each certificate and email domain decision, and who on your side owns the signing certificate and the archive. DeployOpen does not publish a price list, so the quote follows from that written scope. Ask the proposal to separate one-time work (installation, template rebuild, data archive, cutover testing) from recurring work (upgrades, backups, monitoring, retainer support), and to state which items depend on your own decisions, such as whether to use a self-signed certificate or a cloud key service.
DeployOpen prepares systems, configuration, access controls and evidence that your team or an external assessor can review for a compliance assessment, including records of how signing data is stored, backed up and access-controlled. DeployOpen does not issue audit reports, attestations or certifications. Documenso's pricing page lists compliance references such as the ESIGN Act, UETA, 21 CFR Part 11, SOC 2 and HIPAA, but whether your deployment meets any of them depends on your configuration, your processes and an independent assessment, which you should confirm with your auditor or certification body before cutover.
