Migrating Off Conga Composer: A Phased Plan for Document Generation

Most posts about leaving Conga Composer are product comparisons wearing a migration costume. This one assumes you have already decided to move, or you are close to it. The question is not which tool. It is how do we get out of this without breaking the documents the business runs on.

A scope note first: this is about Conga Composer and document generation only. Not Conga CLM, not Conga Contracts, not Conga Sign, not Grid. Contract lifecycle and e-signature are separate migrations with different stakeholders and different risk, and folding them into a docgen project is a reliable way to stall both.

The phased method itself (inventory, freeze, migrate by pain, pilot, rollback, cleanup) is the same regardless of which tool you are leaving, and it is covered in depth in the phased migration playbook. This post covers what is different about Composer specifically: where its logic hides, what it leaves behind, and which parts surprise teams.

The Composer footprint in your org

Composer is rarely one thing you can disable. In an org that has had it for a few years, it is a network. Before you plan anything, enumerate all of it.

Artifact	Where it lives	Why it matters to the migration
Conga Solution records	Composer objects in your org (typically the `APXTConga4` namespace; confirm in your own org)	The unit of configuration. One solution can drive several documents
Conga Template records	Same namespace, with the Word, Excel, or PowerPoint file attached	The template file is the visible half. The conditional logic inside it is the other half
Conga Merge Query records	Same namespace, holding SOQL	Business logic that exists nowhere else in your metadata
URL buttons	Custom buttons and links on layouts and list views	The parameter string is the real specification. See below
Conga Batch and Conga Trigger, if licensed	Scheduled and automated runs	Invisible launch points. These are the ones teams forget
Conga Conductor chains, if used	Solution configuration	One click producing several documents in sequence
Composer email templates and delivery settings	Solution and button configuration	Recipients and subject lines are frequently hardcoded outside your email templates

What is specifically hard about leaving Composer

1. The button parameter string is the spec

This is the one teams underestimate most. A Composer button is a URL carrying a long querystring: session and server parameters, the record Id, TemplateId, QueryId, plus behavioral parameters like OFN for the output file name, DefaultPDF for output format, the SC family for where the finished file is stored, and email parameters for who receives it.

That string is not plumbing. It is the document's actual specification: what it is named, what format it is, where it lands, whether it is emailed, and to whom. Migrate the template and the query and you have migrated maybe two thirds of the behavior. The naming convention that finance depends on for their filing, and the fact that this one quietly emails a copy to a shared mailbox, live only in that URL.

What to do: capture every button URL verbatim into your inventory before anything else, and decode each one into plain language: this button produces X, names it Y, stores it at Z, emails it to W. That decoded line is the acceptance criterion for the migrated version. Your buttons will carry their own mix of parameters, so do not work from a generic list.

2. Merge queries are shared, and they are undocumented business logic

A merge query is SOQL plus, usually, a WHERE clause encoding a real business rule: which line items are excluded, which statuses count, how records are ordered. That logic often exists nowhere else, and nobody wrote it down.

Worse for migration planning, queries are frequently reused across solutions. Retiring the query that served the document you just migrated can break two documents you have not touched yet.

What to do: build a query-to-solution usage map early, and export every query with its SOQL before the migration starts. Treat those exports as documentation of business rules, not as disposable configuration. Re-express the requirement in the new tool and validate side by side rather than translating the SOQL literally, because some of those clauses are workarounds for the template's limitations rather than real business rules.

3. Background and batch runs are launch points nobody remembers

Manual buttons are discoverable because users complain when they change. Scheduled batches and trigger-driven background merges are not. They run silently, often monthly or quarterly, and the first sign they broke is a missing document at period end.

What to do: in Phase 0, explicitly search for automated runs rather than waiting for someone to mention them. Scheduled jobs, automation that calls Composer, anything running in background mode. Cross-check against the calendar: a job that only fires at quarter end will not appear in a two-week observation window.

4. Per-use pricing changes your migration order

The general advice is to migrate by pain. Composer's commercial model can justify a deliberate exception. If you are on consumption or per-use pricing, your highest-volume documents are where the bill is, and moving those first produces measurable savings early, which is often what keeps a migration funded. In the discussions we analyzed, a shift to per-use pricing was one of the most common triggers for leaving, including one team whose bill went from roughly $5.8k to $17.8k.

