Migrating Off PDF Butler in Salesforce: What to Plan For

PDF Butler sits in an interesting middle position among Salesforce document tools. Its configuration records live in your org, which makes part of the inventory straightforward, while template design and rendering involve the vendor's own service, which means part of your migration planning depends on having a login.

That hybrid shape defines what is easy and what is not about leaving. The phased method (inventory, freeze, migrate by pain, pilot with consent, keep a rollback path, then clean up) is in the phased migration playbook. This post covers the PDF Butler specifics.

Scope note: this is about document generation. The wider Butler suite, including e-signature, is a separate decision and should not be folded into the same project.

The footprint in your org

Artifact	Where it lives	Why it matters to the migration
DocConfig records	Salesforce	The document definitions. Queryable, which makes counting easy
Data Source records	Salesforce	SOQL that gathers merge values. Business logic with no other home
Templates and design	The PDF Butler service	Needs account access to inventory properly
Buttons, quick actions, flows, Apex	Salesforce	The launch points
Remote site settings, named credentials, connected app entries	Salesforce	The integration surface, and part of the cleanup

Names and exact object APIs vary between versions, so confirm them in your own org before writing any query you plan to rely on.

What is specifically hard about leaving PDF Butler

1. Data Source records are business logic in disguise

A data source holds the SOQL that gathers what the document merges. As with any tool that stores queries as configuration, the WHERE clause usually encodes real rules: which line items are excluded, which statuses count, how records sort. That logic exists nowhere else in your metadata, and it is rarely documented.

The compounding problem is reuse. One data source often serves several DocConfigs, so retiring the one that served the document you just migrated can break two you have not touched.

What to do: export every data source with its SOQL before starting, and build a data-source-to-DocConfig usage map. When rebuilding, re-express the requirement rather than translating the query literally, because some clauses are workarounds for template limitations rather than business rules.

2. DocConfig count is not document count, in either direction

Two opposite errors are common. Teams overestimate the work by counting every DocConfig as a document, when many are variants of the same document for a different language, country, or business unit. Or they underestimate it by counting document families, when several DocConfigs carry meaningfully different logic that has drifted apart over the years.

What to do: group DocConfigs into families during Phase 0, and diff the variants within each family. The variants that turn out to be identical apart from a header are consolidation candidates; the ones that have drifted are separate migrations wearing the same name. Language and country variants are usually the largest group, and the ratio of variants to families is a good proxy for what the current model is costing you.

3. Half the inventory needs a login

Templates and their design live on the vendor's side. Before planning, confirm who has account access, that the credentials work, and whether your plan limits how many people can hold them.

What to do: export or capture every template, and record which DocConfig uses which, while your subscription is active. This is a Phase 0 deliverable, not a decommissioning task. Access disappears with the subscription, and with it the ability to answer questions about what a document used to contain.

4. The security review asks about processing, not just storage

PDF Butler makes strong compliance claims, including ISO, HIPAA, and GDPR alignment, and states that documents are not stored externally. Those are meaningful commitments and worth taking at face value.

But a careful reviewer distinguishes storage from processing, and if your requirement is that no record data is transmitted outside Salesforce at all, "not stored externally" does not answer it. Neither does it answer where processing happens for the purposes of a data residency clause.

What to do: ask the vendor directly for a current statement of the data flow (what is transmitted, where it is processed, what is retained and for how long) and get it in writing rather than relying on a marketing page or on this post. Then hold any replacement to the same question. If your organization moved to PDF Butler partly for EU data residency, that requirement does not disappear because you are switching tools, and it should be an explicit evaluation criterion rather than an assumption.

5. Language and country variants are the real migration

For orgs running PDF Butler across multiple countries, the bulk of the work is rarely one complicated document. It is the same document maintained in six languages with local legal variations, where every change means six edits and the copies drift.

What to do: pick one multi-language family for an early wave, and use it to test whether the replacement genuinely collapses those variants into conditional sections or simply reproduces the same sprawl with different tooling. That answer determines whether the migration is worth doing at all, so find it out early rather than after five easy documents have moved.

The PDF Butler-specific cleanup list

DocConfig and data source records, after export of both configuration and SOQL
Templates, captured from the vendor side before the subscription ends
Remote site settings, named credentials, and connected app entries for the integration
Any integration user, licenses, and permission sets granting access to the package objects
Buttons, quick actions, flows, and Apex that trigger generation
Fields created to feed data sources: formatting, concatenation, and sort fields
The subscription, cancelled only after export is verified and one full business cycle has run in the new system

Where ZeroExport fits

ZeroExport is a native, structure-aware document generation engine that runs entirely inside Salesforce as a managed package.

Nothing leaves the org, which retires the storage-versus-processing conversation instead of answering it, and makes the data residency question moot rather than contractual.
Query logic moves into the template. Related data is bound declaratively against your objects rather than living in a separate SOQL record, so rules that were invisible in a data source become visible in the thing you edit.
Structure-aware rendering is what determines whether your language and country variants can collapse: deep nested hierarchy rendering, auto-detected repeater boundaries, section-level visibility that cascades, adaptive layout when data is missing, and per-record override for genuine one-off exceptions.
A build-time warning system surfaces structural problems before you ship, which is useful when validating a consolidated template against every variant it replaces.

Being straight about limits, and this one matters given how multi-country orgs use this tool: reusable blocks, meaning one structural section defined once and propagated across many templates, are on the roadmap and not shipped. Today the consolidation you get is one template per document family with conditional sections inside it, not one shared block across many templates. If your requirement is specifically the latter, plan around it. On raw rendering performance at very high volume and pixel-exact page-break control we publish no claims.

FAQ

Does PDF Butler send Salesforce data outside the org?

Configuration records live in Salesforce, while design and rendering involve the vendor's service, and the vendor states that documents are not stored externally. If your requirement concerns transmission and processing rather than storage, ask for a current written statement of the data flow rather than relying on any third-party summary, including this one.

How do I count what needs migrating from PDF Butler?

Group DocConfig records into document families and diff the variants inside each family. Identical variants are consolidation candidates; drifted ones are separate migrations. For multi-country orgs, language and country variants are usually the largest share of the total.

What do I do with PDF Butler data source records?

Export each one with its SOQL and map which DocConfigs use it, since data sources are frequently shared. Treat them as documentation of business rules, then re-express the requirement in the new tool instead of translating the query literally.

We chose PDF Butler for EU data residency. Does migrating put that at risk?

Only if you stop treating it as a requirement. Carry it into your evaluation criteria explicitly. A tool that runs entirely inside Salesforce inherits your org's data residency rather than adding a second jurisdiction to reason about.

Can ZeroExport and PDF Butler run in the same org?

Yes. ZeroExport installs as a managed package alongside it, so you can migrate one document family at a time and keep the existing button as a fallback during each wave.