More often than not, the mere thought of having to migrate an untold number of templates to a different system often deters or delays much-needed upgrades and migrations to newer CCM platforms.  The underappreciated importance of data notwithstanding, the effort involved in moving templates and forms from one system to another tends to be the primary driver of project costs and timelines, as most estimates typically center on form counts and complexities (for good reason, too). Oracle Documaker and Quadient Inspire have similar approaches to template storage and design, but moving between the two is anything but straightforward.  A well-designed Quadient solution grants much more flexibility for template design and usage, so it’s critical that you establish a strategy for moving Documaker forms to Quadient Inspire templates that opens the door to these advantages.

Managing Forms in Documaker

Oracle Documaker’s approach to the design and management of templates comes with certain limitations relative to peer solutions. Some key points include:

• Template design is performed primarily via Documaker Studio (with some external capabilities via Word Add-In).
• The foundational component of template design is called a FAP section.
• One or more FAP sections can comprise a Form (FOR), and individual sections can be used across many different forms/templates.
• FAP sections may be included in a form dynamically via “triggers” (DALScript).
• Support for overflow (form, section, repeating sections).
• Styles are made available via a Font Cross Reference (FXR) file referenced in the environment setup.
• Forms/templates may be organized within Groups (GRP) for document assembly.
• Native support for recipient copy-counts.
• Basic support for PDF inclusion via AddMultipageBitmap section rule (used for enclosures & attachments).  Note:  comes with a penalty when printing to anything other than PDF as inclusions are rasterized).
• All resources are stored within a centralized Master Resource Library, with basic organizational/navigational capabilities via Documaker Studio.

Managing Templates in Quadient

Quadient Inspire shares some basic tenets of design with Documaker, but deviates in some important areas that make the solution more flexible and easier to navigate by non-technical users.  Some key points include:

• Quadient templates start out as “Layouts” in a workflow (WFD) built within Inspire Designer (a power-user app).
• Those WFD’s can stand on their own, or serve as a foundation for other designs:
  • WFD’s built in Designer.
  • Templates, Blocks, Rules & Styles built within Inspire Interactive (a business-user app).
• Inspire Interactive is a web-based app that allows business users to build resources based upon “Master” Templates built in Inspire Designer.
• Extended support for native inclusion of external content support via PDF, HTML, RTF, XML, JSON or WFD.
• External flows may be static (direct) or dynamic (condition-based).
• Support for overflow (pages, flows, tables).
• Styles are made available via an external style “Master” workflow inherited by downstream workflows.
• All resources are stored within Inspire Content Manager (ICM), which is a structured repository navigable via ICM Explorer.  ICM affords custom organizational capabilities, including support for tenants and folders.
• “Categorization” features to create complex documents containing dynamic external flows with content based on fulfillment of specific conditions.

Understanding the differences and why it’s important

When planning and budgeting a move from Documaker to Quadient, you really need to undertake a thorough review of the Documaker implementation to understand how sections, forms and groups are built and organized.  How many templates are truly static vs dynamic in nature, and how many are still used in Production?  Of the dynamic templates, how many are considered simple, medium, and complex?  How pervasive is the use of sub-forms for handling enclosures and overflow?  Are all of the templates included within Documaker GRP files, or are some triggered dynamically via input data?  Are all of the mapped fields listed in the XDD?  What about dynamic inclusion of external PDF via the AddMultipageBitmap rule?  The answers to these questions and others can have a significant impact on migration costs and timeline.

Moving Templates to Quadient

Recognizing that every Documaker implementation is different, it is critically important that you understand exactly how the source system was built and how Documaker sections (FAP), forms, and groups are organized.  You may be tempted to work with output from Documaker in an attempt extrapolate backwards to document composition & assembly, but that approach would almost certainly miss critical content and logic embedded within Documaker and introduce unnecessary risks and costs to the project.  Moving Documaker forms to Quadient templates can be a tricky endeavor that, done incorrectly, will result in project overruns and produce a system that is difficult and costly to maintain. Without question, the best approach is to unpack and organize the source system to serve as a basis for staging resources for Quadient.  To facilitate this process, we’ve built an extraction utility that traverses all core Documaker design files and produces key resources and assembly reports that serve as a roadmap to Quadient Inspire.  Leveraging these assets, our team of Quadient SME’s employ a best-practices approach to template migration as follows:

• Import static content directly to ICM as PDF for dynamic inclusion during assembly.
• Import/build style and data “Master” templates in Quadient (see Moving Documaker Data to Quadient).
• Analyze dynamic content and rationalize into core “Master” template designs in Quadient.
• Build specific Templates in Inspire Interactive for each dynamic Form (FOR) in Documaker.
• Copy/import RTF sections as Blocks in Quadient, add to Inspire Interactive Templates, and apply respective display rules to match assembly from the extracted Documaker reports.
• Build assembly “Master” template in Quadient and leverage exported group/recipient resources from Documaker to drive assembly of dynamic/static content and recipient batching.

Bottom-line, template volume and complexity plays a major role in the timelines and costs required for a Documaker-to-Quadient migration project. Moving Documaker forms to Quadient requires a skilled hand – there’s no magic bullet here – and it can very easy to make costly mistakes without the requisite experience and roadmap to guide you there.