Migrating Off S-Docs: When Native Is Not the Same as Maintainable

Let us start by ruling out the arguments that do not apply here.

S-Docs runs inside Salesforce. Your data does not traverse a third-party service to become a document, there is no middleware to patch, and there is no external endpoint to defend in a security review. If you have read our other migration guides, the architecture and compliance case that motivates most of them is simply absent in this one, and pretending otherwise would waste your time.

So if you are evaluating a move off S-Docs, the reason is different, and it is usually one of three: who can actually maintain the templates, how many templates you now have, or commercial terms. This post is about migrating for those reasons, honestly framed. The phased method itself is in the phased migration playbook; what follows is S-Docs specific.

One scope note: this covers document generation only. S-Sign, if you use it, is a separate decision and should not be folded into the same project.

The S-Docs footprint in your org

The upside of a native tool shows up here: the footprint is contained, discoverable, and queryable. You can build most of your Phase 0 inventory with SOQL rather than archaeology.

Artifact	Object	Why it matters to the migration
Templates	`SDOC__SDTemplate__c`	The document definitions, with their logic in the HTML source
Generated documents	`SDOC__SDoc__c`	Your historical output. Export these before uninstalling. See below
Template relationships	`SDOC__SDRelationship__c`	A junction defining which templates are offered where, and reaching related data
Automation jobs	`SDOC__SDJob__c`	Records created by Flow, Process Builder, or Apex to generate documents
Buttons and LWC placements	Layouts, Lightning pages, Experience Cloud	The visible launch points

What is specifically hard about leaving S-Docs

1. The real template is the HTML source, not the preview

S-Docs templates are HTML underneath. The editor offers a WYSIWYG surface, and simple templates genuinely stay simple in it, but advanced behavior (conditional blocks, related-list rendering, layout control, styling) is expressed in the source, and mature templates tend to accumulate hand-edited HTML and CSS over the years.

For migration this matters twice. First, you cannot scope the work by looking at the rendered PDF: the conditional branch that fires for one customer type may never appear in the version you are looking at. Second, the person who wrote the source may be the only person who can read it, which is often the very reason the migration is being considered.

What to do: read the source of every template you plan to migrate and extract the conditional branches into plain language before rebuilding. Generate each template against records that exercise every branch you found, and keep those as your comparison set. This is the single highest-value activity in an S-Docs migration, and it doubles as documentation you have probably never had.

2. "An admin can maintain it" is not the same as "your admin does"

This is the honest version of the maintainability question. S-Docs puts template editing inside Salesforce and provides wizards for merge fields, related lists, and conditional logic, so an admin can maintain a template. In practice, teams often find that once a template needs a nested table, a conditional section, or precise layout, the change requires someone comfortable in HTML and CSS, and requests queue behind that person.

Before migrating, measure it rather than assuming it: over the last six months, how many template changes were made, by whom, and how long did each wait? If your admin has been making changes comfortably, the strongest argument for moving evaporates and you should be skeptical of the project. If every change routed to one developer or an external consultant, you have your business case in numbers.

3. Template count grows quietly

Because templates are cheap to clone, orgs accumulate variants: one per region, per business unit, per product line, per language. Each is a separate record with its own copy of shared HTML, and a change to the standard footer becomes a search-and-replace across dozens of templates.

What to do: in Phase 0, group templates into document families and count the variants per family. That ratio is your maintenance tax and your migration ranking at the same time, since the families with the most variants are where consolidation into conditional sections pays off most.

4. Automation lives in job records, not buttons

SDOC__SDJob__c records are how flows, processes, and Apex trigger generation. This is clean engineering, but it makes launch points harder to find than buttons: nothing on a page layout reveals that a flow creates a job record on stage change.

What to do: search flows, processes, and Apex for creation of the job object explicitly, rather than relying on a review of layouts. Each hit is a launch point with a cutover step and, if it is in Apex, a developer task that gates the eventual uninstall.

5. Uninstalling deletes your document history

This is the S-Docs-specific decommissioning trap, and it is the one that can cost you something you cannot get back.

Because generation is native, your previously generated documents are stored in the org as records on the package's own objects. Uninstalling a managed package removes its custom objects and the data in them. If your compliance position depends on being able to produce the quote you sent a customer three years ago, and that copy exists as an SDOC__SDoc__c record, uninstalling without exporting first destroys the evidence.

What to do: before any uninstall, export the generated-document records and their files to a destination that outlives the package: Salesforce Files or ContentVersion records attached to the parent record, or an external archive that satisfies your retention policy. Confirm the export is readable, and confirm with whoever owns retention that the new location satisfies the requirement. Do this even if you are certain nobody will ask.

The S-Docs-specific cleanup list

The debt register for a native tool is shorter than for a middleware-based one, which is a genuine advantage of the position you are in. Typically:

Template, relationship, and job records, after export
Generated document records and their files, after archival to a destination that survives the uninstall
Buttons, quick actions, and LWC placements, including any in Experience Cloud sites
Flows, processes, and Apex that create job records, which must be retired before uninstall
Permission sets and licenses granting access to the package objects
Fields created to feed templates: formatting fields, concatenation fields, and sort fields, which exist in S-Docs orgs as much as anywhere else

There is no middleware, no remote site setting, and no integration user to unwind, which is a real difference from the other migrations in this series.

Where ZeroExport fits

Since the architecture argument does not apply, the comparison rests on the authoring and rendering model.

ZeroExport is a native, structure-aware document generation engine that runs entirely inside Salesforce as a managed package, so it matches S-Docs on the native question. The difference is in how a template expresses structure: nested hierarchies, repeating blocks, and conditional sections are configured in a native WYSIWYG builder rather than expressed in template source, which is what changes who can make the next change.

Concretely, the capabilities that matter when consolidating a set of cloned S-Docs templates are deep nested hierarchy rendering, auto-detected repeater boundaries (no manual loop markers), section-level visibility that cascades to nested elements, adaptive layout when data is missing, and per-record override for the one-customer exception that would otherwise spawn another variant. A build-time warning system surfaces structural problems before you ship, which is useful when validating a rebuilt template against the branches you extracted from the old source.

And the fair version of the conclusion: if your S-Docs templates are stable, your admin edits them without help, and the count is not growing, the case for moving is weak and we would rather you spent the quarter on something else. The case gets strong when template changes queue behind one person, when variants multiply, or when the documents themselves have outgrown a flat authoring model.

FAQ

Why would anyone migrate off S-Docs if it is already native?

Not for architecture or security, which are its strengths. The usual drivers are maintainability (template changes requiring HTML and CSS skills, so requests queue behind one person), template sprawl from cloned variants, or commercial terms. Measure your last six months of template changes before deciding.

What happens to documents I already generated with S-Docs?

They are stored as records on the package's objects. Uninstalling a managed package deletes its custom objects and their data, so export those records and their files to Salesforce Files, the parent records, or an external archive before uninstalling, and confirm the destination satisfies your retention policy.

How do I find everything that generates S-Docs documents?

Search for creation of the job object (SDOC__SDJob__c) across flows, processes, and Apex, and separately inventory buttons, quick actions, and Experience Cloud placements. Automation-triggered generation does not appear on page layouts, so a layout review alone will miss it.

Can ZeroExport and S-Docs run in the same org?

Yes. Both are managed packages that run inside Salesforce, so they coexist and you can migrate one document family at a time while keeping the existing path as a fallback.

Is switching from S-Docs to ZeroExport a security improvement?

No, and we will not claim it is. Both run inside Salesforce with no external document service. The comparison is about the authoring model and how the engine handles nested and conditional structure, not about where your data goes.