Migrating Off Nintex DocGen for Salesforce (Formerly Drawloop)

Nintex DocGen for Salesforce, which most long-standing orgs still call Drawloop, tends to be the most deeply embedded document tool on this list. It has been in some orgs for a decade, its configuration bundles several documents into a single unit, and its data sources reach into reports and Visualforce pages that look like ordinary org assets until you try to delete one.

That depth is exactly why the migration needs to be phased rather than attempted in one cutover. The method itself (inventory, freeze, migrate by pain, pilot with consent, keep a rollback path, then clean up) is covered in the phased migration playbook. This post covers what is different about DocGen specifically.

---

The DocGen footprint in your org

Artifact	Where it lives	Why it matters to the migration
DocGen Packages (formerly DDPs)	The DocGen Packages tab	The unit of configuration. One package often produces several documents
Data sources	Inside each package	Can point at Salesforce objects, reports, or Visualforce pages
Document templates	Attached to the package	Word, Excel, PowerPoint, and PDF templates, with their conditional logic inside the file
Delivery options	Inside each package	Where the finished document is stored or sent. Frequently several per package
Integration options	Package configuration	Handoffs to e-signature, cloud storage, and other Nintex products
Buttons from the Button Wizard	Layouts and list views	The visible launch points
Scheduled DocGen Packages and batch runs	Scheduled jobs	The invisible launch points
Apex referencing the loop namespace	Your own code	Blocks package removal until refactored. See below

---

What is specifically hard about leaving DocGen

1. A package is not a document

This is the first thing that breaks people's estimates. A DocGen Package bundles data, one or more templates, and one or more delivery destinations. Teams count packages, assume that is the document count, and discover mid-migration that a single package produces a quote, a cover letter, a terms appendix, and a signature-ready copy, each with its own template and its own destination.

What to do: in Phase 0, decompose every package into the individual documents it emits, and inventory at document level. Your document register will be longer than your package list, sometimes considerably. That number, not the package count, is your migration scope.

2. Reports and Visualforce pages are load-bearing infrastructure

DocGen can draw data from reports and from Visualforce pages, and many mature configurations do. This creates two problems.

The first is fragility in place: a report used as a data source is one well-meaning edit away from changing what appears in a customer-facing document, and nothing in the report warns you. The second is discovery: those reports and pages do not look like docgen assets. They sit in ordinary folders with ordinary names, and a cleanup project a year from now will delete one without knowing.

What to do: enumerate every report and Visualforce page referenced by a data source and add them to the debt register with their true owner recorded as document generation. During migration, treat a report-backed data source as a signal to re-express the requirement directly against the objects, rather than porting the dependency into the new tool. Visualforce-backed sources deserve the same scrutiny, and are usually where the oldest, least understood logic sits.

3. Delivery options are a second migration hiding inside the first

Rendering the document is half the job. The package also decides where the output goes: attached to the record, into a cloud storage destination, into an e-signature envelope, emailed to a particular recipient, or several of those at once.

Each destination is its own piece of work, and some are owned by other teams. The SharePoint path finance depends on, the e-signature handoff legal signed off on, the shared mailbox that receives a copy: none of that is in the template.

What to do: inventory delivery options as first-class rows, not as a footnote on the document row, and get the owning team into the wave. Also note that email delivery is a common breakage point over time. Microsoft's Exchange Online changes affecting SMTP-based delivery, which took effect on March 1, 2026, are the recent example of an external platform change landing on your document pipeline through the delivery layer.

4. Apex in the loop namespace blocks the exit

DocGen exposes Apex classes in the loop namespace so packages can be invoked from code. Wherever a developer used that (a trigger that fires a package on stage change, a service class producing documents in bulk), you have a hard dependency on the managed package. You cannot uninstall a managed package while your own Apex still references its namespace, and the same applies to flows referencing its actions.

