Migrating Off Formstack Documents in Salesforce (Formerly WebMerge)

Every other migration in this series is mostly an exercise in Salesforce archaeology. This one is not, and that single fact changes how you plan it.

With Formstack Documents, formerly WebMerge, the Salesforce package holds the mappings and the buttons, but the documents themselves, the merge behavior, the delivery routing, and often the history of what was generated all live in a Formstack account outside your org. Your admin can read half the picture from Salesforce. The other half requires credentials to a separate system, which in a surprising number of orgs are held by someone in marketing operations, or by someone who left.

The phased method (inventory, freeze, migrate by pain, pilot, rollback, cleanup) is in the phased migration playbook. This post covers what is specific to a migration that spans two systems.

A scope note: this is about Formstack Documents. Formstack Forms and Formstack Sign are separate products and separate decisions, and they should not be bundled into this project.

The footprint, on both sides

Artifact	Where it lives	Why it matters to the migration
Document templates	Formstack account	The actual documents, with their merge fields and conditional logic
Delivery routes	Formstack account	Email, cloud storage, and Salesforce writeback destinations per document
Generated document history	Formstack account or the configured destinations	Your record of what was sent. Export before cancelling
Mappings	Salesforce package	Which record fields feed which document merge fields
API key and secret	Salesforce configuration	A live credential to revoke at decommissioning
Buttons and automation	Layouts, flows, Apex	The launch points inside Salesforce

What is specifically hard about leaving Formstack Documents

1. Get account access before you plan anything

You cannot inventory what you cannot log into. Before Phase 0, establish who administers the Formstack account, confirm you have working credentials, and check whether the plan's user limit is the reason only one person has them.

Do this first because it can take weeks in a large organization, and because a migration plan built only from the Salesforce side will systematically miss documents. Anything triggered from outside Salesforce, or built by a team that never told the Salesforce admins, exists only on that side.

2. Export everything while you still have a subscription

When the account lapses or is cancelled, access to templates and generation history typically goes with it. That includes the record of what you sent to whom, which may be the only copy if delivery routed the file somewhere other than back to Salesforce.

What to do: treat export as a Phase 0 deliverable, not a decommissioning task. Download every template file, capture every delivery route configuration, and export the generation history to a destination that satisfies your retention policy. Then verify with whoever owns compliance that the archive is acceptable. This is the mistake that cannot be undone after the fact, so do it before you have any reason to think about cancelling.

3. Mappings break silently, and always have

A field mapping that lives outside Salesforce is invisible to metadata dependency tracking. Rename or restructure a field and nothing warns you, the mapping simply stops resolving, and the document ships with a blank where a value used to be.

Most teams that have run this setup for a few years have a story about that. It is worth naming during the migration business case, because it is a class of failure that disappears once field references live inside the org where dependency checks can see them.

What to do: during side-by-side comparison, deliberately test the fields most likely to have drifted, and treat any blank in the current output as a finding to investigate rather than an intentional design.

4. Delivery routing is a fan-out, with other owners

A single document can deliver to several destinations: an email to the customer, a copy to a shared cloud storage folder, a file written back to the Salesforce record, sometimes a handoff to an e-signature tool. Each destination is a separate rebuild, and some belong to other teams.

What to do: inventory delivery routes as their own rows, with a named owner each. Decide explicitly which destinations survive the migration. Some will turn out to exist because the document was being generated outside Salesforce in the first place, and disappear once the document is produced on the record itself, which is a genuine simplification worth capturing in the business case.

5. The security review is your strongest argument, so document it

This setup sends record data to an external service to be merged. That may have been reviewed and approved years ago, or it may have arrived through a departmental purchase that never went through review at all.

What to do: during Phase 0, write down the current data flow explicitly: which fields leave the org, to which service, under what agreement, retained for how long. That paragraph does two jobs. It is the clearest justification for the migration, and it becomes the requirement against which you evaluate replacements. If the answer to "what data leaves the org" becomes "none," that is a durable outcome, unlike a feature comparison.

6. WebMerge-era ownership is often split

Accounts that predate the Formstack rebrand are frequently owned by a team other than the one running Salesforce. Documents were built by whoever needed them, and the Salesforce admins inherited the integration without the context.

What to do: identify the real owner of each document early and bring them into the pilot rather than migrating around them. The freeze rule helps here too: once every change requires migrating the document, the documents nobody is willing to claim ownership of tend to reveal themselves as candidates for retirement.

The Formstack-specific cleanup list

API key and secret: revoke, do not just delete the configuration. A credential removed from Salesforce but still valid at the vendor is a live key with no owner. Revoke at the source, then remove locally.
Connected app entries, remote site settings, and any named credential created for the integration
The mapping records and package configuration, after export
Buttons, flows, and Apex that trigger generation
Custom settings or custom metadata holding the API credentials or environment configuration
Fields created to feed the merge: formatting, concatenation, and sort fields
The subscription itself, cancelled only after export is verified and one full business cycle has run in the new system

The credential step is the one that gets skipped, and it is the one a security review will ask about later.

Where ZeroExport fits

ZeroExport is a native, structure-aware document generation engine that runs entirely inside Salesforce as a managed package. For this particular migration, the architectural difference is the point rather than a footnote:

Nothing leaves the org. There is no external account, no API credential to hold and rotate, and no data flow to describe in a security review. In the discussions we analyzed, this was the highest-demand capability in the entire corpus (362 distinct discussions), and it is the specific gap this setup has.
Field references live in your metadata, so a field rename is visible to dependency checks instead of silently producing a blank in a customer-facing document.
The document lands on the record by default, which removes several delivery routes rather than rebuilding them.
Templates are built in a native WYSIWYG builder by your admin, with structure-aware rendering (deep nested hierarchy rendering, auto-detected repeater boundaries, section-level visibility that cascades, adaptive layout on missing data) and a build-time warning system for validating a rebuild against real records.

Being straight about limits: reusable blocks across many templates are on the roadmap, not shipped. On raw rendering performance at very high volume and pixel-exact page-break control we publish no claims, so test your own hardest documents.

FAQ

What happens to my documents if my Formstack Documents subscription ends?

Access to templates and generation history typically ends with the subscription. Export template files, delivery route configurations, and generation history to a destination that satisfies your retention policy before cancelling, and verify the archive with whoever owns compliance.

Is Formstack Documents the same as WebMerge?

Yes. WebMerge was rebranded as Formstack Documents after the acquisition. Older orgs often still have WebMerge-era account ownership, frequently outside the Salesforce team, which is worth resolving before you plan the migration.

Why do Formstack Documents mappings break when we change fields?

Because the mapping lives outside Salesforce, so metadata dependency checks cannot see it. A renamed or restructured field produces no warning and no error, just a blank in the generated document. Moving field references inside the org is what removes this class of failure.

Does data leave Salesforce with Formstack Documents?

Record data is sent to the external service to be merged into the document. Document the exact flow (which fields, which service, retained how long) during inventory: it is both your strongest migration justification and the requirement to evaluate replacements against.

What should I do with the API key at the end?

Revoke it at the vendor, not just in Salesforce. Deleting the configuration locally leaves a valid credential in existence with no owner, which is exactly what a security review will flag later.