What to do: rank by pain, then overlay volume. If a high-volume document is also reasonably simple, it is a legitimate first wave even though it is not the most painful, because the saving buys you time for the harder ones. Just do not let the whole migration become volume-ordered, or you will leave the genuinely painful documents for last and never build the expertise to handle them.

5. The security review question

Anything that processes documents outside Salesforce raises the standard questions: what data leaves the org, how the session is authenticated, what is retained. If a security review is part of why you are moving, capture the specific finding in writing during Phase 0. It is the argument that funds the project, and it also becomes a hard requirement for evaluating replacements rather than a vague preference.

The Conga-specific cleanup list

Alongside the usual formatting fields, flattening rollups, and sort fields on any docgen debt register, a Composer install typically leaves:

Solution, template, and merge query records, plus their attachments
Composer buttons on every page layout, Lightning page, and list view that hosts one
Remote site settings and connected app entries for Composer endpoints
A Conga integration user or dedicated licenses, and the permission sets granting access to Composer objects
Custom settings and custom metadata holding solution IDs, parameter defaults, or environment-specific configuration
Reports and list views used as data sources, which look like reporting assets but are document infrastructure
Fields named for the tool (Conga_*, *_Merge__c, sort and sequence fields), which are the easy wins, and the unnamed ones doing the same job, which are not

Work this list during decommissioning, not during migration, and deprecate before deleting: rename with a ZZ_ prefix, remove from layouts, wait a cycle. Export every template and query first. Someone will ask during an audit what a document used to contain, and the archive is the only place that answer will exist.

Where ZeroExport fits

ZeroExport is a native, structure-aware document generation engine that runs entirely inside Salesforce as a managed package. For a Composer migration specifically, three things matter:

It coexists. Installing it does not disturb Composer. Both run in the same org on the same objects, so you can migrate one document family at a time and keep the Composer button as a fallback.
The query logic moves into the template. Related data is bound declaratively rather than through a separate SOQL record, so the business rules that were invisible in a merge query become visible in the thing you are editing.
Nothing leaves the org, which removes the session and data-flow questions from your security review rather than answering them.

On structure, the capabilities that typically collapse a set of Composer solution variants into one template are deep nested hierarchy rendering, auto-detected repeater boundaries, section-level visibility that cascades, and adaptive layout when data is missing, with a build-time warning system for validating against the ugly records during a parallel run.

Being straight about limits: reusable blocks across many templates are on the roadmap, not shipped, so the model today is one template per document family with conditional sections inside it. On raw rendering performance at very high volume and pixel-exact page-break control we publish no claims, so evaluate any candidate, including this one, against your own requirements.

FAQ

How long does it take to migrate off Conga Composer?

It depends far more on document count and business cycle than on tooling. Plan two to four weeks for inventory and evaluation, three to six weeks for a first wave including pilot and feedback, then faster waves, plus one full business cycle before decommissioning. The freeze rule matters more to the total than the speed of any single document.

Can ZeroExport and Conga Composer run in the same org?

Yes. ZeroExport installs alongside Composer as a managed package, so you can migrate one document family at a time and keep the Composer button available as a fallback. That coexistence is what makes an incremental migration possible.

What do I do with my Conga merge queries?

Treat them as documentation of business logic before treating them as things to delete. Export every query with its SOQL, map which solutions use which query (they are frequently shared), and re-express the data requirement in the new tool rather than translating the SOQL literally, since some clauses are workarounds for template limitations rather than business rules.

What happens to my Conga Composer buttons?

Capture each button's full URL before you change anything. The parameter string encodes the output file name, format, storage location, and email behavior, which is a large part of what the document actually does. Decode each into plain language and use it as the acceptance criterion for the migrated version.

Does this apply to Conga CLM or Conga Sign?

No. This is a document generation migration only. Contract lifecycle management and e-signature have different stakeholders, compliance requirements, and risk, and combining them into one project tends to stall all of it.

Should I migrate my highest-volume documents first to cut the bill?

If you are on per-use pricing, partly yes. Rank by pain first, then overlay volume, and let a high-volume but reasonably simple document into the first wave if the saving helps fund the project. Do not order the entire migration by volume, or the genuinely painful documents end up last.