What to do: search your codebase for the namespace during Phase 0, not during decommissioning. Every hit is a migration task with a developer attached, which affects sequencing: those documents should not be in your first wave, but they must not be left to the very end either, because they gate the uninstall that ends the project.

5. Vendor-driven maintenance is part of the total cost

DocGen has required periodic org-side work that lands on your admin regardless of whether anything about your documents changed. The authentication change is the clearest recent example: package versions released after January 2026 require Connected Apps and OAuth, and automated runs fail with authentication errors if the org has not been moved over.

None of this is unreasonable on the vendor's part, and it is not an argument that the product is bad. It is an argument for counting it honestly. When you build the business case, include the recurring maintenance events, not only the license line, and check what the replacement's equivalent burden looks like.

6. Drawloop-era configuration has no living author

The oldest packages in a mature org were often built by a consultant during the Drawloop years. Naming conventions have drifted, some packages are inactive but not deleted, and some produce documents nobody has requested since 2019.

What to do: use the freeze rule aggressively here. Anything untouched for two years is a candidate for retirement rather than migration, but confirm with the business before deciding, because that category also contains the annual compliance document that works fine and therefore never gets discussed.

---

The DocGen-specific cleanup list

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

• DocGen Package records and their attached templates and delivery configurations
• Reports and Visualforce pages that exist only as data sources
• Buttons generated by the Button Wizard on every layout and list view
• Apex classes, triggers, and flows referencing the loop namespace, which must be refactored before uninstall
• Connected apps, OAuth configuration, and remote site settings created for the integration
• Nintex licenses, permission sets, and any integration user
• Scheduled jobs for scheduled packages and batch runs
• Storage and e-signature integration configuration that outlives the documents it served

Work this list during decommissioning, deprecating before deleting, and export every template and package configuration first.

---

Where ZeroExport fits

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

• It coexists. Installing it does not disturb DocGen. Both run in the same org, so you migrate one document at a time and keep the existing button as a fallback.
• Data binding replaces data sources. Related data is bound declaratively in the template against your objects, which is what lets you retire report-backed and Visualforce-backed data sources rather than reproducing them.
• Nothing leaves the org, so the authentication and integration surface that generates recurring maintenance is not part of the architecture.

On structure, the capabilities that typically collapse several package 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 difficult records during a parallel run.

Being straight about limits: reusable blocks across many templates are on the roadmap, not shipped, so today the model 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. Evaluate any candidate, including this one, against your own requirements.

---

FAQ

Is Nintex DocGen the same as Drawloop?

Yes. Nintex acquired Drawloop and the product became Nintex DocGen for Salesforce. Older orgs often still refer to DocGen Packages as DDPs, and the Apex namespace is still loop, which is why the Drawloop name persists in configuration long after it disappeared from the marketing.

How do I count what I actually need to migrate from DocGen?

Count documents, not packages. A single DocGen Package commonly produces several documents with different templates and delivery destinations, so the package list understates the work. Decompose each package into the documents it emits during inventory.

What happens to reports used as DocGen data sources?

Treat them as document infrastructure. Enumerate every report and Visualforce page referenced by a data source, record document generation as their real owner, and re-express the data requirement directly against your objects during migration rather than carrying the dependency into the new tool.

Can I uninstall the Nintex DocGen package once documents are migrated?

Not while your own Apex, triggers, or flows still reference the loop namespace. Search for those references during inventory, because they are developer tasks that gate the final uninstall. Remove launch points first, deactivate, archive templates and package configurations, then uninstall.

Can ZeroExport and Nintex DocGen run in the same org?

Yes. ZeroExport installs alongside DocGen as a managed package, so you can migrate document by document and keep the existing path available as a fallback during each wave.

Related Reading

• How to Migrate Off a Salesforce Document Generation Tool Without Breaking It
• Migrating Off Conga Composer: A Phased Plan for Document Generation
• The Hidden Logic Problem in Word-Based Salesforce Documents
• The Salesforce Document Generation Workaround Tax
• Why Native Salesforce Document Generation Matters for Compliance