Migrating Legacy Document Viewing Solutions to Modern Low‑Footprint SDKs
← Back to Blog8 min read

Migrating Legacy Document Viewing Solutions to Modern Low‑Footprint SDKs

The quickest path to a modern, secure, and responsive document viewer is to replace legacy components with Doconut’s low‑footprint SDK. For web portals using Kendo UI, the SDK provides fast rendering, full accessibility, and a focused integration path. Enterprises that once cobbled together custom viewers on top of desktop‑only libraries or external conversion services soon run into trouble: maintenance costs climb, client‑side dependencies become fragile, and accessibility is left in the dust. Doconut knocks down those barriers by serving native PDF, Office, and CAD rendering straight from a .NET back‑end, while keeping the front‑end lightweight and fully under your control.

In the next sections we’ll look at why old‑school viewers turn into liabilities, how Doconut’s architecture tackles those pain points, and a hands‑on migration roadmap you can start using right now.

Migration from a dependency-heavy legacy viewer to a secure server-side document viewer
Migration from a dependency-heavy legacy viewer to a secure server-side document viewer

1. Legacy Viewers: Hidden Costs Behind Familiar Interfaces

Most “legacy” document viewers were born when browsers still leaned on plug‑ins, ActiveX controls, or hefty Office installations on the server. The fallout shows up in several ways:

IssueReal‑world impact
Client‑side dependenciesUsers must install or enable browser plug‑ins; corporate IT blocks them, breaking the workflow.
Server‑side Office requirementsInstalling Microsoft Office on a web server violates best‑practice security and inflates licensing costs.
Limited format supportNew CAD or image formats (DWG, DXF, PNG) appear unsupported, forcing work‑arounds or manual conversions.
Scalability bottlenecksRendering runs on the client CPU; large PDFs or multi‑page Office files cause sluggishness and crashes.
Accessibility gapsKeyboard navigation, screen‑reader support, and WCAG compliance are often after‑thoughts, exposing enterprises to compliance risk.
Maintenance nightmareVendor SDKs that are no longer updated become security liabilities, and every patch forces a full redeployment.

Add those hidden costs to a document‑centric system—whether it’s a DMS, CRM portal, or e‑learning platform—and the ROI evaporates fast. Modern enterprises need a viewer that doesn’t depend on client plug‑ins, runs without Office, and scales on the server. Doconut gives you exactly that.


2. Low‑Footprint, Server‑Side Rendering: The Ideal PDF Viewer SDK for Modern Apps

Doconut’s core strength lies in its server‑side document rendering engine that streams raster images to the browser, eliminating any need for a client‑side plugin. Here’s how the architecture lines up with the challenges above:

a. Minimal Client Footprint for the Browser

  • The viewer serves only HTML, CSS, and a tiny amount of JavaScript. No ActiveX, no Flash, no Silverlight—just standard web assets delivered to supported web browsers.
  • Because rendering happens on the server, the client never needs .NET Desktop, Office, or a CAD viewer installed.

b. Comprehensive Format Coverage

Doconut natively supports 33+ formats across Office, PDF, CAD, email, and image categories—including DOC/DOCX, XLS/XLSX, PPT/PPTX, DWG, DXF, PNG, JPG, and more. That wipes out the “file‑type‑gap” that forces developers to stitch together a mishmash of third‑party converters.

c. Built‑in Annotation, Search, and Controlled Printing

  • Annotation Plugin – add highlights, comments, or free‑hand drawings straight in the viewer.
  • Search Plugin – instant text search across the whole document, with OCR for scanned images.
  • Controlled Printing – enforce print policies from the viewer UI, preventing unauthorized copies.

d. Server‑Side Conversion for Office‑Free Workflows

The Converter Plugin lets you turn Word, Excel, PowerPoint, and CAD files into PDF, PNG, or HTML on the server. No Microsoft Office installation, no external SaaS, and no data ever leaves your firewall.

e. Accessibility Built In

Doconut follows WCAG 2.2 AA guidelines out of the box—keyboard navigation, ARIA labels, and screen‑reader‑friendly markup are baked into the viewer’s HTML. Meeting corporate accessibility policies becomes a matter of turning the feature on, not building it from scratch.

f. Seamless Integration with Modern .NET Stacks

Whether you’re on ASP.NET Core, .NET 6, or a micro‑service architecture, Doconut plugs into the request pipeline with a single middleware call. The viewer can be integrated with Kendo UI components or a supported web front‑end.


