Docusign modernizes its eSignature data platform and builds an AI-ready future with Azure SQL

More than 1.9 million customers and a billion people in 180 countries rely on Docusign solutions to accelerate the process of doing business and simplify people's lives. When its 308 TB on-premises SQL Server database supporting its core eSignature platform hit a single-instance ceiling, the legacy infrastructure could no longer scale efficiently.

Working with Microsoft SQL Engineering, Docusign modernized its core eSignature stack without rewriting the application, decomposing the database across custom Azure SQL configurations, Azure SQL Managed Instance, Azure SQL virtual machines, and Azure SQL Database Hyperscale.

Docusign migrated nearly 200 million accounts across five global sites with zero rollbacks, cutting P99 signing latency by over 3 seconds and establishing an elastic cloud foundation for AI-driven agreement management.

Docusign, the global leader in electronic signatures and pioneer of Intelligent Agreement Management (IAM), provides eSignature services on a live, high-scale transaction platform. Over 1.9 million customers and a billion people in 180 countries rely on Docusign to complete millions of transactions daily. Slow or unavailable agreements can delay sales, hires, renewals, or payments, slow hospital admissions, prevent bank account openings, and interrupt hotel check-ins. To keep improving the platform without compromising availability, latency, security, or compliance, Docusign modernized its core eSignature stack by moving complex on-premises SQL Server workloads to Microsoft Azure.

Hitting the monolithic architecture ceiling

Over time, Docusign's primary database, DocusignDB (DSDB), grew to 308 TB across five production sites, with more than 500 tables and 8,000 stored procedures. At peak, the hottest DSDB instance generated two to three times the I/O demand of a top-tier Azure M176 configuration. The sheer size of the monolithic database, combined with continued transaction growth and concentrated I/O demand, made it increasingly difficult to meet the performance benchmarks required by the eSignature application.

"As demand grew, DSDB’s production environment began approaching its practical capacity, with engine-level contention constraining throughput at the busiest site," says Josh Meier, Senior Principal Engineer at Docusign.

Docusign needed an architecture that could sustain growing transaction volumes and maintain predictable application performance without changing the customer experience or API contract. A 1:1 migration would have carried the same scalability constraints forward, while moving accounts individually introduced unacceptable cross-datacenter latency. The modernization therefore had to distribute the workload while preserving application behavior and providing a path to scale throughput as demand increased.

Modernizing workloads on SQL hyperscale

To meet this demand, Docusign decomposed its core database environment through vertical and horizontal sharding across custom Azure SQL configurations and services. "The point was not to force every database onto one Azure service, the point was to match the service to the workload," says Abhishek Chaturvedi, Fellow at Docusign.

Microsoft SQL Engineering worked with Docusign to validate the Azure SQL design. For new and feature-specific databases, Docusign uses Azure SQL managed database services. EnvelopeSearchDB (ESDB) runs on Azure SQL Database Hyperscale, providing a consolidated search view across DSDB and EVDB with read replicas and independent compute and storage scaling.

Azure SQL Database Hyperscale re-architects the traditional database engine around distributed storage, separated compute and storage, and scalable cloud-native infrastructure. This technology future-proofs even small SQL workloads and scales to meet changing requirements.

For the largest DSDB workloads, Azure SQL virtual machines provided the configuration control and sizing required, while query optimization and the extraction of blob metadata, address books, brands, and templates reduced DSDB IOPS for a safe failover.

Faster performance and zero rollbacks

Docusign executed a sub-five-minute site-level database failover followed by a controlled EVDB ramp, validated with 35,000 test cases and over 50 runbook rehearsals.

"The team moved nearly 200 million accounts across five production sites while eSignature stayed live," says Chaturvedi. "We did it without rewriting the application, without a big-bang customer migration, and without a production rollback."

Post-failover storage tuning cut average read time by 5 milliseconds, and P99 latency for completing a signing session and posting a new envelope dropped by over 3 seconds at the largest North American sites. Adding capacity is now a deployment rather than a year-long hardware procurement cycle.

“The team moved nearly 200 million accounts across five production sites while eSignature stayed live. We did it without rewriting the application, without a big-bang customer migration, and without a production rollback.”

Abhishek Chaturvedi, Fellow, Docusign

A foundation for continued growth

The resulting architecture lets Docusign shard the transactional envelope workload while preserving a unified search experience. As EVDB adds shards and envelope history moves from DSDB, ESDB can expand storage, compute, and read capacity independently without rebuilding the application or search architecture.

Next, Docusign is moving more eSign services onto its Kubernetes-based platform and decommissioning on-premises datacenters. "The biggest change is that we are no longer forced to treat eSign as one indivisible system," says Meier. "The application can remain stable while the data and infrastructure underneath it evolve in smaller, safer steps."

This modernized Azure foundation also provides the scale to power IAM and AI capabilities, including Docusign Iris, the engine powering Docusign’s AI contract management platform, in addition to AI-assisted agreement summaries, real-time signer Q&A, and AI agents automating redlines.