The real problem is not switching platforms. It is switching safely.
If you are running Docusign in production today, you already know migration is not a weekend project. Your codebase does not just call Docusign. It relies on a connected set of behaviors such as signing flows, template and field mappings, webhook based status updates, and downstream logic triggered by document lifecycle events.
If any of those behaviors change during migration, problems can surface quietly. Signatures may be delayed. Webhook handlers may stop firing. Downstream systems may receive events they do not recognize.
The challenge was never “can we build a BoldSign integration?” It’s “can we replace Docusign without disrupting what already works?”
That is exactly what the Docusign to BoldSign Migration Skill is designed to help with. In this blog post, we will walk through how it supports a safer migration.
Why teams are migrating now
Docusign’s pricing has become a growing concern for teams, especially for API driven workflows. While it often comes down to per document or per envelope usage, the total cost is commonly shaped by plan tiers, feature gates, and usage thresholds. As document volume grows across multiple workflows and environments, those constraints can push costs up faster than many teams expect.
BoldSign also follows a per document style pricing model, but with a structure that is typically easier to forecast as automation scales. Limits and overages can still apply, but teams often evaluate BoldSign because the pricing tends to be more predictable and, in many cases, lower than Docusign for comparable API driven usage. BoldSign also provides SDKs for .NET, Node.js, Python, Java, and PHP.
For teams evaluating broader tradeoffs, BoldSign provides a detailed comparison of API models, pricing, and capabilities in its Docusign API alternative overview.
But cost alone doesn’t justify the risk of migrating a production integration. What justifies it is having a reliable, repeatable process, and that’s where AI Agent Skills come in.
Migration goal: Behavior parity, not reinvention
The goal of this migration is not to redesign workflows or introduce new architecture. The goal is to preserve existing behavior.
If a document triggered specific lifecycle events before migration, it should trigger the same events afterward. Downstream systems should continue to receive the same signals, in the same order, with no changes required.
A successful migration is one where users notice no difference and only the underlying platform has changed.
Why a specialized migration skill is needed
If you’re using AI coding agents like Claude Code, GitHub Copilot, OpenAI Codex, Cursor, or any of the 16+ tools that now support the SKILL.md standard, you’ve probably noticed a pattern: AI agents are great at generating code, but they struggle with platform-specific nuances.
Ask an AI agent to “migrate this Docusign code to BoldSign” without context, and you’ll get code that compiles but breaks in production. Common failures include:
- Treating document sending as synchronous. BoldSign’s SendDocument returns a DocumentId immediately, but the document isn’t sent yet. You must use webhook events to track completion.
- Missing webhook verification. The agent generates a webhook handler but skips signature validation entirely.
- Wrong field mappings. Docusign calls them “tabs.” BoldSign calls them “form fields.” The mapping isn’t one-to-one, and the agent guesses wrong.
- Polling instead of webhooks. The agent defaults to polling for status, which burns through rate limits.
A Migration Skill prevents all of these by encoding the correct mappings, lifecycle behaviors, and platform rules directly into the agent’s context. Think of it as giving the AI the complete senior developer onboarding guide before it writes a single line of code.
Common migration mistakes the skill prevents
| Mistake | What Happens | How the Migration Skill Helps |
|---|---|---|
| Treating SendDocument as synchronous | Code waits for completion that never occurs, leading to timeouts in production | Ensures completion is always tracked via webhook events |
| Polling for document status | Rapidly consumes API rate limits in sandbox and production | Enforces an event‑driven lifecycle model |
| Skipping webhook signature verification | Webhook endpoint becomes vulnerable to spoofed events | Requires HMAC SHA256 verification for all webhook handlers |
| Using application/json for file uploads | API rejects uploads and document sending fails | Enforces multipart form‑data for all file operations |
| Assuming audit logs are included with documents | Compliance data is missing or not stored | Generates a separate audit log retrieval call |
| Hardcoding API endpoints | Deployment breaks for EU or regional environments | Selects the correct regional API endpoint automatically |
Anatomy of the Docusign to BoldSign migration Skill
The skill is intentionally minimal and focused.
docusign-to-boldsign-api-migration/
├── README.md
└── BoldSign/
└── SKILL.md
Everything important is defined inside SKILL.md.
It contains:
- Object mappings such as envelopes to documents, tabs to form fields, and recipients to signers
- Behavior guarantees that must remain unchanged
- Assumptions that no longer apply after migration such as synchronous sends or polling
- Correct webhook usage and lifecycle handling patterns
Before generating any migration code, the AI agent reads this file and applies its constraints, ensuring production-safe output rather than guessed implementations.
Popular AI coding agents that support skill
Many modern AI coding agents allow developers to load external context folders such as the BoldSign Skill, so the agent can generate accurate, .NET SDK aligned integration code.
- Syncfusion Code Studio - AI code editor / IDE for enterprise app development.
- Claude Code - Anthropic’s AI coding agent for terminal, IDE, desktop, and browser.
- Cursor - AI-first code editor.
- GitHub Copilot Coding Agent– GitHub’s coding agent for project tasks and fixes.
- OpenAI Codex - OpenAI’s AI coding partner / agent platform.
In this blog post, we demonstrate the migration using Syncfusion Code Studio with the Claude model.
Getting started with the migration skill
Using the BoldSign Skill in Code Studio is straightforward. Here’s the process:
Step 1: Obtain the skill
Clone or download the Docusign to BoldSign API Migration GitHub repository
Step 2: Place it in your skills directory
Place the folder in /.codestudio/skills/. Once placed here, the Skill becomes available whenever Docusign to BoldSign migration context is detected.
*Step 3: Select your AI model*
Open the model selector at the bottom of Code Studio and choose the model you want to use.
*Step 4: Prompt the agent*
Provide your existing Docusign .NET code and prompt:
“Using the skill, convert this Docusign .NET implementation to BoldSign while preserving functionality.”
The agent will:
- Analyze the existing Docusign logic
- Apply the mappings defined in the skill
- Generate equivalent BoldSign .NET SDK code
- Preserve asynchronous lifecycle behavior
Key example: Sending a document
This example shows how a common Docusign envelope workflow translates cleanly to BoldSign while preserving behavior.
Docusign .NET Example
C#
using Docusign.eSign.Api;
using Docusign.eSign.Client;
using Docusign.eSign.Model;
// 1. Setup client
var apiClient = new ApiClient("https://demo.Docusign.net/restapi");
apiClient.Configuration.DefaultHeader.Add("Authorization", "Bearer " + accessToken);
var envelopesApi = new EnvelopesApi(apiClient);
// 2. Create document
var doc = new Document
{
DocumentBase64 = Convert.ToBase64String(File.ReadAllBytes("contract.pdf")),
Name = "Contract.pdf",
FileExtension = "pdf",
DocumentId = "1"
};
// 3. Create signer with tabs
var signer = new Signer
{
Email = "john@example.com",
Name = "John Doe",
RecipientId = "1",
RoutingOrder = "1",
Tabs = new Tabs
{
SignHereTabs = new List<SignHere>
{
new SignHere
{
DocumentId = "1",
PageNumber = "1",
XPosition = "100",
YPosition = "200"
}
},
DateSignedTabs = new List<DateSigned>
{
new DateSigned
{
DocumentId = "1",
PageNumber = "1",
XPosition = "300",
YPosition = "200"
}
},
TextTabs = new List<Text>
{
new Text
{
DocumentId = "1",
PageNumber = "1",
XPosition = "100",
YPosition = "300",
TabLabel = "company_name",
Required = "true"
}
}
}
};
// 4. Build and send envelope
var envelopeDefinition = new EnvelopeDefinition
{
EmailSubject = "Please sign this document",
EmailBlurb = "Please review and sign.",
Documents = new List<Document> { doc },
Recipients = new Recipients
{
Signers = new List<Signer> { signer },
},
Status = "sent" // "sent" sends immediately; "created" saves as draft
};
var result = envelopesApi.CreateEnvelope(accountId, envelopeDefinition);
Console.WriteLine($"Envelope ID: {result.EnvelopeId}");
BoldSign .NET Equivalent
C#
using BoldSign.Api;
using BoldSign.Model;
// 1. Setup client — much simpler
var apiClient = new ApiClient("https://api.boldsign.com",
Environment.GetEnvironmentVariable("BOLDSIGN_API_KEY"));
var documentClient = new DocumentClient(apiClient);
// 2. Load file as stream (not Base64)
using var fileStream = File.OpenRead("contract.pdf");
var documentFile = new DocumentFileStream
{
ContentType = "application/pdf",
FileData = fileStream,
FileName = "contract.pdf"
};
// 3. Create form fields (equivalent to Docusign tabs)
var signatureField = new FormField
{
FieldType = FieldType.Signature,
PageNumber = 1,
Bounds = new Rectangle(x: 100, y: 200, width: 200, height: 50),
IsRequired = true
};
var dateSignedField = new FormField
{
FieldType = FieldType.DateSigned,
PageNumber = 1,
Bounds = new Rectangle(x: 300, y: 200, width: 150, height: 30)
};
var textField = new FormField
{
Id = "company_name",
FieldType = FieldType.Textbox,
PageNumber = 1,
Bounds = new Rectangle(x: 100, y: 300, width: 200, height: 30),
IsRequired = true
};
// 4. Create signer (with form fields attached to the signer)
var signer = new DocumentSigner(
name: "John Doe",
emailAddress: "john@example.com",
signerType: SignerType.Signer,
formFields: new List<FormField> { signatureField, dateSignedField, textField }
);
// 5. Build and send
var sendRequest = new SendForSign
{
Title = "Please sign this document",
Message = "Please review and sign.",
Signers = new List<DocumentSigner> { signer },
Files = new List<IDocumentFile> { documentFile },
// ExpiryDays = 30,
// EnableSigningOrder = true // For sequential signing
};
var result = documentClient.SendDocument(sendRequest);
Console.WriteLine($"Document ID: {result.DocumentId}");
// NOTE: Document send is ASYNC — listen for Sent/SendFailed webhooks
Important: Document sending in BoldSign is asynchronous. Completion must be tracked using webhooks, not polling or blocking logic.
In the above example, the document send logic maps cleanly from Docusign to BoldSign using equivalent SDK calls. Core workflow intent remains unchanged, while platform-specific differences are handled automatically by the Migration Skill.
What the skill handles during migration
Authentication
- Converts OAuth-based Docusign flows
- Supports BoldSign API key or OAuth
- Prevents hardcoded credentials
Signing behavior
- Preserves signing order
- Enforces required fields
- Supports template-based and coordinate-based workflows
Embedded signing
- Preserves iframe-based flows
- Maintains redirect and expiry behavior
- Ensures access controls remain unchanged
Document retrieval and audit trails
- Reliable signed document retrieval
- Explicit audit trail APIs
- Compliance workflows preserved
Webhooks and lifecycle tracking
- Event-driven lifecycle handling
- HMAC SHA256 verification enforced
- Correct handling of Sent, Viewed, Signed, Completed, Declined, Expired, and failure events
The five-step recommended migration approach
Don’t migrate everything at once. Each step should be verified independently before moving forward.
Step 1: Basic document send
Migrate a single document send flow. Verify delivery, field placement, and signer access. Use BoldSign’s sandbox environment for all testing.
Step 2: Webhook lifecycle tracking
Configure HMAC verified webhooks. Confirm that lifecycle events are processed correctly.
Step 3: Embedded signing
Migrate iframe based signing. Validate link generation, redirects, and signing experience.
Step 4: Templates and advanced fields
Migrate template workflows. Validate field mappings, defaults, and validation rules.
Step 5: Multisigner and advanced workflows
Extend to sequential and parallel signing, reminders, revocation, and signer authentication.
Supported migration workflows
The Migration Skill supports:
- Single and multi-signer workflows
- Sequential and parallel signing
- Embedded signing for SaaS applications
- Template-based document sending
- Bulk send operations
- Full lifecycle tracking via webhooks
- Signed document and audit trail retrieval
- Reminder, revoke, and delete operations
- OTP, access code, and identity verification
All migrations target behavior parity. The goal is to achieve identical functionality on a different platform, not to redesign existing workflows.
Final takeaway
Migrating from Docusign does not require rebuilding your system.
With BoldSign’s Docusign to BoldSign Migration Skill, teams can:
- Preserve existing workflows
- Reduce migration risk
- Maintain webhook and lifecycle behavior
- Transition safely without disrupting production
Start with a single workflow. Validate it thoroughly from end to end. Then expand with confidence.
Get started
- Explore the Docusign to BoldSign Migration Skill on GitHub
- Create a free BoldSign Sandbox account
- Review available APIs and SDKs in the BoldSign Developer Documentation
If you are building new workflows, the BoldSign eSignature Skill for new integrations provides a strong foundation. Existing Docusign templates can also be migrated easily using the Import Docusign Templates into BoldSign guide.
If additional help is needed during setup, testing, or migration planning, the BoldSign Support Portal provides direct access to documentation, guides, and the BoldSign support team.
Related blogs
- Controllers vs Minimal APIs in .NET 8: What to Choose and Why
- BoldSign Edit Document API: Update Signers, Fields, and Files Without Restarting
- ASP.NET Core Minimal APIs: When to Use Them and When Not To Use Them
Note: This blog was originally published at boldsign.com
Top comments (0)