3. Migration Blueprint: From Legacy to Doconut

Below is a pragmatic, step‑by‑step migration plan you can follow in an existing .NET web application. The aim is to swap the old viewer for Doconut while keeping the public API stable for downstream consumers.

Step 1: Prepare the Environment

  1. Add the Doconut NuGet package to your solution.
  2. Ensure your server runs .NET 6 (or later); Doconut’s dependency optimizer shines with the newest runtime.

Step 2: Register Doconut Middleware

Insert the Doconut middleware early in the ASP.NET request pipeline so that requests for rendered document images are intercepted and processed by Doconut’s engine.

Step 3: Load the License

At application start, load the Doconut license file (or XML document) once. If you have plugin‑specific licenses (e.g., for the Annotation Plugin), load them using the appropriate Doconut API.

Step 4: Replace Old Rendering Calls

Identify places where legacy code renders a document page to a bitmap or byte array. Replace those calls with Doconut’s document‑open flow, which returns a token representing the opened document. Use the token to request page images or thumbnails via Doconut’s image‑serving endpoints.

Map any existing “add comment” or “search” functionality to Doconut’s Annotation and Search plugins. Both plugins expose simple server‑side methods that return JSON payloads, which your front‑end can consume.

Step 6: Update Front‑End Integration

Because Doconut streams rendered images, the front‑end only needs an <img> tag per page or a canvas‑based viewer. For Kendo UI, bind the image URLs to a Kendo Carousel for smooth page‑turning.

Step 7: Test, Optimize, Deploy

  • Performance – measure time‑to‑first‑page; Doconut’s server‑side raster rendering typically delivers sub‑second results for standard PDFs.
  • Security – verify that no document data leaks to the client beyond the rendered images.
  • Accessibility – run a screen‑reader audit; Doconut’s markup already includes ARIA roles.

When the test suite passes, replace the legacy viewer route with the new Doconut endpoint and roll out the update.


4. Boosting Accessibility and UX with Doconut and Kendo UI

Accessibility isn’t a nice‑to‑have anymore; it’s a requirement in many regulated industries (healthcare, finance, public sector). Doconut’s out‑of‑the‑box compliance helps you meet those standards without writing custom code.

Keyboard Navigation

Every interactive element—page navigation, zoom controls, annotation tools—exposes standard tabindex attributes. Users can zip through the document using only the keyboard, a must‑have for Section 508 compliance.

ARIA Labels and Screen Readers

The viewer’s HTML includes role="document" and descriptive aria-label attributes that convey page numbers and zoom level to assistive technologies. No need to sprinkle extra ARIA scripting yourself.

High‑Contrast Mode

Doconut can reflect the high‑contrast preferences configured in the viewer interface. The UI can switch to a dark‑on‑light scheme, keeping readability sharp for visually impaired users.

Integration with Kendo UI

Kendo UI’s accessible widgets (e.g., kendoButton, kendoSlider) can sit on top of Doconut’s image rendering. The result? A seamless, fully keyboard‑navigable viewer that feels native to the rest of your app.


5. Future‑Proofing: Extending the Viewer with Plugins

Doconut’s modular plugin architecture means you can start with basic viewing and later turn on extra capabilities as business needs evolve.

PluginCore BenefitTypical Enterprise Use
Annotation PluginHighlight, comment, drawLegal review, engineering change orders
Search PluginFull‑text, OCR‑powered searchHealthcare record lookup, finance audit
Converter PluginServer‑side Office → PDF/HTMLDMS ingestion pipelines, automated reporting
Controlled PrintingPrint quotas, watermarksConfidential contracts, regulated filings

Because all plugins run on the server, you retain centralized control over data handling, licensing, and scaling. Adding a new plugin is as simple as loading its license and calling the relevant API—no front‑end recompilation required.


Conclusion

Modernizing your document‑viewing stack doesn’t have to be a costly, risky overhaul. By adopting Doconut’s low‑footprint, server‑side rendering engine you gain:

  • Broad format support without external converters.
  • Built‑in annotation, search, and controlled printing that meet compliance needs.
  • Enterprise‑grade accessibility right out of the box.
  • Smooth integration with existing .NET and Kendo UI projects.

Ready to retire legacy viewers and give your users a faster, more secure experience? Start your migration with Doconut today – download the SDK, follow the migration blueprint, and see the difference in minutes.

#document rendering#PDF Viewer SDK#legacy migration#enterprise .NET#Doconut